Re: Wondering about errors…

[Rainer Schuetze]

On 27.05.2013 13:51, Adam D. Ruppe wrote:

Yeah, me too.

I take a working program and add "gf" to the middle of it. Here's the
errors:

base.d(2143): Error: found '{' when expecting ';' following statement
base.d(2168): Error: unexpected ( in declarator
base.d(2168): Error: basic type expected, not "div"
base.d(2168): Error: found '"div"' when expecting ')'
base.d(2168): Error: no identifier for declarator div.addChild(int)
base.d(2168): Error: semicolon expected following function declaration
base.d(2168): Error: Declaration expected, not ','
base.d(2177): Error: Declaration expected, not 'if'
base.d(2179): Error: no identifier for declarator qrUrl
base.d(2180): Error: unrecognized declaration


OK now let's add a semicolon to it. Prepare yourself, here's what
dmd gives me now:

base.d(2141): Error: undefined identifier gf, did you mean template to(T)?
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/format.d(1723): Error:
template std.format.formatRange does not match any function template

[...]

formattedWrite!(Appender!(immutable(dchar)[]), dchar,
immutable(dchar)[],immutable(dchar)[],immutable(dchar)[],immutable(dchar)[],immutable(dchar)[])

make: *** [all] Error 1



I think most of these floods of errors come from not wanting to 
instantiate templates once any (completely unrelated) error has been 
shown. This has improved, but I just found two instances of that in mtype.c:


if (global.errors)
return new ErrorExp();  // TemplateInstance::semantic() will 
fail anyway


The mechanism of not showing errors if they contain ErrorExp seems to 
not work in that case, but I think not even trying to do the 
instantiation is unreasonable (just stopping compilation would be better).

Re: Discussion of TypeTuple naming

[Jonathan M Davis]

On Tuesday, May 28, 2013 04:52:50 Diggory wrote:
> Are you really arguing that the existing system is easier to
> understand?

I'm arguing that the only problem in the current design is the name. TypeTuple 
is a template for creating built-in tuples, and the built-in tuples deal with 
both expressions and types, so that's what TypeTuple should do. The fact that 
it's called TypeTuple is a problem, because it doesn't just deal with types, 
and the fact that the documentation indicates that it just deals with types is 
a problem, because it doesn't. But I don't think that there's any problem with 
how the template itself works.

If I could go back, I'd rename TypeTuple to something like StaticTuple, or 
ParamTuple, or ArgTuple, or ParamSeq, or ArgSeq, or some other name which made 
more sense for what it does. But given that we can't go back in time, we have 
to contend with the fact that both the module and template have the name 
TypeTuple (albeit with different capitalization) and that changing them would 
break a lot of code. And Walter in particular is very much against making 
breaking changes which don't have a large ROI, and he and Andrei have made it 
clear that they don't want to be changing symbol names in the library at this 
point just because the names aren't as good as they should be. The ROI is too 
small. So, at this point, the fact that a name is poor is generally _not_ 
enough to get it changed. TypeTuple is bad enough that they _might_ agree to 
it, but I doubt it. So, given the current situation, we clearly need to 
improve the documentation, but that's probably all that we can do.

Regardless, I have _zero_ problem with the design of TypeTuple, just the name.

- Jonathan M Davis

Re: Walter: A small request for this upcoming release's installer

[Brad Anderson]

On Tuesday, 28 May 2013 at 04:12:06 UTC, Walter Bright wrote:

On 5/27/2013 7:44 PM, Brad Anderson wrote:
(Sorry for the NG noise, I would have just emailed you 
directly about this but I

couldn't manage to find your email address)

Could you use the AWS hosted URLs for the zip files in the 
windows installer
script?  It takes around 5-10 minutes to install from the 
ftp.digitalmars.com URLs.


Thanks.


Pull requests are welcome!

https://github.com/D-Programming-Language/installer


I know, I've made about 6 of them so far :)

I just mean when you update the .nsi with the URLs to the new 
release  during your regular release 
process, use the S3 hosting URLs instead of the 
ftp.digitalmars.com address to the 2.063 zip.


I've gone ahead and made a pull request using the dmd.2.062.zip 
url as a base but I'm not entirely sure if other parts of the S3 
url will change over time ("2013" in the URL suggests that at 
least would). 
https://github.com/D-Programming-Language/installer/pull/16


While we are on the subject, I'm thinking of doing a pull request 
to make it so the installer executable is something more along 
the lines of "dmd-2.063.exe".  Reusing dinstaller.exe over and 
over is confusing (to me at least).  You wouldn't have to do 
anything, it'd just use the version string in the .nsi you update 
when you roll a release.


Also, I'd like to make a pull request to move away from a 
internet installer and just package it all into the installer 
executable. One benefit is it shouldn't be hard for NSIS to only 
have it grab the Windows specific stuff. It'd just grab some 
wildcarded paths (dmd2/{html,src,windows} I believe is all that 
is required).  The most you'd have to do is give it a path to the 
root of the directory you make the dmd zip from (probably dmc and 
d1 too).  NSIS would do the rest (and LZMA compress it so it'll 
be even smaller).

Re: Why UTF-8/16 character encodings?

[Manu]

On 28 May 2013 14:38, Peter Williams  wrote:

> On 28/05/13 13:22, David Eagen wrote:
>
>> On Tuesday, 28 May 2013 at 01:38:22 UTC, Peter Williams wrote:
>>
>>
>>> So you're going to spell check them all to make sure that they're
>>> English?  Or did you mean ASCII?
>>>
>>> Peter
>>>
>>
>> That's it. I'm filing a bug against std.traits. There's a unittest there
>> that with a struct named "Colour". Completely unacceptable.
>>
>
> Except here in Australia and other places where they use the Queen's
> English :-)


Is there anywhere other than America that doesn't?

Re: Why UTF-8/16 character encodings?

[Peter Williams]

On 28/05/13 13:22, David Eagen wrote:

On Tuesday, 28 May 2013 at 01:38:22 UTC, Peter Williams wrote:



So you're going to spell check them all to make sure that they're
English?  Or did you mean ASCII?

Peter


That's it. I'm filing a bug against std.traits. There's a unittest there
that with a struct named "Colour". Completely unacceptable.


Except here in Australia and other places where they use the Queen's 
English :-)


Peter

Re: More on "Component Programming"

[Peter Alexander]

On Monday, 27 May 2013 at 21:36:12 UTC, bearophile wrote:
"pairwise" is a very useful lazy range similar to 
cartesianProduct, but it yields only the ordered pairs, so they 
cover only about half (a triangle) of the square matrix of the 
possibilities.


This will be part of my combinatorics library, but is more 
general. pairWise is just a specific case of k-subsets (with 
k=2). By default, it currently provides the subsets in 
colexicographic order instead of lexicographic, but I intend to 
make the ordering a policy before I'm done.

Re: More on "Component Programming"

[Timothee Cour]

On Mon, May 27, 2013 at 9:53 PM, H. S. Teoh  wrote:

> On Mon, May 27, 2013 at 09:24:28PM -0700, Timothee Cour wrote:
> > > Done, turns out the fix was trivial, just swapping two static ifs:
> > > https://github.com/D-Programming-Language/phobos/pull/1314
> >
> > This isn't what Andrei had in mind in his post above:
> >
> > > I'm disappointed cartesianProduct works that way; I should have
> > > caught that during the code review. A better iteration order would
> > > have spanned the lower position in both ranges first, i.e. create
> > > squares of increasing side in the 2D space.
> >
> > I would suggest an additional template parameter to specify the order
> > of iteration:
> [...]
>
> The problem with allowing the user to specify order is that when one or
> more of the input ranges are infinite, the order of traversal is much
> less flexible, and it may not be possible to satisfy the requested
> order.
>

Explicit is better than implicit. The user should request the order, and
the compiler can statically disallow
lexicographic_depth/antilexicographic_depth
when at least one of the ranges is infinite.


>
> The order that Andrei suggested is what's currently used for two
> infinite ranges, though when finite ranges are involved I chose a
> slightly simpler implementation. The order bearophile proposed in issue
> 9878 is different from what Andrei describes, at any rate.
>
> What's the typical output order of cartesian products in other languages
> / libraries? It seems nobody can agree on what the order should be. :-/
>
>
python uses itertools.product which is lexicographic_depth.
Like you say, no-one can agrees what the order should be, so let's leave it
up to user through a template. Sounds like a no-brainer to me. There are
use cases for each order I mentioned.


>
> T
>
> --
> People demand freedom of speech to make up for the freedom of thought
> which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
>

Re: More on "Component Programming"

[Peter Williams]

On 28/05/13 11:50, bearophile wrote:

Peter Williams:


Are the () necessary on sort?


If you don't use () I think you call the slower, not flexible and buggy
built-in sort. I think it's already deprecated. Maybe I am wrong...


Ah.  Does that mean that import.algorithms is need to use sort()?





PS Now I've found this I can go back and simplify all the code where I
iterated over associative arrays in key order by getting the keys and
the sorting them separately.


I don't fully understand.


I'm assuming here that it's safe to call sort() on the .keys property of 
the dynamic array.  This enables me to go:


foreach (key; aa.keys.sort()) {...}

instead of the much more complex code I'm currently writing which gets 
the keys, sorts them and then uses them in the foreach.  I had actually 
written a generic function to do all of that but now find all the work 
was unnecessary :-).


As I learn more about D I'm finding I can go back and simplify a lot of 
my code.  I'm going to reread Andrei's book to see what I missed the 
first time.


Peter
PS I think I need to read more about component programming as I'm 
beginning to suspect I don't understand it fully.

Re: Why UTF-8/16 character encodings?

[Diggory]

On Tuesday, 28 May 2013 at 04:52:55 UTC, Walter Bright wrote:

On 5/27/2013 9:27 PM, Manu wrote:
I will never write colour without a u, ever! I may suffer the 
global American
cultural invasion of my country like the rest of us, but I 
will never let them

infiltrate my mind! ;)


Resistance is useless.


*futile :P

Re: More on "Component Programming"

[H. S. Teoh]

On Mon, May 27, 2013 at 09:24:28PM -0700, Timothee Cour wrote:
> > Done, turns out the fix was trivial, just swapping two static ifs:
> > https://github.com/D-Programming-Language/phobos/pull/1314
> 
> This isn't what Andrei had in mind in his post above:
> 
> > I'm disappointed cartesianProduct works that way; I should have
> > caught that during the code review. A better iteration order would
> > have spanned the lower position in both ranges first, i.e. create
> > squares of increasing side in the 2D space.
> 
> I would suggest an additional template parameter to specify the order
> of iteration:
[...]

The problem with allowing the user to specify order is that when one or
more of the input ranges are infinite, the order of traversal is much
less flexible, and it may not be possible to satisfy the requested
order.

The order that Andrei suggested is what's currently used for two
infinite ranges, though when finite ranges are involved I chose a
slightly simpler implementation. The order bearophile proposed in issue
9878 is different from what Andrei describes, at any rate.

What's the typical output order of cartesian products in other languages
/ libraries? It seems nobody can agree on what the order should be. :-/


T

-- 
People demand freedom of speech to make up for the freedom of thought
which they avoid. -- Soren Aabye Kierkegaard (1813-1855)

Re: Why UTF-8/16 character encodings?

[Walter Bright]

On 5/27/2013 9:27 PM, Manu wrote:

I will never write colour without a u, ever! I may suffer the global American
cultural invasion of my country like the rest of us, but I will never let them
infiltrate my mind! ;)


Resistance is useless.

Re: Why UTF-8/16 character encodings?

[Manu]

On 28 May 2013 13:22, David Eagen  wrote:

> On Tuesday, 28 May 2013 at 01:38:22 UTC, Peter Williams wrote:
>
>
>> So you're going to spell check them all to make sure that they're
>> English?  Or did you mean ASCII?
>>
>> Peter
>>
>
> That's it. I'm filing a bug against std.traits. There's a unittest there
> that with a struct named "Colour". Completely unacceptable.
>

How dare you!
What's unacceptable is that a bunch of ex-english speakers had the audacity
to rewrite the dictionary and continue to call it English!
I will never write colour without a u, ever! I may suffer the global
American cultural invasion of my country like the rest of us, but I will
never let them infiltrate my mind! ;)

Re: More on "Component Programming"

[Timothee Cour]

> Done, turns out the fix was trivial, just swapping two static ifs:
> https://github.com/D-Programming-Language/phobos/pull/1314

This isn't what Andrei had in mind in his post above:

> I'm disappointed cartesianProduct works that way; I should have caught
that during the code review. A better iteration order would have spanned
the lower position in both ranges first, i.e. create squares of increasing
side in the 2D space.

I would suggest an additional template parameter to specify the order of
iteration:
for example an enum Order {lexicographic_depth,
lexicographic_breadth,antilexicographic_depth,
antilexicographic_breadth}.
The naming is horrible but you get the idea:
cartesianProduct!(order)(['a','b','c'],[1,2,3]))
order=Order.lexicographic_depth:
a1 a2 a3 b1 b2 b3 c1 c2 c3
order=Order. lexicographic_breadth:
a1 b1 a2 c1 b2 a3 c2 b3 c3
ie , in 2D, it follows diagonals x+y=k, with k=0,1,2,... and 0<=x wrote:

> On Mon, May 27, 2013 at 07:35:36PM -0700, H. S. Teoh wrote:
> > On Mon, May 27, 2013 at 10:01:32PM -0400, Andrei Alexandrescu wrote:
> > > On 5/27/13 5:36 PM, bearophile wrote:
> > > >This simple example shows the difference:
> > > >
> > > >import std.stdio, std.algorithm;
> > > >void main() {
> > > >auto data = [1, 2, 3, 4];
> > > >foreach (xy; cartesianProduct(data, data))
> > > >writeln(xy);
> > > >}
> > > >
> > > >
> > > >Generates the tuples:
> > > >(1, 1)
> > > >(2, 1)
> > > >(3, 1)
> > > >(4, 1)
> > > >(1, 2)
> > > >(2, 2)
> > > >(3, 2)
> > > >(4, 2)
> > > >(1, 3)
> > > >(2, 3)
> > > >(3, 3)
> > > >(4, 3)
> > > >(1, 4)
> > > >(2, 4)
> > > >(3, 4)
> > > >(4, 4)
> > >
> > > I'm disappointed cartesianProduct works that way; I should have
> > > caught that during the code review. A better iteration order would
> > > have spanned the lower position in both ranges first, i.e. create
> > > squares of increasing side in the 2D space.
> >
> > This is not too hard to change; it's just a matter of swapping left-
> > and right- recursion in the templates. I'll see if I can cook up an
> > pull request in a bit.
> [...]
>
> Done, turns out the fix was trivial, just swapping two static ifs:
>
> https://github.com/D-Programming-Language/phobos/pull/1314
>
>
> T
>
> --
> I think Debian's doing something wrong, `apt-get install pesticide',
> doesn't seem to remove the bugs on my system! -- Mike Dresser
>

Re: Why UTF-8/16 character encodings?

[Manu]

On 28 May 2013 11:42, Jonathan M Davis  wrote:

> On Tuesday, May 28, 2013 11:38:08 Peter Williams wrote:
> > On 28/05/13 09:44, H. S. Teoh wrote:
> > > Since language keywords are already in English, we might as well
> > > standardize on English identifiers too.
> >
> > So you're going to spell check them all to make sure that they're
> > English?  Or did you mean ASCII?
>
> I think that it was more an issue of that the only reason that Unicode
> would
> be necessary in identifiers would be if you weren't using English, so if
> you
> assume that everyone is going to be using some form of English for their
> identifier names, you can skip having Unicode in identifiers. So, a natural
> effect of standardizing on English is that you can stick with ASCII.
>

I'm fairly sure that any programmer who takes themself seriously will use
English, I don't see any reason why this rule should nee to be be
implemented by the compiler.
The loss I can imagine is that kids, or people from developing countries,
etc, may have an additional barrier to learning to code if they don't speak
English.
Nobody in this set is likely to produce a useful library that will be used
widely.
Likewise, no sane programmer is going to choose to use a library that's not
written in English.

You may argue that the keywords and libs are in English. I can attest from
personal experience, that a child, or a non-english-speaking beginner
probably has absolutely NO IDEA what the keywords mean anyway, even if they
do speak English.
I certainly had no idea when I was a kid, I just typed them because I
figured out what they did. I didn't even know how to say many of them, and
realised 5 years later than I was saying all the words wrong...

So my point is, why make this restriction as a static compiler rule, when
it's not practically going to be broken anyway. You never know, it may
actually assist some people somewhere.
I think it's a great thing that D can accept identifiers in non-english.

Re: Walter: A small request for this upcoming release's installer

[Walter Bright]

On 5/27/2013 7:44 PM, Brad Anderson wrote:

(Sorry for the NG noise, I would have just emailed you directly about this but I
couldn't manage to find your email address)

Could you use the AWS hosted URLs for the zip files in the windows installer
script?  It takes around 5-10 minutes to install from the ftp.digitalmars.com 
URLs.

Thanks.


Pull requests are welcome!

https://github.com/D-Programming-Language/installer

Re: Walter: htod on github?

[Walter Bright]

On 5/27/2013 8:35 PM, Lionello Lunesu wrote:

On 5/28/13 11:08, Diggory wrote:

On Tuesday, 28 May 2013 at 02:32:24 UTC, Lionello Lunesu wrote:

Walter,

Any chance we can get the source of htod? If found it a very useful
little utility, although there are many issues with it.

VisualD also include a similar utility to convert header files to D,
but it is more tuned to Windows header files. Perhaps we can combine
the two into a new utility?

Lio.


I think htod is based on dmc so open sourcing it would be a problem.


Ah, right. I remember now :) HTOD is using the DMC frontend for C/H parsing and
that's not open sourced. Got it.


I've been thinking about making it "source available".

Re: Walter: A small request for this upcoming release's installer

[Manu]

+1!
It is an annoyingly slow installer...


On 28 May 2013 12:44, Brad Anderson  wrote:

> (Sorry for the NG noise, I would have just emailed you directly about this
> but I couldn't manage to find your email address)
>
> Could you use the AWS hosted URLs for the zip files in the windows
> installer script?  It takes around 5-10 minutes to install from the
> ftp.digitalmars.com URLs.
>
> Thanks.
>

Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ

[deadalnix]

On Monday, 27 May 2013 at 20:34:30 UTC, Peter Alexander wrote:
On Monday, 27 May 2013 at 20:14:35 UTC, Andrei Alexandrescu 
wrote:
At some point Walter and I were talking about generating an MD 
hash for very long names. That has some disadvantages (i.e. no 
easy reverse lookup) but it may work.


Surely a better solution would be to use a lossless 
compression? With the amount of repetition you should get very 
high ratios.


I'd begin with the mangling of template. It is by definition 
redundant, and changing it without any compression scheme can 
already drastically reduce the pathologic cases demonstrated in 
this thread.

Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ

[deadalnix]

On Monday, 27 May 2013 at 20:14:35 UTC, Andrei Alexandrescu wrote:
At some point Walter and I were talking about generating an MD 
hash for very long names. That has some disadvantages (i.e. no 
easy reverse lookup) but it may work.




Reverse lookup never worked for this kind of symbols in the first 
place.

Re: Walter: htod on github?

[Lionello Lunesu]

On 5/28/13 11:08, Diggory wrote:

On Tuesday, 28 May 2013 at 02:32:24 UTC, Lionello Lunesu wrote:

Walter,

Any chance we can get the source of htod? If found it a very useful
little utility, although there are many issues with it.

VisualD also include a similar utility to convert header files to D,
but it is more tuned to Windows header files. Perhaps we can combine
the two into a new utility?

Lio.


I think htod is based on dmc so open sourcing it would be a problem.


Ah, right. I remember now :) HTOD is using the DMC frontend for C/H 
parsing and that's not open sourced. Got it.


L.

Re: [article] Language Design Deal Breakers

[deadalnix]

On Monday, 27 May 2013 at 21:55:00 UTC, Simen Kjaeraas wrote:
Now, if we wanted to add compiler support for non-nullable 
references, many
more things would need to be decided - how do they look? Do 
they assert
non-nullness upon initialization/assignment, or are external 
checks required?


Same problem exists with any type with @disable this.

Does new Foo() return a non-nullable reference? Must we also 
add scoped
non-nullness guarantees (if(foo != null) { /* foo is now 
implicitly

convertible to non-nullable */ })?



if reference are non nullables, this example don't make any sense.

So, no. The stuff required to add @disable this() to the 
language is not the
same that is required for non-nullable references. It's 
certainly an important
part of it, but there's still more left, and it's going to make 
the language
harder to implement. Adding a feature that lets non-nullable 
references be

added in a library is much better.


It is. Having everybody considering it isn't is probably why 
you'll find so much holes in NonNullable.

Re: Transition for removing functions from Object [Compiler devs in particular, please read]

[Kenji Hara]

2013/5/27 Jonathan M Davis 

> 1. You can't do UFCS with overloaded operators, and opEquals and opCmp are
> overloaded operators. In general, I think that it would be bad to be able
> to
> overload operators via UFCS (especially with functions that are as core as
> opEquals and opCmp), but if we could at least make it so that the compiler
> allowed it in this case until the deprecation process has been completed,
> then
> these functions could be UFCS-able.
>

Class objects and '==' (equality operation) is already treated specially.
Even if a class object has opEquals method (currently Object class has
opEquals, so it's always true), equality operation c1 == c2 is always
forwarded to object.opEquals(c1, c2). As well we can also forward
comparison operator to object.opCmp specially.


> 2. super doesn't work with UFCS. Take this code for example
>

As Lionello already mentioned, this is not an issue.

3. The override keyword makes it so that making those functions free
> functions
> will break all code everywhere that uses them. override is fantastic for
> catching changes in class hierarchies so that you can fix your code when
> base
> classes change, but it does not give us a good deprecation path. So, if we
> were to make these functions free functions, the compiler would have to be
> adjusted so that in this particular case, it gave a message about it (and
> not
> a warning, as that would cause code to break with -w) rather than giving an
> error. I do think that this _should_ give an error normally, as you'd no
> longer be overriding anything, but we need to be able to not make it an
> error
> in this case if we want a smooth transition. override is intended for
> catching
> bugs quite loudly and not for smooth deprecation paths.
>

In this case, compiler should stop reporting "does not override any
function" error.
If -w switch is on, the redundant override keyword usage would be warned.

Kenji Hara

Re: Why UTF-8/16 character encodings?

[David Eagen]

On Tuesday, 28 May 2013 at 01:38:22 UTC, Peter Williams wrote:



So you're going to spell check them all to make sure that 
they're English?  Or did you mean ASCII?


Peter


That's it. I'm filing a bug against std.traits. There's a 
unittest there that with a struct named "Colour". Completely 
unacceptable.

Re: Walter: htod on github?

[Diggory]

On Tuesday, 28 May 2013 at 02:32:24 UTC, Lionello Lunesu wrote:

Walter,

Any chance we can get the source of htod? If found it a very 
useful little utility, although there are many issues with it.


VisualD also include a similar utility to convert header files 
to D, but it is more tuned to Windows header files. Perhaps we 
can combine the two into a new utility?


Lio.


I think htod is based on dmc so open sourcing it would be a 
problem.

Re: More on "Component Programming"

[H. S. Teoh]

On Mon, May 27, 2013 at 07:35:36PM -0700, H. S. Teoh wrote:
> On Mon, May 27, 2013 at 10:01:32PM -0400, Andrei Alexandrescu wrote:
> > On 5/27/13 5:36 PM, bearophile wrote:
> > >This simple example shows the difference:
> > >
> > >import std.stdio, std.algorithm;
> > >void main() {
> > >auto data = [1, 2, 3, 4];
> > >foreach (xy; cartesianProduct(data, data))
> > >writeln(xy);
> > >}
> > >
> > >
> > >Generates the tuples:
> > >(1, 1)
> > >(2, 1)
> > >(3, 1)
> > >(4, 1)
> > >(1, 2)
> > >(2, 2)
> > >(3, 2)
> > >(4, 2)
> > >(1, 3)
> > >(2, 3)
> > >(3, 3)
> > >(4, 3)
> > >(1, 4)
> > >(2, 4)
> > >(3, 4)
> > >(4, 4)
> > 
> > I'm disappointed cartesianProduct works that way; I should have
> > caught that during the code review. A better iteration order would
> > have spanned the lower position in both ranges first, i.e. create
> > squares of increasing side in the 2D space.
> 
> This is not too hard to change; it's just a matter of swapping left-
> and right- recursion in the templates. I'll see if I can cook up an
> pull request in a bit.
[...]

Done, turns out the fix was trivial, just swapping two static ifs:

https://github.com/D-Programming-Language/phobos/pull/1314


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't 
seem to remove the bugs on my system! -- Mike Dresser

Re: Discussion of TypeTuple naming

[Diggory]

Using StaticTuple clearly and unambiguously refers to the alias
to a "..." template argument.


Right now, that's TypeTuple. The fact that Type is in the name 
means nothing
other than the fact that it was poorly named. I'm quite certain 
that a number
of the template-heavy projects out there use TypeTuple for 
expressions as well
as types. I know that I have. You pretty much have to if you 
want to use

expressions with static foreach.


because not so long ago I would
have assumed that when you said "built-in tuple" you meant
std.tuple.Tuple.


std.typecons.Tuple isn't built-in. It's in the standard 
library. When I say

built-in, I meant built into the language.


There's no point explaining it to me - I know what they are, and 
the only reason I know is because I've gone through and looked at 
the phobos code for both of them, something I shouldn't have to 
do.



If you introduce StaticTuple on top of TypeTuple, even without
ExpressionTuple, you now have three different tuple types to 
explain, whereas
now we only have two (which is already problematic enough). If 
you create an
alias from TypeTuple to StaticTuple, then you only really have 
two tuple
types, but you still have three of them in code, so you stil 
have to explain

three of them.


Sometimes explaining more things is better than explaining fewer 
things. Having recently gone through the process of learning 
about D tuples I can safely say that if instead "StaticTuple", 
"TypeTuple" and "Tuple" were explained it would have been much 
easier to understand.


Are you really arguing that the existing system is easier to 
understand?


A simple note that TypeTuple may be used in existing code to 
store non-types but that this usage is deprecated is enough to 
explain the entire situation to anyone, and even this is not 
necessary to remember unless you are specifically editing code 
written before StaticTuple.


The documentation on TypeTuple is just plain wrong, and anyone 
who uses it
much knows fulwell that it's wrong, so I consider it to be 
pretty much

irrelevant.


How on earth is anyone supposed to know this if the documentation 
is wrong without going through the code. IMO the reason D has had 
such limited uptake despite all of its positive features has 
nothing to do with being too unstable, it's because every 
possible barrier is put up against novice programmers getting 
started with the language. A language grows in popularity because 
new people start using it, not because company X decides it's now 
crossed some imaginary stability threshold.


There seems to be some illusion that being stable is about 
drawing a line and saying "from now on there will be no more code 
breakage". That's not being stable, that's not fixing problems 
with the language. A language is stable when sufficiently many of 
the problems that would require code changes have been fixed so 
that the remaining problems can be fixed without breaking code. 
The only possible outcome is either fixing the problems later 
which is worse because you break more code, or never being able 
to fix the problems satisfactorily (C++).



I think that the design of TypeTuple is perfectly sound - it's
merely a way to create the tuples which are built into the 
language. It's just
that a bad name was chosen. If we were willing to break code 
for name changes,
I'd argue for changing it to something like StaticTuple, but 
Walter and Andrei
are flat-out against that at this point. The ROI is too low for 
the amount of
breakage that it causes - especially with something as heavily 
used as
TypeTuple. If we were going to change the name, we should have 
changed it ages

ago.


What is the worst possible scenario if this change was 
implemented? Answer: some projects generate deprecation warnings 
until somebody can be bothered to press ctrl+H or *insert 
shortcut of your choice for replace all*. It won't actually break 
any code, so it's not a case of breaking code for name changes.


The questions after the most recent dconf talk discussed an 
automatic conversion tool for upgrading code, and most of the 
people concerned with breaking changes were happy for those 
changes to occur if it was no effort for them to update the code. 
In this case I am not even suggesting breaking code, plus it's 
possible to upgrade the code using an automated tool that 
everyone already has.


The benefits are significant. Maybe to someone who knows D inside 
out it doesn't matter but you have to cater to newcomers both now 
and in the future, not just existing users. If not, D will 
stagnate.


I don't think that it's going to be acceptable to do so now, 
and I don't
think that the confusion caused by adding an alias to it is an 
improvement.


IMO, StaticTuple + TypeTuple + Good documentation is less 
confusing than TypeTuple + Good documentation. Plus the former 
reflects better on the language. Seeing the former and reading 
about TypeTuple I would think D is a language where the problems 

Re: Transition for removing functions from Object [Compiler devs in particular, please read]

[Jonathan M Davis]

On Tuesday, May 28, 2013 10:28:34 Lionello Lunesu wrote:
> On 5/27/13 9:20, Jonathan M Davis wrote:
> > class D : C
> > {
> > 
> >  void foo() { writeln("D"); }
> >  void bar() { writeln(super.foo()); }
> > 
> > }
> 
> I think this works just fine, you just have to drop the writeln(). foo()
> doesn't return anything, but prints itself.
> 
> But yet, super should just work: it should be a variable of type C and
> treated as such.

Oh, you're right. Apparently, I wrote that up too quickly. So, my issue #2 
isn't a problem. super will work with UFCS. But that still leaves #1 and #3.

- Jonathan M Davis

Re: More on "Component Programming"

[Jonathan M Davis]

On Tuesday, May 28, 2013 03:50:48 bearophile wrote:
> Peter Williams:
> > Are the () necessary on sort?
> 
> If you don't use () I think you call the slower, not flexible and
> buggy built-in sort. I think it's already deprecated. Maybe I am
> wrong...

If it's on an array, then yes, I believe that calling sort without parens 
would call the built-in one that should be deprecated.

- Jonathan M Davis

Walter: A small request for this upcoming release's installer

[Brad Anderson]

(Sorry for the NG noise, I would have just emailed you directly 
about this but I couldn't manage to find your email address)


Could you use the AWS hosted URLs for the zip files in the 
windows installer script?  It takes around 5-10 minutes to 
install from the ftp.digitalmars.com URLs.


Thanks.

Re: More on "Component Programming"

[H. S. Teoh]

On Mon, May 27, 2013 at 10:01:32PM -0400, Andrei Alexandrescu wrote:
> On 5/27/13 5:36 PM, bearophile wrote:
> >This simple example shows the difference:
> >
> >import std.stdio, std.algorithm;
> >void main() {
> >auto data = [1, 2, 3, 4];
> >foreach (xy; cartesianProduct(data, data))
> >writeln(xy);
> >}
> >
> >
> >Generates the tuples:
> >(1, 1)
> >(2, 1)
> >(3, 1)
> >(4, 1)
> >(1, 2)
> >(2, 2)
> >(3, 2)
> >(4, 2)
> >(1, 3)
> >(2, 3)
> >(3, 3)
> >(4, 3)
> >(1, 4)
> >(2, 4)
> >(3, 4)
> >(4, 4)
> 
> I'm disappointed cartesianProduct works that way; I should have
> caught that during the code review. A better iteration order would
> have spanned the lower position in both ranges first, i.e. create
> squares of increasing side in the 2D space.

This is not too hard to change; it's just a matter of swapping left- and
right- recursion in the templates. I'll see if I can cook up an pull
request in a bit.


T

-- 
It only takes one twig to burn down a forest.

Walter: htod on github?

[Lionello Lunesu]

Walter,

Any chance we can get the source of htod? If found it a very useful 
little utility, although there are many issues with it.


VisualD also include a similar utility to convert header files to D, but 
it is more tuned to Windows header files. Perhaps we can combine the two 
into a new utility?


Lio.

Re: Transition for removing functions from Object [Compiler devs in particular, please read]

[Lionello Lunesu]

On 5/27/13 9:20, Jonathan M Davis wrote:

class D : C
{
 void foo() { writeln("D"); }
 void bar() { writeln(super.foo()); }
}


I think this works just fine, you just have to drop the writeln(). foo() 
doesn't return anything, but prints itself.


But yet, super should just work: it should be a variable of type C and 
treated as such.


L.

Re: More on "Component Programming"

[Walter Bright]

On 5/27/2013 5:16 PM, bearophile wrote:

There are several optimizations that D/DMD is not performing on those ranges and
higher order functions. The Haskell compiler GHC optimized that stuff using
purity, library defined "rewrite rules", stream fusion/deforestation and more.
DMD does nothing of this, or very little. I think so far Walter has shown no
interest in this.


I don't really know what you're talking about.

Re: More on "Component Programming"

[bearophile]

Andrei Alexandrescu:

We need to fix that! std.algorithm.sort should include builtin 
sort's functionality,


What is the missing functionality we are talking about?
I think the only advantage of the built-in sort is that it causes 
less template bloat and less compilation time.


Anyway, I'd like to see a warning or deprecation for the built-in 
sort soon... Unless you/we want to un-deprecate it and fix it 
better. Keeping several things for lot of time in a 
"will-be-deprecated" limbo doesn't sound good for a serious 
language.


Bye,
bearophile

Re: More on "Component Programming"

[Andrei Alexandrescu]

On 5/27/13 9:30 PM, Peter Williams wrote:

On 28/05/13 10:37, bearophile wrote:

.map!(words => words
.classify!q{ a
.dup
.representation
.sort()
.release


Also, let's kill the built-in sort already :-)



But I just found it and started using it. :-)

I was contemplating writing my own sort function as the ones in
std.algorithm didn't meet my needs (or using them was too messy) until I
discovered this feature.


We need to fix that! std.algorithm.sort should include builtin sort's 
functionality,


Andrei

Re: More on "Component Programming"

[bearophile]

Andrei Alexandrescu:

I'm disappointed cartesianProduct works that way; I should have 
caught that during the code review. A better iteration order 
would have spanned the lower position in both ranges first, 
i.e. create squares of increasing side in the 2D space.


I opened this:
http://d.puremagic.com/issues/show_bug.cgi?id=9878

Bye,
bearophile

Re: DLang Spec rewrite (?)

[Andrei Alexandrescu]

On 5/27/13 9:32 PM, Jonathan M Davis wrote:

On Monday, May 27, 2013 21:29:41 Andrei Alexandrescu wrote:

On 5/27/13 6:48 PM, Borden wrote:

Oh, and another thing: XHTML adopts the XML practice of only defining
the lt, gt and amp entities and no others (like nbsp, mdash, accented,
or non-Latin characters).

Since Unicode is, by and large, universal, I've read that the
recommended practice for including characters not on a standard US
keyboard is to copy them from a character map and save the file in a
Unicode encoding. I intend to follow this guidance in writing the
(x)html.ddoc template.

As such, should I keep the existing 'entity' macros or use the Unicode
characters in the DLang spec source files? I imagine that Andrei will
immediately comment that .tex files are supposed to be in ASCII.
Suggestions?


The LaTeX configuration won't use your ddoc template. Knock yourself out.


Yes, but he was wondering if he could change the .dd files to use Unicode
characters directly instead of macros, which _would_ affect the LaTeX
configuration.


Prolly that wouldn't be a good idea. Macros are the traditional level of 
indirection that solve all problems...


Andrei

Re: More on "Component Programming"

[Andrei Alexandrescu]

On 5/27/13 5:36 PM, bearophile wrote:

This simple example shows the difference:

import std.stdio, std.algorithm;
void main() {
auto data = [1, 2, 3, 4];
foreach (xy; cartesianProduct(data, data))
writeln(xy);
}


Generates the tuples:
(1, 1)
(2, 1)
(3, 1)
(4, 1)
(1, 2)
(2, 2)
(3, 2)
(4, 2)
(1, 3)
(2, 3)
(3, 3)
(4, 3)
(1, 4)
(2, 4)
(3, 4)
(4, 4)


I'm disappointed cartesianProduct works that way; I should have caught 
that during the code review. A better iteration order would have spanned 
the lower position in both ranges first, i.e. create squares of 
increasing side in the 2D space.


Andrei

Re: More on "Component Programming"

[bearophile]

Peter Williams:


Are the () necessary on sort?


If you don't use () I think you call the slower, not flexible and 
buggy built-in sort. I think it's already deprecated. Maybe I am 
wrong...



PS Now I've found this I can go back and simplify all the code 
where I iterated over associative arrays in key order by 
getting the keys and the sorting them separately.


I don't fully understand.

Bye,
bearophile

Re: More on "Component Programming"

[Andrei Alexandrescu]

On 5/27/13 8:16 PM, bearophile wrote:

The "group" of Phobos is useful and it has purposes quite different from
the Perl6 "classify", both are needed.
I have also suggested "group" to act more like the Python
"itertools.grouby" and yield not just the (head,count) tuples, but
(head,lazy_range_of_the_equality_ class) that is quite useful, example:



from itertools import groupby
s = "abABACABCAB"
[(h, list(g)) for h,g in groupby(s, key=str.isupper)]

[(False, ['a', 'b']), (True, ['A', 'B', 'A', 'C', 'A']), (False, ['a',
'a', 'a', 'a']), (True, ['B', 'C', 'A', 'B'])]

I think Andrei was looking at this change with interest. Changing Phobos
group() API now is maybe not easy to do, so maybe it's better to
introduce a differently named function for that, like one named
"groupAll" or something similar.


I wrote that a while ago. Someone please review and pull 
https://github.com/D-Programming-Language/phobos/pull/1186 already!



Andrei

Re: Why UTF-8/16 character encodings?

[Jonathan M Davis]

On Tuesday, May 28, 2013 11:38:08 Peter Williams wrote:
> On 28/05/13 09:44, H. S. Teoh wrote:
> > Since language keywords are already in English, we might as well
> > standardize on English identifiers too.
> 
> So you're going to spell check them all to make sure that they're
> English?  Or did you mean ASCII?

I think that it was more an issue of that the only reason that Unicode would 
be necessary in identifiers would be if you weren't using English, so if you 
assume that everyone is going to be using some form of English for their 
identifier names, you can skip having Unicode in identifiers. So, a natural 
effect of standardizing on English is that you can stick with ASCII.

- Jonathan M Davis

Re: DLang Spec rewrite (?)

[Borden]

Yep, and that seems like a bad idea, so I'll just update the 
macros is the xhtml.ddoc file

Re: Why UTF-8/16 character encodings?

[Peter Williams]

On 28/05/13 09:44, H. S. Teoh wrote:


Since language keywords are already in English, we might as well
standardize on English identifiers too.


So you're going to spell check them all to make sure that they're 
English?  Or did you mean ASCII?


Peter

Re: Why UTF-8/16 character encodings?

[Walter Bright]

On 5/27/2013 6:06 PM, H. S. Teoh wrote:

I don't find this a compelling reason to allow full Unicode on
identifiers, though. For one thing, somebody maintaining your code may
not know how to type said identifier correctly. It can be very
frustrating to have to keep copy-n-pasting identifiers just because they
contain foreign letters you can't type. Not to mention sheer
unreadability if the inventor's name is in Chinese, so the algorithm
name is also in Chinese, and the person maintaining the code can't read
Chinese. This will kill D code maintainability.


+1

Re: Why UTF-8/16 character encodings?

[Walter Bright]

On 5/27/2013 5:34 PM, Manu wrote:

On 28 May 2013 09:05, Walter Bright mailto:newshou...@digitalmars.com>> wrote:

On 5/27/2013 3:18 PM, H. S. Teoh wrote:

Well, D *does* support non-English identifiers, y'know... for example:

 void main(string[] args) {
 int число = 1;
 foreach (и; 0..100)
 число += и;
 writeln(число);
 }

Of course, whether that's a good practice is a different story. :)


I've recently come to the opinion that that's a bad idea, and D should not
support it.


Why? You said previously that you'd love to support extended operators ;)


Extended operators, yes. Non-ascii identifiers, no.

Re: More on "Component Programming"

[Jonathan M Davis]

On Tuesday, May 28, 2013 11:30:55 Peter Williams wrote:
> Are the () necessary on sort?  I found:
> 
> auto sorted_array = an_array.dup.sort;

Any function which takes no arguments can be called without parens, and thanks 
to UFCS (Universal Function Call Syntax), you're calling these functions as if 
they were member functions and so they no longer have any arguments between 
the parens and so can be called without parens.

- Jonathan M Davis

Re: DLang Spec rewrite (?)

[Jonathan M Davis]

On Monday, May 27, 2013 21:29:41 Andrei Alexandrescu wrote:
> On 5/27/13 6:48 PM, Borden wrote:
> > Oh, and another thing: XHTML adopts the XML practice of only defining
> > the lt, gt and amp entities and no others (like nbsp, mdash, accented,
> > or non-Latin characters).
> > 
> > Since Unicode is, by and large, universal, I've read that the
> > recommended practice for including characters not on a standard US
> > keyboard is to copy them from a character map and save the file in a
> > Unicode encoding. I intend to follow this guidance in writing the
> > (x)html.ddoc template.
> > 
> > As such, should I keep the existing 'entity' macros or use the Unicode
> > characters in the DLang spec source files? I imagine that Andrei will
> > immediately comment that .tex files are supposed to be in ASCII.
> > Suggestions?
> 
> The LaTeX configuration won't use your ddoc template. Knock yourself out.

Yes, but he was wondering if he could change the .dd files to use Unicode 
characters directly instead of macros, which _would_ affect the LaTeX 
configuration.

- Jonathan M Davis

Re: More on "Component Programming"

[Peter Williams]

On 28/05/13 10:37, bearophile wrote:

.map!(words => words
   .classify!q{ a
.dup
.representation
.sort()
.release


Also, let's kill the built-in sort already :-)



But I just found it and started using it. :-)

I was contemplating writing my own sort function as the ones in 
std.algorithm didn't meet my needs (or using them was too messy) until I 
discovered this feature.


Are the () necessary on sort?  I found:

auto sorted_array = an_array.dup.sort;

worked.

Peter
PS Now I've found this I can go back and simplify all the code where I 
iterated over associative arrays in key order by getting the keys and 
the sorting them separately.

PPS Every time I discover one of these features I like D even more.

Re: DLang Spec rewrite (?)

[Andrei Alexandrescu]

On 5/27/13 6:48 PM, Borden wrote:

Oh, and another thing: XHTML adopts the XML practice of only defining
the lt, gt and amp entities and no others (like nbsp, mdash, accented,
or non-Latin characters).

Since Unicode is, by and large, universal, I've read that the
recommended practice for including characters not on a standard US
keyboard is to copy them from a character map and save the file in a
Unicode encoding. I intend to follow this guidance in writing the
(x)html.ddoc template.

As such, should I keep the existing 'entity' macros or use the Unicode
characters in the DLang spec source files? I imagine that Andrei will
immediately comment that .tex files are supposed to be in ASCII.
Suggestions?


The LaTeX configuration won't use your ddoc template. Knock yourself out.

Andrei

Re: More on "Component Programming"

[H. S. Teoh]

On Tue, May 28, 2013 at 02:16:22AM +0200, bearophile wrote:
> Sebastian Graf:
> 
> >Plus, the compiler is still able to optimize most of the
> >delegate/range fluff away (as opposed to e.g. C#).
> 
> There are several optimizations that D/DMD is not performing on
> those ranges and higher order functions. The Haskell compiler GHC
> optimized that stuff using purity, library defined "rewrite rules",
> stream fusion/deforestation and more.

Library-defined rewrite rules would be über-cool if it were supported in
D.

*(waits for somebody to mention "AST macros", and everyone else to shout
him down. :-P)


> DMD does nothing of this, or very little. I think so far Walter has
> shown no interest in this.
[...]

The DMD optimizer certainly leaves a lot of room for improvement. I
think Walter would accept pull requests to that effect. ;-)


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz

Re: dlang.org/posix.mak dependencies

[Jonathan M Davis]

On Tuesday, May 28, 2013 03:05:26 Borden wrote:
> The thing, though, is that, unless I've misread the makefile,
> dlang.org doesn't have any code that needs compiling. All it
> needs DMD for is to generate the documentation (which, I'm
> presuming, can be accomplished by the most current released
> version)

Maybe. Probably. But it's not guaranteed.

> and generate the docfiles for the Phobos libraries
> (which, I'm guessing, should be compiled against a current
> release of the libraries).

IIRC, it compiles both the most recent release and the current git master. To 
do that, it needs all of the latest stuff. The odds of it working with the 
released compiler rather than the one in git master are far, far higher than 
they used to be, but it still may not work some of the time.

- Jonathan M Davis

Re: Why UTF-8/16 character encodings?

[H. S. Teoh]

On Tue, May 28, 2013 at 02:54:30AM +0200, Torje Digernes wrote:
> On Tuesday, 28 May 2013 at 00:34:20 UTC, Manu wrote:
> >On 28 May 2013 09:05, Walter Bright 
> >wrote:
> >
> >>On 5/27/2013 3:18 PM, H. S. Teoh wrote:
> >>
> >>>Well, D *does* support non-English identifiers, y'know... for
> >>>example:
> >>>
> >>>void main(string[] args) {
> >>>int число = 1;
> >>>foreach (и; 0..100)
> >>>число += и;
> >>>writeln(число);
> >>>}
> >>>
> >>>Of course, whether that's a good practice is a different
> >>>story. :)
> >>>
> >>
> >>I've recently come to the opinion that that's a bad idea, and D
> >>should not
> >>support it.
> >>
> >
> >Why? You said previously that you'd love to support extended
> >operators ;)
> 
> I find features such as support for uncommon symbols in variables a
> strength as it makes some physics formulas a bit easier to read in
> code form, which in my opinion is a good thing.

I think there's a difference between allowing math symbols (which
includes things like (a subset of) Greek letters that mathematicians
love) in identifiers, and allowing full Unicode. What if you're assigned
to maintain code containing identifiers that has letters that don't
appear in any of your installed fonts?

I think it's OK to allow math symbols, but allowing the entire set of
Unicode characters is going a bit too far, IMO. For one thing, if some
code has identifiers written in Arabic, I wouldn't be able to understand
the code, simply because I'd have a hard time telling different
identifiers apart.  Besides, if the rest of the language (keywords,
Phobos, etc.) are in English, then I don't see any compelling reason to
use a different language in identifiers, other than to submit IODCC
entries. :-P

C doesn't support Unicode identifiers, for one thing, but I've seen
working C code written by people who barely understand any English -- it
didn't stop them at all. (The comments were of course in their native
language -- the compiler ignores everything inside anyway so 8-bit
native encodings or even UTF-8 can be sneaked in without provoking
compiler errors.)


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

Re: dlang.org/posix.mak dependencies

[Borden]

On Tuesday, 28 May 2013 at 00:50:04 UTC, Jonathan M Davis wrote:

On Tuesday, May 28, 2013 02:14:06 Borden wrote:

Good evening, all,

I'm making a new thread on this because my question isn't
strictly related to the DDoc issues I've mentioned in earlier
threads. Rather, it has to do with the dependencies of the
posix.mak file in the dlang.org repo (on GitHub, for greater
clarity):

posix.mak, beginning at line 236, compiles local copies of DMD,
DRuntime and Phobos. Is all of this extra compilation really
necessary for someone who, presumably, already installed D 
using

the installer packages?

Wouldn't it be more reasonable to see if the most current 
version

of DMD is installed and, if not, panic out and tell the user to
go and fetch the latest copy from the website? Then the rest of
the makefile could use the installed copies on the user's
computer rather than download and recompile them?

This question is specific to the dlang.org repo and NOT to any
other repos hosted at GitHub.


It's a bad idea to assume that a released version of dmd and 
Phobos will work
with the current git repos. It's far less of an issue than it 
used to be, but
breaking changes still happen (some of which are regressions 
and get fixed and
some of which are on purpose), and there's no guarantee that 
there haven't
been changes which require that you have the latest of 
everything in order to

build the git versions.

- Jonathan M Davis


Good evening, Jonathan,

The thing, though, is that, unless I've misread the makefile, 
dlang.org doesn't have any code that needs compiling. All it 
needs DMD for is to generate the documentation (which, I'm 
presuming, can be accomplished by the most current released 
version) and generate the docfiles for the Phobos libraries 
(which, I'm guessing, should be compiled against a current 
release of the libraries).

Re: Why UTF-8/16 character encodings?

[H. S. Teoh]

On Tue, May 28, 2013 at 02:23:32AM +0200, Diggory wrote:
> On Tuesday, 28 May 2013 at 00:11:18 UTC, Walter Bright wrote:
> >On 5/27/2013 4:28 PM, Hans W. Uhlig wrote:
> >>On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
> >>>I've recently come to the opinion that that's a bad idea, and
> >>>D should not
> >>>support it.
> >>
> >>Why do you think its a bad idea? It makes it such that code can
> >>be in various
> >>languages? Just lack of keyboard support?
> >
> >Every time I've been to a programming shop in a foreign country,
> >the developers speak english at work and code in english. Of
> >course, that doesn't mean that everyone does, but as far as I can
> >tell the overwhelming bulk is done in english.
> >
> >Naturally, full Unicode needs to be in strings and comments, but
> >symbol names? I don't see the point nor the utilty of it.
> >Supporting such is just pointless complexity to the language.
> 
> The most convincing case for usefulness I've seen was in java where
> a class implemented a particular algorithm and so was named after
> it. This name had a particular accented character and so required
> unicode. Lots of algorithms are named after their inventors and lots
> of these names contain unicode characters so it's not that uncommon.

I don't find this a compelling reason to allow full Unicode on
identifiers, though. For one thing, somebody maintaining your code may
not know how to type said identifier correctly. It can be very
frustrating to have to keep copy-n-pasting identifiers just because they
contain foreign letters you can't type. Not to mention sheer
unreadability if the inventor's name is in Chinese, so the algorithm
name is also in Chinese, and the person maintaining the code can't read
Chinese. This will kill D code maintainability.


T

-- 
Don't drink and derive. Alcohol and algebra don't mix.

Re: DLang Spec rewrite (?)

[H. S. Teoh]

On Mon, May 27, 2013 at 05:30:27PM -0700, Jonathan M Davis wrote:
[...]
> Well, it's more user-friendly to have macros for Unicode than having
> to figure out how to input the actual Unicode character in there
> (since it's not on the keyboard), and it's trivial to turn the macro
> into the actual character with the macro, so I'd think that it would
> be more user-friendly to just use the macros, especially if we're
> already using them. And if laTeX has to be ASCII (I don't know if it
> has to be or not), then that's all the more reason to not use Unicode
> directly. But regardless, if we're already using macros, why bother
> changing it? Just change what the macros convert to in the XHTML
> generation.
[...]

Plain vanilla LaTeX assumes ASCII input, and will do odd things if fed
8-bit data (much less UTF-8). I think macros for HTML entities is the
way to go, given the current setup.

However, it is not a straightforward 1-to-1 mapping between &entity; and
macro; to truly support LaTeX properly, one should be aware of some of
its idiosyncrasies. For example, in Unicode, a character like ẃ can be
represented by w *followed* by a combining diacritic; in LaTeX, however,
the combining diacritic must *precede* the modified character (that is,
\'w). So such characters should be represented by a single macro, say
$(WACUTE), rather than w followed by a general $(ACUTE), which will be
impossible to translate to LaTeX correctly.

LaTeX also has some special sequences for different kinds of spacings:
an abbreviation like "Mr." requires the interspersing space to be
escaped, i.e., "Mr.\ X", otherwise it will treat the "." as a sentence
terminator and give it an overly-wide space in the output. This may make
it a bit annoying to write in Ddoc, though, 'cos you'll need a macro of
some sort to indicate this non-terminating ".".

The correct way to represent quotation marks in LaTeX is `` and '' for
double quotes, and ` and ' for single quotes. Writing " or ' will still
work, but it will just be ugly in the output.

If there are math formulae involved, then they need to be enclosed with
$, for example: "This sentence contains $2+2=4$ words." Inside math
formulae, a slightly different syntax is used, but for the purposes of
Ddoc, I think that can probably be ignored for now.

A bunch of metacharacters need to be escaped; I can't recall the list
off the top of my head, but they include at the very least:

~ # $ % ^ & { } _ \

The escape sequences required for these metacharacters are not all
obvious; for example, \\ is NOT an escaped backslash, it's a linebreak.
I forgot what a literal backslash is... And \^ is NOT a literal caret;
it's a circumflex accent on the next letter; ditto with \~. Though IIRC
\$ does represent a literal $. So, some care is required to make things
work correctly. :)


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- 
Sammy

Re: Why UTF-8/16 character encodings?

[Torje Digernes]

On Tuesday, 28 May 2013 at 00:34:20 UTC, Manu wrote:
On 28 May 2013 09:05, Walter Bright 
 wrote:



On 5/27/2013 3:18 PM, H. S. Teoh wrote:

Well, D *does* support non-English identifiers, y'know... for 
example:


void main(string[] args) {
int число = 1;
foreach (и; 0..100)
число += и;
writeln(число);
}

Of course, whether that's a good practice is a different 
story. :)




I've recently come to the opinion that that's a bad idea, and 
D should not

support it.



Why? You said previously that you'd love to support extended 
operators ;)


I find features such as support for uncommon symbols in variables 
a strength as it makes some physics formulas a bit easier to read 
in code form, which in my opinion is a good thing.

Re: dlang.org/posix.mak dependencies

[Jonathan M Davis]

On Tuesday, May 28, 2013 02:14:06 Borden wrote:
> Good evening, all,
> 
> I'm making a new thread on this because my question isn't
> strictly related to the DDoc issues I've mentioned in earlier
> threads. Rather, it has to do with the dependencies of the
> posix.mak file in the dlang.org repo (on GitHub, for greater
> clarity):
> 
> posix.mak, beginning at line 236, compiles local copies of DMD,
> DRuntime and Phobos. Is all of this extra compilation really
> necessary for someone who, presumably, already installed D using
> the installer packages?
> 
> Wouldn't it be more reasonable to see if the most current version
> of DMD is installed and, if not, panic out and tell the user to
> go and fetch the latest copy from the website? Then the rest of
> the makefile could use the installed copies on the user's
> computer rather than download and recompile them?
> 
> This question is specific to the dlang.org repo and NOT to any
> other repos hosted at GitHub.

It's a bad idea to assume that a released version of dmd and Phobos will work 
with the current git repos. It's far less of an issue than it used to be, but 
breaking changes still happen (some of which are regressions and get fixed and 
some of which are on purpose), and there's no guarantee that there haven't 
been changes which require that you have the latest of everything in order to 
build the git versions.

- Jonathan M Davis

Re: DMD source violates c++11 standards.

[Jonathan M Davis]

On Tuesday, May 28, 2013 02:15:39 Borden wrote:
> I was thinking about that: surely D's mature enough that dmd can
> be written in D?

Work is being done to convert it to D, but there's a fair bit of work to do 
for it to happen (like improving what extern(C++) can do so that it can better 
integrate with the various backends).

- Jonathan M Davis

Re: Discussion of TypeTuple naming

[Jonathan M Davis]

On Tuesday, May 28, 2013 00:23:08 Diggory wrote:
> On Monday, 27 May 2013 at 19:30:18 UTC, Jonathan M Davis wrote:
> > Yeah. The only problem I see is the name. I don't see any real
> > benefit in making it so that we have _three_ different types of
> > compile time tuples, particularly when their uses tend to be
> > fairly localized rather than being passed around through APIs
> > and the like (if they get passed through APIs, they'd just be
> > template or function argument lists), and any mismatch of types
> > and expressions will result in an error pretty much instantly.
> 
> Three? I am suggesting TWO, "StaticTuple" and "TypeTuple" with
> further additions for a future discussion.

I thought that you were suggesting ExpressionTuple on top of the other two. 
Regardless, I see no reason to add yet more tuple types. Two is plenty. It's 
just that the name for TypeTuple sucks, because it's used for more than just 
types and arguably isn't a tuple to begin with (since it doesn't have 
nesting).

> Using StaticTuple clearly and unambiguously refers to the alias
> to a "..." template argument.

Right now, that's TypeTuple. The fact that Type is in the name means nothing 
other than the fact that it was poorly named. I'm quite certain that a number 
of the template-heavy projects out there use TypeTuple for expressions as well 
as types. I know that I have. You pretty much have to if you want to use 
expressions with static foreach.

> because not so long ago I would
> have assumed that when you said "built-in tuple" you meant
> std.tuple.Tuple.

std.typecons.Tuple isn't built-in. It's in the standard library. When I say 
built-in, I meant built into the language.

> > The name sucks, but I think that we're stuck with it at this
> > point. For it to be worth it, we'd have to be willing to force
> > everyone to change their code to use the new name, and for the
> > most part, we're just not doing that sort of thing anymore.
> 
> This makes no sense. All of the benefits of StaticTuple come
> without changing any existing code except for in phobos itself,
> in particular a logical naming system which actually matches the
> existing documentation.

If you introduce StaticTuple on top of TypeTuple, even without 
ExpressionTuple, you now have three different tuple types to explain, whereas 
now we only have two (which is already problematic enough). If you create an 
alias from TypeTuple to StaticTuple, then you only really have two tuple 
types, but you still have three of them in code, so you stil have to explain 
three of them.

The documentation on TypeTuple is just plain wrong, and anyone who uses it 
much knows fulwell that it's wrong, so I consider it to be pretty much 
irrelevant. I think that the design of TypeTuple is perfectly sound - it's 
merely a way to create the tuples which are built into the language. It's just 
that a bad name was chosen. If we were willing to break code for name changes, 
I'd argue for changing it to something like StaticTuple, but Walter and Andrei 
are flat-out against that at this point. The ROI is too low for the amount of 
breakage that it causes - especially with something as heavily used as 
TypeTuple. If we were going to change the name, we should have changed it ages 
ago. I don't think that it's going to be acceptable to do so now, and I don't 
think that the confusion caused by adding an alias to it is an improvement. 
And I definitely don't think that trying to split out TypeTuple into a tuple 
that actually is a way to use the built-in tuple (like it is now) and one that 
only takes types is an improvement.

So, I agree that the name sucks, and it would be great if we could change it, 
but at this point, I think that we're stuck, and we obviously need to fix the 
documentation to clarify it.

- Jonathan M Davis

Re: Rust-based provocation :)

[Adam D. Ruppe]

On Monday, 27 May 2013 at 17:51:33 UTC, Dicebot wrote:
Looking at object.d source, it looks like you are generating 
TypeInfo stubs that can be optimized away, have I understood it 
right?


I'm not sure if they can be optimized away, but all I was doing 
is putting the bare minimum so the compiler would shut up.


P.S. I can't get to run your "minimal.zip" example because of 
"object.d(87): Error: mismatch between compiler and object.d or 
object.di found." which does not really make sense in scope of 
line 87. Any ideas? Have changes all relevant stuff from x32 to 
x64 as far as I can see.



Hmm I already modified the file I have locally. I'll update the 
zip but I don't think this will work in 64 bit anyway because the 
syscall functions are all written in 32 bit inline asm. (I've 
never written a 64 bit asm program so I'm not even sure what the 
calling convention would look like there. If you ripped that out 
and used C functions instead, with an extern(C) main even maybe, 
you might be in business though.)


I think line 87 was one of the TypeInfos though, and dmd expects 
them to be a particular size, and it is slightly different on 64 
bit. If it is TypeInfo_Struct, on 32 bit void*[13] stuff; is good 
enough for dmd to shut up.


I believe on 64 bit it expects two more words, so void*[15] stuff 
should be good enough.


this should be updated and hitting "make" worked on my box, 
building 32 bit, with the test program being a bit of class 
stuff. The write() and exit() functions are moved to object.d 
right now, along with a dead stupid "allocator" that gives you a 
pointer to a static buffer (that it never frees) to play with new 
class. If you are using libc, malloc/free should be able to do 
the job instead, see the manual_alloc and manual_free stubs in 
object.d


http://arsdnet.net/dcode/minimal.zip

Re: More on "Component Programming"

[bearophile]

.map!(words => words
   .classify!q{ a
.dup
.representation
.sort()
.release


Also, let's kill the built-in sort already :-)

Bye,
bearophile

Re: Why UTF-8/16 character encodings?

[Manu]

On 28 May 2013 09:39, "@puremagic.com <
"\"Luís".Marques"> wrote:

> On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
>
>> I've recently come to the opinion that that's a bad idea, and D should
>> not support it.
>>
>
> I think it is a bad idea to program in a language other than english, but
> I believe D should still support it.
>

I can imagine a young student learning to code, that may not speak English
(yet).
Or a not-so-unlikely future where we're all speaking chinese ;)

Re: Why UTF-8/16 character encodings?

[Manu]

On 28 May 2013 09:05, Walter Bright  wrote:

> On 5/27/2013 3:18 PM, H. S. Teoh wrote:
>
>> Well, D *does* support non-English identifiers, y'know... for example:
>>
>> void main(string[] args) {
>> int число = 1;
>> foreach (и; 0..100)
>> число += и;
>> writeln(число);
>> }
>>
>> Of course, whether that's a good practice is a different story. :)
>>
>
> I've recently come to the opinion that that's a bad idea, and D should not
> support it.
>

Why? You said previously that you'd love to support extended operators ;)

Re: DLang Spec rewrite (?)

[Jonathan M Davis]

On Tuesday, May 28, 2013 00:48:02 Borden wrote:
> Oh, and another thing: XHTML adopts the XML practice of only
> defining the lt, gt and amp entities and no others (like nbsp,
> mdash, accented, or non-Latin characters).
> 
> Since Unicode is, by and large, universal, I've read that the
> recommended practice for including characters not on a standard
> US keyboard is to copy them from a character map and save the
> file in a Unicode encoding. I intend to follow this guidance in
> writing the (x)html.ddoc template.
> 
> As such, should I keep the existing 'entity' macros or use the
> Unicode characters in the DLang spec source files? I imagine that
> Andrei will immediately comment that .tex files are supposed to
> be in ASCII. Suggestions?

Well, it's more user-friendly to have macros for Unicode than having to figure 
out how to input the actual Unicode character in there (since it's not on the 
keyboard), and it's trivial to turn the macro into the actual character with 
the macro, so I'd think that it would be more user-friendly to just use the 
macros, especially if we're already using them. And if laTeX has to be ASCII 
(I don't know if it has to be or not), then that's all the more reason to not 
use Unicode directly. But regardless, if we're already using macros, why 
bother changing it? Just change what the macros convert to in the XHTML 
generation.

- Jonathan M Davis

Re: Why UTF-8/16 character encodings?

[Diggory]

On Tuesday, 28 May 2013 at 00:11:18 UTC, Walter Bright wrote:

On 5/27/2013 4:28 PM, Hans W. Uhlig wrote:

On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
I've recently come to the opinion that that's a bad idea, and 
D should not

support it.


Why do you think its a bad idea? It makes it such that code 
can be in various

languages? Just lack of keyboard support?


Every time I've been to a programming shop in a foreign 
country, the developers speak english at work and code in 
english. Of course, that doesn't mean that everyone does, but 
as far as I can tell the overwhelming bulk is done in english.


Naturally, full Unicode needs to be in strings and comments, 
but symbol names? I don't see the point nor the utilty of it. 
Supporting such is just pointless complexity to the language.


The most convincing case for usefulness I've seen was in java 
where a class implemented a particular algorithm and so was named 
after it. This name had a particular accented character and so 
required unicode. Lots of algorithms are named after their 
inventors and lots of these names contain unicode characters so 
it's not that uncommon.

Re: More on "Component Programming"

[bearophile]

Sebastian Graf:

Plus, the compiler is still able to optimize most of the 
delegate/range fluff away (as opposed to e.g. C#).


There are several optimizations that D/DMD is not performing on 
those ranges and higher order functions. The Haskell compiler GHC 
optimized that stuff using purity, library defined "rewrite 
rules", stream fusion/deforestation and more. DMD does nothing of 
this, or very little. I think so far Walter has shown no interest 
in this.



I'm all for more algorithm primitives in std.algorithm. I 
missed classify often enough and coming from a C# backgroung I 
was confused that std.algorithm.group did not what I thought it 
did.


and coming from a C# backgroung I was confused that 
std.algorithm.group did not what I thought it did.


The "group" of Phobos is useful and it has purposes quite 
different from the Perl6 "classify", both are needed.
I have also suggested "group" to act more like the Python 
"itertools.grouby" and yield not just the (head,count) tuples, 
but (head,lazy_range_of_the_equality_ class) that is quite 
useful, example:




from itertools import groupby
s = "abABACABCAB"
[(h, list(g)) for h,g in groupby(s, key=str.isupper)]
[(False, ['a', 'b']), (True, ['A', 'B', 'A', 'C', 'A']), (False, 
['a', 'a', 'a', 'a']), (True, ['B', 'C', 'A', 'B'])]


I think Andrei was looking at this change with interest. Changing 
Phobos group() API now is maybe not easy to do, so maybe it's 
better to introduce a differently named function for that, like 
one named "groupAll" or something similar.



Is there any reason why you keep using quoted strings instead 
of string literals for lambdas besides taste?


My editor uses a single uniform color for the contents of normal 
strings, unlike quoted strings.


Bye,
bearophile

Re: DMD source violates c++11 standards.

[Borden]

On Tuesday, 28 May 2013 at 00:12:57 UTC, Walter Bright wrote:

On 5/27/2013 4:47 PM, Daniel Murphy wrote:

"Hans W. Uhlig"  wrote in message
news:idtvbddofuxwpsbto...@forum.dlang.org...

This also makes compiling LDC with clang rather difficult



DMD is not written in C++11.  Turning of the C++11 warnings in 
clang will

fix this problem.




Also, you can submit a bugzilla entry for it, or even a pull 
request. There's no reason for such code in DMD to remain.


I was thinking about that: surely D's mature enough that dmd can 
be written in D?

Re: DMD source violates c++11 standards.

[Ziad Hatahet]

On Mon, May 27, 2013 at 4:47 PM, Daniel Murphy wrote:

> DMD is not written in C++11.  Turning of the C++11 warnings in clang will
> fix this problem


True, but could it not be the case that, since there might be stricter type
checking included, certain errors might show up? Like the example above,
where a switch is being done on an unsigned type, and negative cases are
being handled.

--
Ziad

dlang.org/posix.mak dependencies

[Borden]

Good evening, all,

I'm making a new thread on this because my question isn't 
strictly related to the DDoc issues I've mentioned in earlier 
threads. Rather, it has to do with the dependencies of the 
posix.mak file in the dlang.org repo (on GitHub, for greater 
clarity):


posix.mak, beginning at line 236, compiles local copies of DMD, 
DRuntime and Phobos. Is all of this extra compilation really 
necessary for someone who, presumably, already installed D using 
the installer packages?


Wouldn't it be more reasonable to see if the most current version 
of DMD is installed and, if not, panic out and tell the user to 
go and fetch the latest copy from the website? Then the rest of 
the makefile could use the installed copies on the user's 
computer rather than download and recompile them?


This question is specific to the dlang.org repo and NOT to any 
other repos hosted at GitHub.

Re: DMD source violates c++11 standards.

[Walter Bright]

On 5/27/2013 4:47 PM, Daniel Murphy wrote:

"Hans W. Uhlig"  wrote in message
news:idtvbddofuxwpsbto...@forum.dlang.org...

This also makes compiling LDC with clang rather difficult



DMD is not written in C++11.  Turning of the C++11 warnings in clang will
fix this problem.




Also, you can submit a bugzilla entry for it, or even a pull request. There's no 
reason for such code in DMD to remain.

Re: Why UTF-8/16 character encodings?

[Walter Bright]

On 5/27/2013 4:28 PM, Hans W. Uhlig wrote:

On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:

I've recently come to the opinion that that's a bad idea, and D should not
support it.


Why do you think its a bad idea? It makes it such that code can be in various
languages? Just lack of keyboard support?


Every time I've been to a programming shop in a foreign country, the developers 
speak english at work and code in english. Of course, that doesn't mean that 
everyone does, but as far as I can tell the overwhelming bulk is done in english.


Naturally, full Unicode needs to be in strings and comments, but symbol names? I 
don't see the point nor the utilty of it. Supporting such is just pointless 
complexity to the language.

Re: DMD source violates c++11 standards.

[Daniel Murphy]

"Hans W. Uhlig"  wrote in message 
news:idtvbddofuxwpsbto...@forum.dlang.org...
> This also makes compiling LDC with clang rather difficult
>

DMD is not written in C++11.  Turning of the C++11 warnings in clang will 
fix this problem. 

Re: Why UTF-8/16 character encodings?

[H. S. Teoh]

On Tue, May 28, 2013 at 01:28:22AM +0200, Hans W. Uhlig wrote:
> On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
> >On 5/27/2013 3:18 PM, H. S. Teoh wrote:
> >>Well, D *does* support non-English identifiers, y'know... for
> >>example:
> >>
> >>void main(string[] args) {
> >>int число = 1;
> >>foreach (и; 0..100)
> >>число += и;
> >>writeln(число);
> >>}
> >>
> >>Of course, whether that's a good practice is a different story.
> >>:)
> >
> >I've recently come to the opinion that that's a bad idea, and D
> >should not support it.

Currently, the above code snippet compiles (upon inserting "import
std.stdio;", that is). Should that be made illegal?


> Why do you think its a bad idea? It makes it such that code can be
> in various languages? Just lack of keyboard support?

I can't speak for Walter, but one issue that comes to mind is when
someone reads the code and doesn't understand the language the
identifiers are in, or worse, can't reliably recognize the distinctions
between the glyphs, and so can't match identifier names correctly -- if
you don't know Japanese, for example, seeing a bunch of Japanese
identifiers of equal length will look more-or-less the same (all
gibberish to you), so it only obscures the code. Or if your computer
doesn't have the requisite fonts to display the alphabet in question,
then you'll just see a bunch of ?'s or black blotches for all program
identifiers, making the code completely unreadable.

Since language keywords are already in English, we might as well
standardize on English identifiers too. (After all, Phobos identifiers
are English as well.) While it's cool to have multilingual identifiers,
I'm not sure if it actually adds any practical value. :) If anything, it
arguably detracts from usability. Multilingual program output, of
course, is a different kettle o' fish.


T

-- 
Doubt is a self-fulfilling prophecy.

Re: Why UTF-8/16 character encodings?

[Luís.Marques]

On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
I've recently come to the opinion that that's a bad idea, and D 
should not support it.


I think it is a bad idea to program in a language other than 
english, but I believe D should still support it.

Re: Why UTF-8/16 character encodings?

[Hans W. Uhlig]

On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:

On 5/27/2013 3:18 PM, H. S. Teoh wrote:
Well, D *does* support non-English identifiers, y'know... for 
example:


void main(string[] args) {
int число = 1;
foreach (и; 0..100)
число += и;
writeln(число);
}

Of course, whether that's a good practice is a different 
story. :)


I've recently come to the opinion that that's a bad idea, and D 
should not support it.


Why do you think its a bad idea? It makes it such that code can 
be in various languages? Just lack of keyboard support?

DMD source violates c++11 standards.

[Hans W. Uhlig]

This also makes compiling LDC with clang rather difficult

[  1%] Building CXX object CMakeFiles/LDCShared.dir/dmd2/func.c.o
/root/llvm/src/ldc/dmd2/func.c:540:18: error: case value 
evaluates to -2, which cannot be narrowed to type 'size_t' (aka 
'unsigned long') [-Wc++11-narrowing]

case -2:// can't determine because of fwd refs
 ^
/root/llvm/src/ldc/dmd2/func.c:503:18: error: case value 
evaluates to -1, which cannot be narrowed to type 'size_t' (aka 
'unsigned long') [-Wc++11-narrowing]

case -1:
 ^
/root/llvm/src/ldc/dmd2/func.c:632:22: error: case value 
evaluates to -2, which cannot be narrowed to type 'size_t' (aka 
'unsigned long') [-Wc++11-narrowing]

case -2:
 ^
/root/llvm/src/ldc/dmd2/func.c:629:22: error: case value 
evaluates to -1, which cannot be narrowed to type 'size_t' (aka 
'unsigned long') [-Wc++11-narrowing]

case -1:

Re: More on "Component Programming"

[Sebastian Graf]

On Monday, 27 May 2013 at 21:36:12 UTC, bearophile wrote:

snip


Every time I see that kind of code, my heart makes a delightful 
jump. That code is what I enjoy most about D compared to C++. 
Plus, the compiler is still able to optimize most of the 
delegate/range fluff away (as opposed to e.g. C#).


I'm all for more algorithm primitives in std.algorithm. I missed 
classify often enough and coming from a C# backgroung I was 
confused that std.algorithm.group did not what I thought it did.


Is there any reason why you keep using quoted strings instead of 
string literals for lambdas besides taste?

Re: Why UTF-8/16 character encodings?

[Walter Bright]

On 5/27/2013 3:18 PM, H. S. Teoh wrote:

Well, D *does* support non-English identifiers, y'know... for example:

void main(string[] args) {
int число = 1;
foreach (и; 0..100)
число += и;
writeln(число);
}

Of course, whether that's a good practice is a different story. :)


I've recently come to the opinion that that's a bad idea, and D should not 
support it.

Re: DLang Spec rewrite (?)

[Borden]

Oh, and another thing: XHTML adopts the XML practice of only 
defining the lt, gt and amp entities and no others (like nbsp, 
mdash, accented, or non-Latin characters).


Since Unicode is, by and large, universal, I've read that the 
recommended practice for including characters not on a standard 
US keyboard is to copy them from a character map and save the 
file in a Unicode encoding. I intend to follow this guidance in 
writing the (x)html.ddoc template.


As such, should I keep the existing 'entity' macros or use the 
Unicode characters in the DLang spec source files? I imagine that 
Andrei will immediately comment that .tex files are supposed to 
be in ASCII. Suggestions?

Re: Why UTF-8/16 character encodings?

[Simen Kjaeraas]

On Tue, 28 May 2013 00:18:31 +0200, H. S. Teoh   
wrote:



On Tue, May 28, 2013 at 12:04:52AM +0200, Vladimir Panteleev wrote:

On Monday, 27 May 2013 at 21:24:15 UTC, H. S. Teoh wrote:
>Besides, it's impractical to use compose key sequences to write
>large amounts of text in some given language; a method of
>temporarily switching to a different layout is necessary.

I thought the topic was typing the occasional Unicode character to
use as an operator in D programs?


Well, D *does* support non-English identifiers, y'know... for example:

void main(string[] args) {
int число = 1;
foreach (и; 0..100)
число += и;
writeln(число);
}

Of course, whether that's a good practice is a different story. :)

But for operators, you still need enough compose key sequences to cover
all of the Unicode operators -- and there are a LOT of them -- which I
don't think is currently done anywhere. You'd have to make your own
compose key maps to do it.



The Fortress programming language has some 900 or so operators:

https://java.net/projects/projectfortress/sources/sources/content/Specification/fortress.1.0.pdf?rev=5558

Appendix C, and

https://java.net/projects/projectfortress/sources/sources/content/Documentation/Specification/fortress.pdf?rev=5558

chapter 14


--
Simen

Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ

[Diggory]

On Monday, 27 May 2013 at 20:34:30 UTC, Peter Alexander wrote:
On Monday, 27 May 2013 at 20:14:35 UTC, Andrei Alexandrescu 
wrote:
At some point Walter and I were talking about generating an MD 
hash for very long names. That has some disadvantages (i.e. no 
easy reverse lookup) but it may work.


Surely a better solution would be to use a lossless 
compression? With the amount of repetition you should get very 
high ratios.


It could even be (somewhat) backward compatible if you have a 
marker at the front indicating whether it's compressed or not.

Re: Discussion of TypeTuple naming

[Diggory]

On Monday, 27 May 2013 at 13:42:51 UTC, Timon Gehr wrote:

It is not that similar, as it automatically expands into any 
context and hence does not allow a nested structure.


The point being? It's true that there is some special behaviour, 
but that's the same regardless of whether it's called StaticTuple 
or TypeTuple.


I don't think that having a construct that is restricted to 
just types makes a lot of sense.


In a language which is most emphatically statically typed with 
built in support for class invariants and in/out contracts you 
can't see the purpose of a TypeTuple?


TypeTuple does not implement any functionality. It is an 
'identity function'.


And yet the documentation:

http://dlang.org/tuple.html (see Type Tuples)

And the name clearly suggest that it DOES implement functionality 
- that of checking that the arguments are all types.




On Monday, 27 May 2013 at 19:13:24 UTC, Andrej Mitrovic wrote:

You are forgetting about performance. TypeTuple can be used *a 
lot* in
generic code. If you add static checking for each tuple element 
you're
going to slow down the compiler quite a bit. And you won't know 
this

if you only sporadically use TypeTuple.


Actually, given that all the template parameters are likely 
already being used (otherwise why have that parameter) the 
checking must already occur simply further down the line.


In addition, I've run some tests using thousands of huge 
recursively defined tuples and I haven't been able to get any 
detectable different between using TypeTuple and StaticTuple. 
Unless someone can demonstrate some code which has a measurable 
difference in compilation time I think performance is not an 
argument.


It's not undocumented behavior, it's documented, e.g. The D 
Templates Book.


Fine, not documented on the official dlang site, or rather it's 
specifically documented that TypeTuples are only for storing 
types.


Where do you get this clarity that it's only used for types? 
Have you

inspected all D libraries out there?


Of course not, my "clarity" comes from having gone through phobos 
and identifying which uses of TypeTuple would have to be changed 
to using StaticTuple.


The only significant cases of it being used with non-types 
outside std.typetuple itself were in std.traits, which is hardly 
typical D code and is one file in a large library anyway.


Hence my statement that most uses of TypeTuple were with types 
was based on the fact that it's true in phobos and therefore 
likely true in any sufficiently large code-base. Especially 
considering that significant contributers to phobos are more 
likely to know that using TypeTuple with non-types is allowed 
than the average user of D.



It's not, because now you're forced to always compile with the
deprecation switch.


As Jonathan said that's not true anymore.




On Monday, 27 May 2013 at 19:30:18 UTC, Jonathan M Davis wrote:

That being said, I don't really like the idea of deprecating 
something with the intention that it stick around forever. It 
just provides a smoother transition.


OK, let me amend my statement to "the transition can be as smooth 
as it needs to be".


Yeah. The only problem I see is the name. I don't see any real 
benefit in making it so that we have _three_ different types of 
compile time tuples, particularly when their uses tend to be 
fairly localized rather than being passed around through APIs 
and the like (if they get passed through APIs, they'd just be 
template or function argument lists), and any mismatch of types 
and expressions will result in an error pretty much instantly.


Three? I am suggesting TWO, "StaticTuple" and "TypeTuple" with 
further additions for a future discussion.


It gives good names to concepts we already have but have no way 
to refer to consistently. The term "TypeTuple" as used to mean a 
compile time tuple which contains types has a whole section in 
the documentation.


Currently we don't have any way to talk about StaticTuples 
without being ambiguous and confusing. We can't use the term 
"TypeTuple" because that is already used as I've just described, 
and we can't use the term "Tuple" even though that is what's 
currently used in most places because a "Tuple" is something 
completely different in phobos!


Using StaticTuple clearly and unambiguously refers to the alias 
to a "..." template argument.


If a function's documentation says it accepts any StaticTuple 
then it's clear what that function expects. Likewise for 
TypeTuple. At the moment there's no way to determine whether a 
function can accept non-types without going through the phobos 
source code.


So, holding both expressions and types isn't really a problem 
IMHO - particularly since that's what the built-in tuples do, 
and all TypeTuple really is is a template to let you create and 
manipulate the built-in tuples.


I assume you are refering to what I am calling a StaticTuple 
rather than a Tuple in this case, because not so long ago I would 
have assum

Re: Why UTF-8/16 character encodings?

[H. S. Teoh]

On Tue, May 28, 2013 at 12:04:52AM +0200, Vladimir Panteleev wrote:
> On Monday, 27 May 2013 at 21:24:15 UTC, H. S. Teoh wrote:
> >Besides, it's impractical to use compose key sequences to write
> >large amounts of text in some given language; a method of
> >temporarily switching to a different layout is necessary.
> 
> I thought the topic was typing the occasional Unicode character to
> use as an operator in D programs?

Well, D *does* support non-English identifiers, y'know... for example:

void main(string[] args) {
int число = 1;
foreach (и; 0..100)
число += и;
writeln(число);
}

Of course, whether that's a good practice is a different story. :)

But for operators, you still need enough compose key sequences to cover
all of the Unicode operators -- and there are a LOT of them -- which I
don't think is currently done anywhere. You'd have to make your own
compose key maps to do it.


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

Re: Why UTF-8/16 character encodings?

[Vladimir Panteleev]

On Monday, 27 May 2013 at 21:24:15 UTC, H. S. Teoh wrote:
Besides, it's impractical to use compose key sequences to write 
large amounts of text in some given language; a method of 
temporarily switching to a different layout is necessary.


I thought the topic was typing the occasional Unicode character 
to use as an operator in D programs?

Re: [article] Language Design Deal Breakers

[Simen Kjaeraas]

On Sun, 26 May 2013 10:50:25 +0200, Nick Sabalausky  
 wrote:



On Sat, 25 May 2013 22:14:06 -0700
"H. S. Teoh"  wrote:


D's unittest blocks have singlehandedly converted me from a
code-by-faith person full of every excuse to *not* write unittests, to
somebody habitually writing unittests.


Same here. And I'd bet it's a common story among D users.


Yup. Well, in D. I just love this:

void foo(Args args)
in {
} body {
} out {
} unittest {
}

I won't always use all of those (I'm no good at using contracts), but  
writing

'} unittest {' at the end of a function has become second nature now.

Now, opening the unit test solution, checking out the right file, waiting  
for a
minute while Irrational CludgeCase tries to download a possibly updated  
version

of a file it should know is already on my disk, writing a new test while
occasionally glancing at the code on my other screen to remember what the
function did, then wait for ClearCase to accept my attempt to save to file,
before finally being able to run the test...

One of these is just... simpler. Better. More sane.

--
Simen

Re: [article] Language Design Deal Breakers

[Simen Kjaeraas]

On Mon, 27 May 2013 20:00:30 +0200, deadalnix  wrote:


On Monday, 27 May 2013 at 17:41:37 UTC, Walter Bright wrote:

On 5/27/2013 2:17 AM, deadalnix wrote:
But the argument about compiler feature don't stand, as nonnull  
pointer and

@disable this require the exact same processing in the compiler.


Yes, it does stand, as there is a lot of other types that can benefit  
from @disable this. If notnull is a core feature, then only that works.


I never said that they are mutually exclusive. All the contrary, I say  
they are the same thing. And that if you have one, you have no reason  
not the have the other.


Ah, like that. Your posts could be read as 'non-nullable pointers give
the *exact* same benefits as does @disable this()', which is simply untrue.

Now, if we wanted to add compiler support for non-nullable references, many
more things would need to be decided - how do they look? Do they assert
non-nullness upon initialization/assignment, or are external checks  
required?

Does new Foo() return a non-nullable reference? Must we also add scoped
non-nullness guarantees (if(foo != null) { /* foo is now implicitly
convertible to non-nullable */ })?

So, no. The stuff required to add @disable this() to the language is not  
the
same that is required for non-nullable references. It's certainly an  
important
part of it, but there's still more left, and it's going to make the  
language

harder to implement. Adding a feature that lets non-nullable references be
added in a library is much better.

--
Simen

Re: [article] Language Design Deal Breakers

[Simen Kjaeraas]

On Mon, 27 May 2013 16:55:54 +0200, deadalnix  wrote:


On Monday, 27 May 2013 at 14:36:26 UTC, Andrei Alexandrescu wrote:

On 5/27/13 5:17 AM, deadalnix wrote:

I'm saying that NonNull require language support, either by making it a
first class entity, or by introducing some other language feature like
@disable this(). At the end it doesn't change anything for the  
compiler,

the exact same work have to be done, simply on different entities. It
can't be a 100% library feature as the work around @disable this shows.


The difference is that @disable this() and friends allows implementing  
NonNull PLUS a host of other restricted types, whereas plopping NonNull  
in the language just stops there. Big difference.




My point being that this is the exact same feature, from a compiler  
perspective.



I think that ideally, nonnull pointer should be a core feature.
Considering history, a library solution is preferable.

But the argument about compiler feature don't stand, as nonnull pointer
and @disable this require the exact same processing in the compiler.


No.



See above. Tracking initialization, that's it.


Well, yes. But it does so in a general way, rather than limit it to
non-nullable pointers/references.

If D had added non-nullable references only (no @disable this()), how would
you go about creating a number that's guaranteed to be prime? Would you ask
for that as a separate complier feature?

--
Simen

More on "Component Programming"

[bearophile]

This simple task on Rosettacode site is useful to show some uses 
of Phobos and the "component programming" recently discussed by 
Walter (other languages use a different name to denote the same 
idea).


Given a dictionary file of different words, it asks to find any 
of the longest anagram pairs, that also share no equal chars in 
the same position (so they are named deranged anagrams):


http://rosettacode.org/wiki/Anagrams/Deranged_anagrams#D

There are many ways to do this in D+Phobos. The following 
solution is long, but it's quite fast (the "warmed up" run-time 
is only about 0.03 seconds with a dictionary of about 200 KB, on 
an old CPU core), I have chosen it over simple solutions because 
it gives me a chance to discuss certain things:




import std.stdio, std.file, std.algorithm, std.string,
   std.typecons, std.range, std.functional;

auto findDeranged(in string[] words) pure /*nothrow*/ {
//return words.pairwise.filter!(ww=> ww[].zip.all!q{a[0] != 
a[1]});

Tuple!(string, string)[] result;
foreach (immutable i, const w1; words)
foreach (const w2; words[i + 1 .. $])
if (zip(w1, w2).all!q{ a[0] != a[1] })
result ~= tuple(w1, w2);
return result;
}

void main() {
Appender!(string[])[30] wClasses;
foreach (word; 
std.algorithm.splitter("unixdict.txt".readText))

wClasses[$ - word.length] ~= word;

"Longest deranged anagrams:".writeln;
foreach (words; wClasses[].map!q{ a.data 
}.filter!(not!empty)) {

string[][const ubyte[]] anags; // Assume ASCII input.
foreach (w; words)
anags[w.dup.representation.sort().release.idup] ~= w;
auto pairs = anags.byValue.map!findDeranged.join;
if (!pairs.empty)
return writefln("  %s, %s", pairs.front[]);
}
}


- - - - - - - - - - - -

That program contains five foreach loops. Foreach loops are not 
evil and I like them, but for a certain kind of programming 
(discussed recently by Walter, and also common in F# and other 
languages) every time you use a for/foreach it's one small 
"failure" for the standard library :-)


The following weird (untested and maybe buggy) program replaces 
all the foreach loops with higher order functions and other 
library functions. It can't be compiled because it uses some 
things not yet present in Phobos (on the Rosettacode page there 
is also a slower and simpler D solution of this problem that uses 
only one foreach):



void main() {
import std.stdio, std.file, std.algorithm, std.string,
   std.typecons, std.range, std.functional;

"unixdict.txt"
.readText
.splitter
.classify!q{ a.length }
.map!q{ a.values } // .byValue is almost OK.
.array
.schwartzSort!q{ -a[0].length }
.release
.map!(words => words
   .classify!q{ a
.dup
.representation
.sort()
.release
.idup }
   .byValue
   .map!(words => words
  .pairwise
  .filter!(ww => ww[]
 .zip
 .all!q{ a[0] != 
a[1] }))

   .join)
.filter(not!empty)
.front[]
.binaryReverseArgs!writefln("  %s, %s");
}


A copy of the same code if the newsgroup has messed up the 
formatting and indents, turning that code into a soup:

http://codepad.org/L4TyDkcQ


I am not suggesting you to write whole D script-like programs in 
this strange style. But I think Phobos should offer all the tools 
to write a program like this, because even if you don't want to 
write a whole little program in this style, you sometimes want to 
use some parts of it or some other parts of it, so I think all 
the most common and distinct micro-patterns should be contained 
in Phobos.


- - - - - - - - - - - -

"binaryReverseArgs" is in the std.functional module. Here it 
allows the use of writefln in UFCS style, inverting the 
formatting string position. I think I'd like a shorter and more 
handy name for it. In Haskell it's named "flip", and its usage is 
not uncommon.


- - - - - - - - - - - -

"classify" is a simple function, that given a forward range of T 
and an optional function T->K, returns an associative array 
T[][K]. (Arrays are used by default as values. But maybe you can 
optionally specify a different type of values, like Appenders, 
Arrays, sets, etc). (Currently in Phobos the only function to 
build an associative array is std.array.assocArray, but here we 
need something different). 
(http://d.puremagic.com/issues/show_bug.cgi?id=5502 ).


[1, 7, 6, 3, 2].classify!(x => x % 2 ? "odd": "even").writeln;

==>
["odd": [1, 7, 3], "even": [6, 2]]

- - - - - - - - - - - -

"pairwise" is a very useful lazy range similar to 
cartesianProduct, but

Re: Why UTF-8/16 character encodings?

[H. S. Teoh]

On Mon, May 27, 2013 at 09:59:52PM +0200, Vladimir Panteleev wrote:
> On Monday, 27 May 2013 at 02:17:08 UTC, Wyatt wrote:
> >No hardware required; just a smarter IME.
> 
> Perhaps something like the compose key?
> 
> http://en.wikipedia.org/wiki/Compose_key

I'm already using the compose key. But it only goes so far (I don't
think compose key sequences cover all of unicode). Besides, it's
impractical to use compose key sequences to write large amounts of text
in some given language; a method of temporarily switching to a different
layout is necessary.


T

-- 
Тише едешь, дальше будешь.

Re: New UTF-8 stride function

[Martin Nowak]

On 05/27/2013 09:21 PM, Martin Nowak wrote:

 > See unittest/benchmark here:
 > https://gist.github.com/blackwhale/5653927
 >
Looks promising.


This will not detect 0xFF as invalid UTF-8 sequence.
For sequences with 5 or 6 bytes, that aren't used for unicode, it will 
return a stride of 4.

Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ

[Peter Alexander]

On Monday, 27 May 2013 at 20:14:35 UTC, Andrei Alexandrescu wrote:
At some point Walter and I were talking about generating an MD 
hash for very long names. That has some disadvantages (i.e. no 
easy reverse lookup) but it may work.


Surely a better solution would be to use a lossless compression? 
With the amount of repetition you should get very high ratios.

Re: Wondering about errors…

[Walter Bright]

On 5/27/2013 4:32 AM, Russel Winder wrote:

Using rdmd, it appears that the first error in the code can lead the
parsing and template handling of everything following to be wrong. I
keep finding that I am getting spurious errors about things nothing to
do with the actual error, that simply go away when the real error is
fixed. This would imply that most errors reported are generally
spurious?


The usual approach to handling errors in a compiler is to guess at what the user 
actually meant, repair the AST according to that guess, then continue on. 
Unfortunately, the guess is usually wrong and the result is cascaded errors, of 
which only the first is meaningful.


DMD has been gradually switching over to a more novel approach, one that I 
haven't seen elsewhere. Once an error is discovered, the AST is marked as 
"erroneous". That erroneous state propagates upwards to the root of the AST, and 
that any AST that relies on an erroneous AST is itself erroneous, and no further 
error messages are emitted for it.


The result should be that only "original sin" errors are reported.

This has already resulted in a great reduction of spurious error messages, but 
clearly we have more work to do.

Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ

[Andrei Alexandrescu]

On 5/27/13 12:18 PM, David Nadlinger wrote:

On Monday, 27 May 2013 at 15:22:21 UTC, Peter Alexander wrote:

Am I the only person that worries greatly about the length of symbols
in D?


No, I do as well. My units of measurement project suffered from very
non-negligible code bloat due to symbol name length, and even if that
was a rather extraordinary endeavor to begin with, "normal" D code is
affected just as well. For example, try this one from the std.algorithm
unit tests:

———
_D3std5range4308__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std9algorithm987__T6joinerTS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__

T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6joinerFS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__T8Sequ
enceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6ResultTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range2008__T6RepeatTS3std9algorithm987__T6joinerTS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typ
econs12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6joinerFS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons1
2__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6ResultZ6RepeatZ3Zip8opAssignMFNcS3std5range4308__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5

Re: New UTF-8 stride function

[Dmitry Olshansky]

27-May-2013 23:21, Martin Nowak пишет:


On 05/26/2013 10:49 PM, Dmitry Olshansky wrote:
 > If there is anything that come out of UTF-8 discussion is that I decided
 > to dust off my experimental implementation of UTF-8 stride function.
 > Just for fun.
 >
 > The key difference vs std is in handling non-ASCII case.
 > I'm replacing bsr intrinsic with a what I call an "in-register lookup
 > table" (neat stuff that is a piece of cake, thx to CTFE).
 >
 > See unittest/benchmark here:
 > https://gist.github.com/blackwhale/5653927
 >
Looks promising.


Cool, I'm not alone in this :)

The only definitive results so far is that it takes less cycles on 32 
bit. For me AMD CodeAnalyst confirms this is literally in cycles of up 
to 33% less with smaller samples in a loop. ASCII-only case seems to 
stay more or less the same (at least cycle-wise but not in time...) 
saving my sanity.




These are huge and most likely the performance is limited by the memory
bandwith.



That could be it. I'll be making measurement on smaller samples of said 
files and spin on them. More tests to come tomorrow.



--
Dmitry Olshansky

Re: Wondering about errors…

[Andrei Alexandrescu]

On 5/27/13 7:51 AM, Adam D. Ruppe wrote:

Yeah, me too.

I take a working program and add "gf" to the middle of it. Here's the
errors:


I'd say that deserves a bugzilla entry.

Andrei

Re: Why UTF-8/16 character encodings?

[Vladimir Panteleev]

On Monday, 27 May 2013 at 02:17:08 UTC, Wyatt wrote:

No hardware required; just a smarter IME.


Perhaps something like the compose key?

http://en.wikipedia.org/wiki/Compose_key

Re: Discussion of TypeTuple naming

[Jonathan M Davis]

On Monday, May 27, 2013 21:13:10 Andrej Mitrovic wrote:
> On 5/27/13, Diggory  wrote:
> > - There's no necessity to ever actually completely remove the
> > deprecated behaviour, the deprecation warning is enough.
> 
> It's not, because now you're forced to always compile with the
> deprecation switch.

That's not true anymore. Deprecations only print out warning messages by 
default, precisely so that we can deprecate things without breaking everyone's 
code. -d makes the compile shut up, but it is no longer required to get your 
code to compile. That being said, I don't really like the idea of deprecating 
something with the intention that it stick around forever. It just provides a 
smoother transition.

> All I see here is the problem with the actual *name* of the template.
> If it's so horrible to use this name, the simplest thing we can do is
> introduce an alias to TypeTuple, ala "Seq" or "ExpressionTuple", or
> something similar.
> 
> Of course "TypeTuple" is a misnomer, but it's way too late to change
> it now or even change its semantics. Even slowing it down by doing
> type-checking is a problem.

Yeah. The only problem I see is the name. I don't see any real benefit in 
making it so that we have _three_ different types of compile time tuples, 
particularly when their uses tend to be fairly localized rather than being 
passed around through APIs and the like (if they get passed through APIs, 
they'd just be template or function argument lists), and any mismatch of types 
and expressions will result in an error pretty much instantly. So, holding 
both expressions and types isn't really a problem IMHO - particularly since 
that's what the built-in tuples do, and all TypeTuple really is is a template 
to let you create and manipulate the built-in tuples.

So, if we change anything, we change the name via an alias and leave all of 
the semantics alone. But given how much TypeTuple is used and that the module 
is named std.typetuple, it would likely have to be a permanent alias, in which 
case you _still_ have to explain what TypeTuple is, and the gain of renaming 
it is minimal IMHO (it could even make things _worse_ by increasing the 
confusion by having multiple names).

The name sucks, but I think that we're stuck with it at this point. For it to 
be worth it, we'd have to be willing to force everyone to change their code to 
use the new name, and for the most part, we're just not doing that sort of 
thing anymore.

- Jonathan M Davis

Re: New UTF-8 stride function

[Martin Nowak]

On 05/26/2013 10:49 PM, Dmitry Olshansky wrote:
> If there is anything that come out of UTF-8 discussion is that I decided
> to dust off my experimental implementation of UTF-8 stride function.
> Just for fun.
>
> The key difference vs std is in handling non-ASCII case.
> I'm replacing bsr intrinsic with a what I call an "in-register lookup
> table" (neat stuff that is a piece of cake, thx to CTFE).
>
> See unittest/benchmark here:
> https://gist.github.com/blackwhale/5653927
>
Looks promising.

> Test files I used:
> 
https://github.com/blackwhale/gsoc-bench-2012/blob/master/arwiki-latest-all-titles-in-ns0

>
> 
https://github.com/blackwhale/gsoc-bench-2012/blob/master/dewiki-latest-all-titles-in-ns0

>
> 
https://github.com/blackwhale/gsoc-bench-2012/blob/master/dewiki-latest-all-titles-in-ns0

>
> 
https://github.com/blackwhale/gsoc-bench-2012/blob/master/ruwiki-latest-all-titles-in-ns0

>
These are huge and most likely the performance is limited by the memory 
bandwith.

Re: New UTF-8 stride function

[Dmitry Olshansky]

27-May-2013 01:13, Vladimir Panteleev пишет:

On Sunday, 26 May 2013 at 20:49:36 UTC, Dmitry Olshansky wrote:

It's the kind of thing that is tremendously hard to measure accurately
since it depends on the workload, architecture and the time spent is
very small. So don't take it by word I'm almost certain that something
is amiss (compiler switches and whatnot).


For such cases, I found Agner's benchmarking utilities to be very
useful. They print exact CPU statistics, such as numbers of micro-ops,
cache misses, mispredicted branches, etc. I've used them very
successfully when tuning my appender implementation.



Yes, Agner is da man. Just hoped I could postpone this but... welcome to 
the micro-optimization world I guess.



To use them with D, I modified his C++ program to load a DLL and call a
function, taking the DLL and function names from the command line.

Original program:
http://www.agner.org/optimize/testp.zip

My patch (to load a DLL):
http://dump.thecybershadow.net/5f55e8be5f8cd38ad60f218957ef24bb/PMCTestB.diff


Usage example (sort of):
https://github.com/CyberShadow/DAppenderResearch/blob/master/go-dll.bat

Hope this helps :)


Thanks, I'll try it out. But jezz I have win8 so I'd start with linux 
version :)


--
Dmitry Olshansky

Re: Discussion of TypeTuple naming

[Andrej Mitrovic]

On 5/27/13, Diggory  wrote:
> - The result of the change is zero existing code actually failing
> to compile. TypeTuple will simply show a deprecation warning if
> used with non-types.

You are forgetting about performance. TypeTuple can be used *a lot* in
generic code. If you add static checking for each tuple element you're
going to slow down the compiler quite a bit. And you won't know this
if you only sporadically use TypeTuple.

> - Any code that does use non-types with TypeTuple is using
> undocumented behaviour.

It's not undocumented behavior, it's documented, e.g. The D Templates Book.

> - Almost all uses of TypeTuple are for dealing with types and so
> will be completely unaffected by the change.

Where do you get this clarity that it's only used for types? Have you
inspected all D libraries out there?

> - There's no necessity to ever actually completely remove the
> deprecated behaviour, the deprecation warning is enough.

It's not, because now you're forced to always compile with the
deprecation switch.

---

All I see here is the problem with the actual *name* of the template.
If it's so horrible to use this name, the simplest thing we can do is
introduce an alias to TypeTuple, ala "Seq" or "ExpressionTuple", or
something similar.

Of course "TypeTuple" is a misnomer, but it's way too late to change
it now or even change its semantics. Even slowing it down by doing
type-checking is a problem.