www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The Thermopylae excerpt of TDPL available online

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
It's a rough rough draft, but one for the full chapter on arrays, 
associative arrays, and strings.

http://erdani.com/d/thermopylae.pdf

Any feedback is welcome. Thanks!


Andrei
Oct 28 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.
 http://erdani.com/d/thermopylae.pdf
 Any feedback is welcome. Thanks!
 Andrei
Given that new is all over the place, does this mean we're not getting rid of new before D2 goes gold?
Oct 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.
 http://erdani.com/d/thermopylae.pdf
 Any feedback is welcome. Thanks!
 Andrei
Given that new is all over the place, does this mean we're not getting rid of new before D2 goes gold?
I guess we need to compromise. Andrei
Oct 28 2009
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s 
 article
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.
 http://erdani.com/d/thermopylae.pdf
 Any feedback is welcome. Thanks!
 Andrei
Given that new is all over the place, does this mean we're not getting rid of new before D2 goes gold?
I guess we need to compromise. Andrei
I got the impression from previous discussions that this would be a rather simple thing to implement. Also, the community mostly seemed to agree that ditching new would be a good thing. What are the obstacles? -Lars
Oct 29 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lars T. Kyllingstad wrote:
 Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s 
 article
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.
 http://erdani.com/d/thermopylae.pdf
 Any feedback is welcome. Thanks!
 Andrei
Given that new is all over the place, does this mean we're not getting rid of new before D2 goes gold?
I guess we need to compromise. Andrei
I got the impression from previous discussions that this would be a rather simple thing to implement. Also, the community mostly seemed to agree that ditching new would be a good thing. What are the obstacles?
Walter prefers that allocations have a cue. You'd need to convince him. Andrei
Oct 29 2009
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
 
 
 Andrei
It's a very pleasant read, and it looks good. I guess I'll have to buy the book. :) I just have two comments: Code snippet in 4.2.1: Why do you suddenly use postfix array declaration here? Code snippet just before 4.4.3: ("yowza" !in aa) doesn't work, at least not with DMD 2.035. It has to be !("yowza" in aa). Very annoying.
Oct 29 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lars T. Kyllingstad wrote:
 Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
It's a very pleasant read, and it looks good. I guess I'll have to buy the book. :)
Thanks! Very glad to hear you like it.
 I just have two comments:
 
 Code snippet in 4.2.1: Why do you suddenly use postfix array declaration 
 here?
Oops... I'd planned to simply pretend it doesn't exist. Thanks, I fixed that now.
 Code snippet just before 4.4.3: ("yowza" !in aa) doesn't work, at least 
 not with DMD 2.035. It has to be !("yowza" in aa). Very annoying.
Walter is planning to effect that change. By publishing time, there won't be any red and any pink in the book! (One nice thing about the book is that it gives us a good idea on what to work on. Walter has been on an incredible streak lately, and Don adds amazing value.) Andrei
Oct 29 2009
prev sibling next sibling parent reply =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
 
 
 Andrei
Your "Hallå Värd!" should be "Hallå Värld!", to be Swedish. D: Also, I am wondering, why is the undefined behavior of opCatAssign kept? Couldn't every T[] know if it is the owner of the memory in question? Sorry if I bring outdated discussions up unnecessarily.
Oct 29 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Pelle Månsson wrote:
 Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Your "Hallå Värd!" should be "Hallå Värld!", to be Swedish. D:
Thanks! Ouch, two mistakes in one word. Also, should I put a comma in between the words?
 Also, I am wondering, why is the undefined behavior of opCatAssign kept? 
 Couldn't every T[] know if it is the owner of the memory in question? 
 Sorry if I bring outdated discussions up unnecessarily.
We don't know how to do that cheaply. Andrei
Oct 29 2009
parent =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
Andrei Alexandrescu wrote:
 Pelle Månsson wrote:
 Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Your "Hallå Värd!" should be "Hallå Värld!", to be Swedish. D:
Thanks! Ouch, two mistakes in one word. Also, should I put a comma in between the words?
Actually, I see now that you had it as "Hallå, värd!", and it should be "Hallå, värld!", no need to capitalize the second word. Unless what you want to say is "Hello, host!", in which case your värd is correct.
 Also, I am wondering, why is the undefined behavior of opCatAssign 
 kept? Couldn't every T[] know if it is the owner of the memory in 
 question? Sorry if I bring outdated discussions up unnecessarily.
We don't know how to do that cheaply. Andrei
How about doing it expensively? Maybe storing a boolean in each T[]? I think undefined behavior is bad.
Oct 29 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 http://erdani.com/d/thermopylae.pdf
 Any feedback is welcome. Thanks!
So far I've just taken a look, I'll read it when I can. I can see several warnings in red. The look of the text is really nice! Elegant, and the images are good and necessary. Are you going to write a book with all pages coloured? If true this will increase the book price, I think. I have seen that you use a nice fount for the nonproportional text (like code), it looks similar to the Consolas. You may try this one too (but it's not a professional product, it may have some rough details): http://www.fantascienza.net/leonardo/ar/inconsolatag/inconsolata-g_font.zip Bye, bearophile
Oct 29 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 
 http://erdani.com/d/thermopylae.pdf Any feedback is welcome.
 Thanks!
So far I've just taken a look, I'll read it when I can. I can see several warnings in red. The look of the text is really nice! Elegant, and the images are good and necessary. Are you going to write a book with all pages coloured? If true this will increase the book price, I think.
Thanks. Unlike most authors, I provide camera-free to the publisher and carried all of the page design myself. I'm very glad I did. The book will be in black and white. Notice how every use of color is also accompanied by a color-independent cue (e.g. bold/slanted). But the book will also sell in electronic format, which will be color.
 I have seen that you use a nice fount for the
 nonproportional text (like code), it looks similar to the Consolas.
 You may try this one too (but it's not a professional product, it may
 have some rough details): 
 http://www.fantascienza.net/leonardo/ar/inconsolatag/inconsolata-g_font.zip
I did consider Inconsolata seriously, but I had to reject it (I forgot why; all I can remember was that it was a good reason). Andrei
Oct 29 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I did consider Inconsolata seriously, but I had to reject it (I forgot 
 why; all I can remember was that it was a good reason).
A problem with Inconsolata that I have forgotten to tell you is that there isn't a true bold version yet, so the bold characters don't have the same width. So if your code highlighting converts some words to bold, the alignments break. This is quite so bad that I have disabled bold highlighting in my Python editor where I use that font. In the future I'll create a bold version of Inconsolata-g to solve this problem, it requires some tedious work, because it seems there are no automatic tools to do this. Bye, bearophile
Oct 29 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 
 I did consider Inconsolata seriously, but I had to reject it (I forgot 
 why; all I can remember was that it was a good reason).
A problem with Inconsolata that I have forgotten to tell you is that there isn't a true bold version yet, so the bold characters don't have the same width.
I think that was it indeed. Andrei
Oct 29 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet? Also, on page 8? a code comment says average of a and b even though the variables don't exist.
Oct 29 2009
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code snippets in question are marked "Note: normally the code below would not be included...", and I suppose he's put them there as a reminder for himself and Walter on what needs to be fixed before the book comes out. I agree with you, though, is(typeof(...)) is quite often misused, or at least used in an ugly way. Why not use __traits(compiles, ...) instead? -Lars
Oct 29 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on arrays,  
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code snippets in question are marked "Note: normally the code below would not be included...", and I suppose he's put them there as a reminder for himself and Walter on what needs to be fixed before the book comes out. I agree with you, though, is(typeof(...)) is quite often misused, or at least used in an ugly way. Why not use __traits(compiles, ...) instead? -Lars
... which is at least as ugly.
Oct 29 2009
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Denis Koroskin wrote:
 On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad 
 <public kyllingen.nospamnet> wrote:
 
 Jason House wrote:
 Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code snippets in question are marked "Note: normally the code below would not be included...", and I suppose he's put them there as a reminder for himself and Walter on what needs to be fixed before the book comes out. I agree with you, though, is(typeof(...)) is quite often misused, or at least used in an ugly way. Why not use __traits(compiles, ...) instead? -Lars
... which is at least as ugly.
I disagree. Pretend you are just learning D, and you are presented with the following two lines of code: static assert (is(typeof(XXX)); static assert (__traits(compiles, XXX)); Which of these would you most likely assume to be a check on whether XXX is compilable code? What I cannot for the life of me understand is WHY the double underscores? What's wrong with just "traits"? -Lars
Oct 29 2009
next sibling parent reply Don <nospam nospam.com> writes:
Lars T. Kyllingstad wrote:
 Denis Koroskin wrote:
 On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad 
 <public kyllingen.nospamnet> wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code snippets in question are marked "Note: normally the code below would not be included...", and I suppose he's put them there as a reminder for himself and Walter on what needs to be fixed before the book comes out. I agree with you, though, is(typeof(...)) is quite often misused, or at least used in an ugly way. Why not use __traits(compiles, ...) instead? -Lars
... which is at least as ugly.
I disagree. Pretend you are just learning D, and you are presented with the following two lines of code: static assert (is(typeof(XXX)); static assert (__traits(compiles, XXX)); Which of these would you most likely assume to be a check on whether XXX is compilable code? What I cannot for the life of me understand is WHY the double underscores? What's wrong with just "traits"? -Lars
Also is(typeof(XXX)) *doesn't* currently check that XXX is compilable, just that it has a type. OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be better; but I think we need to do better than that. It's the bread-and-butter of metaprogramming in D. Using the ugly syntax, it has well and truly proved its value. I've counted 20 uses in what I've seen of Andrei's book -- it appears about as often as (say) 'delegate'! It does a beautiful thing, it deserves a beautiful syntax. Something at least as good as __compiles(XXX), I reckon.
Oct 29 2009
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:
 Lars T. Kyllingstad wrote:
 Denis Koroskin wrote:
 On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad 
 <public kyllingen.nospamnet> wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code snippets in question are marked "Note: normally the code below would not be included...", and I suppose he's put them there as a reminder for himself and Walter on what needs to be fixed before the book comes out. I agree with you, though, is(typeof(...)) is quite often misused, or at least used in an ugly way. Why not use __traits(compiles, ...) instead? -Lars
... which is at least as ugly.
I disagree. Pretend you are just learning D, and you are presented with the following two lines of code: static assert (is(typeof(XXX)); static assert (__traits(compiles, XXX)); Which of these would you most likely assume to be a check on whether XXX is compilable code? What I cannot for the life of me understand is WHY the double underscores? What's wrong with just "traits"? -Lars
Also is(typeof(XXX)) *doesn't* currently check that XXX is compilable, just that it has a type. OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be better; but I think we need to do better than that. It's the bread-and-butter of metaprogramming in D. Using the ugly syntax, it has well and truly proved its value. I've counted 20 uses in what I've seen of Andrei's book -- it appears about as often as (say) 'delegate'! It does a beautiful thing, it deserves a beautiful syntax. Something at least as good as __compiles(XXX), I reckon.
Again with the double underscores. :) I'm starting to think we need a separate namespace for the CT stuff. D.compiles(XXX) D.typeof(foo) D.stringof(T) D.allMembers(T) etc. -Lars
Oct 30 2009
parent reply Don <nospam nospam.com> writes:
Lars T. Kyllingstad wrote:
 Don wrote:
 Lars T. Kyllingstad wrote:
 Denis Koroskin wrote:
 On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad 
 <public kyllingen.nospamnet> wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code snippets in question are marked "Note: normally the code below would not be included...", and I suppose he's put them there as a reminder for himself and Walter on what needs to be fixed before the book comes out. I agree with you, though, is(typeof(...)) is quite often misused, or at least used in an ugly way. Why not use __traits(compiles, ...) instead? -Lars
... which is at least as ugly.
I disagree. Pretend you are just learning D, and you are presented with the following two lines of code: static assert (is(typeof(XXX)); static assert (__traits(compiles, XXX)); Which of these would you most likely assume to be a check on whether XXX is compilable code? What I cannot for the life of me understand is WHY the double underscores? What's wrong with just "traits"? -Lars
Also is(typeof(XXX)) *doesn't* currently check that XXX is compilable, just that it has a type. OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be better; but I think we need to do better than that. It's the bread-and-butter of metaprogramming in D. Using the ugly syntax, it has well and truly proved its value. I've counted 20 uses in what I've seen of Andrei's book -- it appears about as often as (say) 'delegate'! It does a beautiful thing, it deserves a beautiful syntax. Something at least as good as __compiles(XXX), I reckon.
Again with the double underscores. :)
Yes. That's why I said "at least as good". I'm starting to think we need a
 separate namespace for the CT stuff.
 
   D.compiles(XXX)
   D.typeof(foo)
   D.stringof(T)
   D.allMembers(T)
That's not bad. Can't be 'D', though, has to look like a keyword. Maybe something like 'traits' instead. In exchange, get rid of the '__traits' and 'typeid' keywords. Not sure about typeof, though. traits.compiles(XXX) traits.typeid(TTT) traits.stringof(T) traits.allMembers(T) traits.error("message"); IMHO this looks better than __traits(compiles, XXX) but it actually has the same flexibility, and it's a straightforward transformation inside the compiler. For bonus points, allow 'with(traits)': with(traits) { if (compiles(XXX)) return stringof(T); else error("Can't use " ~ stringof(T) ~ " in a transmogrifier."); }
Oct 30 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

 traits.compiles(XXX)
 traits.typeid(TTT)
 traits.stringof(T)
 traits.allMembers(T)
 traits.error("message");
Cute. Simpler alternative, the dot isn't necessary: traits_compiles(XXX) traits_typeid(TTT) traits_stringof(T) traits_allmembers(T) traits_error("message"); Or, more uniformly (all D needs more identifier style uniformity): traits_compiles(XXX) traits_type_id(TTT) traits_string_of(T) traits_all_members(T) traits_error("message");
 For bonus points, allow 'with(traits)':
 with(traits) {
    if (compiles(XXX)) return stringof(T);
    else error("Can't use " ~ stringof(T) ~ " in a transmogrifier.");
 }
Not nice. Bad. Bye, bearophile
Oct 30 2009
next sibling parent "Danny Wilson" <bluezenix gmail.com> writes:
Op Fri, 30 Oct 2009 11:44:08 +0100 schreef bearophile  
<bearophileHUGS lycos.com>:

 Simpler alternative, the dot isn't necessary:

 traits_compiles(XXX)
 traits_typeid(TTT)
 traits_stringof(T)
 traits_allmembers(T)
 traits_error("message");
Not nice. Bad.
Oct 30 2009
prev sibling parent Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 
 traits.compiles(XXX)
 traits.typeid(TTT)
 traits.stringof(T)
 traits.allMembers(T)
 traits.error("message");
Cute. Simpler alternative, the dot isn't necessary: traits_compiles(XXX) traits_typeid(TTT) traits_stringof(T) traits_allmembers(T) traits_error("message");
That is WAY more complicated! It adds a crazy number of keywords, and isn't extensible.
Oct 30 2009
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:
 Lars T. Kyllingstad wrote:
 Don wrote:
 Lars T. Kyllingstad wrote:
 Denis Koroskin wrote:
 On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad 
 <public kyllingen.nospamnet> wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on 
 arrays, associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code snippets in question are marked "Note: normally the code below would not be included...", and I suppose he's put them there as a reminder for himself and Walter on what needs to be fixed before the book comes out. I agree with you, though, is(typeof(...)) is quite often misused, or at least used in an ugly way. Why not use __traits(compiles, ...) instead? -Lars
... which is at least as ugly.
I disagree. Pretend you are just learning D, and you are presented with the following two lines of code: static assert (is(typeof(XXX)); static assert (__traits(compiles, XXX)); Which of these would you most likely assume to be a check on whether XXX is compilable code? What I cannot for the life of me understand is WHY the double underscores? What's wrong with just "traits"? -Lars
Also is(typeof(XXX)) *doesn't* currently check that XXX is compilable, just that it has a type. OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be better; but I think we need to do better than that. It's the bread-and-butter of metaprogramming in D. Using the ugly syntax, it has well and truly proved its value. I've counted 20 uses in what I've seen of Andrei's book -- it appears about as often as (say) 'delegate'! It does a beautiful thing, it deserves a beautiful syntax. Something at least as good as __compiles(XXX), I reckon.
Again with the double underscores. :)
Yes. That's why I said "at least as good". I'm starting to think we need a
 separate namespace for the CT stuff.

   D.compiles(XXX)
   D.typeof(foo)
   D.stringof(T)
   D.allMembers(T)
That's not bad. Can't be 'D', though, has to look like a keyword. Maybe something like 'traits' instead. In exchange, get rid of the '__traits' and 'typeid' keywords. Not sure about typeof, though. traits.compiles(XXX) traits.typeid(TTT) traits.stringof(T) traits.allMembers(T) traits.error("message"); IMHO this looks better than __traits(compiles, XXX) but it actually has the same flexibility, and it's a straightforward transformation inside the compiler. For bonus points, allow 'with(traits)': with(traits) { if (compiles(XXX)) return stringof(T); else error("Can't use " ~ stringof(T) ~ " in a transmogrifier."); }
I like it. It's a clean, simple solution. The std.traits module will just have to be renamed to std.meta or something. Or one could possibly use 'meta' as the new keyword: meta.compiles(XXX) meta.typeid(T) meta.stringof(T) Actually, I think I like that better than 'traits'. -Lars
Oct 30 2009
parent reply Justin Johansson <no spam.com> writes:
Lars T. Kyllingstad Wrote:

 Don wrote:
 Lars T. Kyllingstad wrote:
 Don wrote:
 Lars T. Kyllingstad wrote:
 Denis Koroskin wrote:
 On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad 
 <public kyllingen.nospamnet> wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on 
 arrays, associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code snippets in question are marked "Note: normally the code below would not be included...", and I suppose he's put them there as a reminder for himself and Walter on what needs to be fixed before the book comes out. I agree with you, though, is(typeof(...)) is quite often misused, or at least used in an ugly way. Why not use __traits(compiles, ...) instead? -Lars
... which is at least as ugly.
I disagree. Pretend you are just learning D, and you are presented with the following two lines of code: static assert (is(typeof(XXX)); static assert (__traits(compiles, XXX)); Which of these would you most likely assume to be a check on whether XXX is compilable code? What I cannot for the life of me understand is WHY the double underscores? What's wrong with just "traits"? -Lars
Also is(typeof(XXX)) *doesn't* currently check that XXX is compilable, just that it has a type. OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be better; but I think we need to do better than that. It's the bread-and-butter of metaprogramming in D. Using the ugly syntax, it has well and truly proved its value. I've counted 20 uses in what I've seen of Andrei's book -- it appears about as often as (say) 'delegate'! It does a beautiful thing, it deserves a beautiful syntax. Something at least as good as __compiles(XXX), I reckon.
Again with the double underscores. :)
Yes. That's why I said "at least as good". I'm starting to think we need a
 separate namespace for the CT stuff.

   D.compiles(XXX)
   D.typeof(foo)
   D.stringof(T)
   D.allMembers(T)
That's not bad. Can't be 'D', though, has to look like a keyword. Maybe something like 'traits' instead. In exchange, get rid of the '__traits' and 'typeid' keywords. Not sure about typeof, though. traits.compiles(XXX) traits.typeid(TTT) traits.stringof(T) traits.allMembers(T) traits.error("message"); IMHO this looks better than __traits(compiles, XXX) but it actually has the same flexibility, and it's a straightforward transformation inside the compiler. For bonus points, allow 'with(traits)': with(traits) { if (compiles(XXX)) return stringof(T); else error("Can't use " ~ stringof(T) ~ " in a transmogrifier."); }
I like it. It's a clean, simple solution. The std.traits module will just have to be renamed to std.meta or something. Or one could possibly use 'meta' as the new keyword: meta.compiles(XXX) meta.typeid(T) meta.stringof(T) Actually, I think I like that better than 'traits'. -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it. Justin
Oct 30 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
 Actually, I think I like that better than 'traits'.
 
 -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it.
"compiler"? That could open the door to other types of access to compiler internals, AST, etc. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Yo soy peperino el que siempre pone el vino, yo soy aquel que come los huevos con tocino. -- Peperino Pómoro
Oct 30 2009
parent reply Don <nospam nospam.com> writes:
Leandro Lucarella wrote:
 Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
 Actually, I think I like that better than 'traits'.

 -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it.
"compiler"? That could open the door to other types of access to compiler internals, AST, etc.
Yup. I think the 'magic namespace' approach is a simple, clean way to incorporate reflection. It could be like Object and TypeInfo, implicitly available in every module and tightly coupled to the compiler, but can be viewed by the user as if it were just a module. It'd be particularly interesting if some of the functions _were_ actually implemented in library code, when possible.
Oct 30 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Don Wrote:

 Leandro Lucarella wrote:
 Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
 Actually, I think I like that better than 'traits'.

 -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it.
"compiler"? That could open the door to other types of access to compiler internals, AST, etc.
Yup. I think the 'magic namespace' approach is a simple, clean way to incorporate reflection. It could be like Object and TypeInfo, implicitly available in every module and tightly coupled to the compiler, but can be viewed by the user as if it were just a module. It'd be particularly interesting if some of the functions _were_ actually implemented in library code, when possible.
What about going one step further? You could require an import statement to use traits. For example, import traits=std.traits could reproduce your earlier suggestion, but gives added flexibility to the programmer. It also eliminates a keyword.
Oct 30 2009
parent reply Don <nospam nospam.com> writes:
Jason House wrote:
 Don Wrote:
 
 Leandro Lucarella wrote:
 Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
 Actually, I think I like that better than 'traits'.

 -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it.
"compiler"? That could open the door to other types of access to compiler internals, AST, etc.
Yup. I think the 'magic namespace' approach is a simple, clean way to incorporate reflection. It could be like Object and TypeInfo, implicitly available in every module and tightly coupled to the compiler, but can be viewed by the user as if it were just a module. It'd be particularly interesting if some of the functions _were_ actually implemented in library code, when possible.
What about going one step further? You could require an import statement to use traits. For example, import traits=std.traits could reproduce your earlier suggestion, but gives added flexibility to the programmer. It also eliminates a keyword.
It's too fundamental for that. You can't use template constraints without it. BTW, 'scope' is another possible magic namespace. scope.compiles(XXX) -- true if XXX compiles in the current scope. More generally, scope.YYY() would provide metaprogramming information about the property YYY of the current scope.
Nov 02 2009
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:
 Jason House wrote:
 Don Wrote:

 Leandro Lucarella wrote:
 Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
 Actually, I think I like that better than 'traits'.

 -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it.
"compiler"? That could open the door to other types of access to compiler internals, AST, etc.
Yup. I think the 'magic namespace' approach is a simple, clean way to incorporate reflection. It could be like Object and TypeInfo, implicitly available in every module and tightly coupled to the compiler, but can be viewed by the user as if it were just a module. It'd be particularly interesting if some of the functions _were_ actually implemented in library code, when possible.
What about going one step further? You could require an import statement to use traits. For example, import traits=std.traits could reproduce your earlier suggestion, but gives added flexibility to the programmer. It also eliminates a keyword.
It's too fundamental for that. You can't use template constraints without it. BTW, 'scope' is another possible magic namespace. scope.compiles(XXX) -- true if XXX compiles in the current scope. More generally, scope.YYY() would provide metaprogramming information about the property YYY of the current scope.
Do you mean in addition to or instead of the already proposed traits/meta/compiler namespace? If it's just about avoiding new keywords I think this feature is fundamental enough to deserve its own keyword, and all of the above are more descriptive than 'scope'. Is this "magic namespace" proposal technically difficult to implement in the compiler? -Lars
Nov 02 2009
parent reply Don <nospam nospam.com> writes:
Lars T. Kyllingstad wrote:
 Don wrote:
 Jason House wrote:
 Don Wrote:

 Leandro Lucarella wrote:
 Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
 Actually, I think I like that better than 'traits'.

 -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it.
"compiler"? That could open the door to other types of access to compiler internals, AST, etc.
Yup. I think the 'magic namespace' approach is a simple, clean way to incorporate reflection. It could be like Object and TypeInfo, implicitly available in every module and tightly coupled to the compiler, but can be viewed by the user as if it were just a module. It'd be particularly interesting if some of the functions _were_ actually implemented in library code, when possible.
What about going one step further? You could require an import statement to use traits. For example, import traits=std.traits could reproduce your earlier suggestion, but gives added flexibility to the programmer. It also eliminates a keyword.
It's too fundamental for that. You can't use template constraints without it. BTW, 'scope' is another possible magic namespace. scope.compiles(XXX) -- true if XXX compiles in the current scope. More generally, scope.YYY() would provide metaprogramming information about the property YYY of the current scope.
Do you mean in addition to or instead of the already proposed traits/meta/compiler namespace?
It's another namespace suggestion. Just brainstorming.
 If it's just about avoiding new keywords I think this feature is 
 fundamental enough to deserve its own keyword, and all of the above are 
 more descriptive than 'scope'.
 
 Is this "magic namespace" proposal technically difficult to implement in 
 the compiler?
See for yourself. For example, the patch below (against svn 234) allows '__traits' as the magic namespace. The existing __traits stuff continues to compile. <g> __traits.compiles(XXX); __traits.isArithmetic; // note, property syntax OK if no arguments __traits.isArithmetic(int*); (Any error messages involving __traits are wrong, of course). Index: parse.c =================================================================== --- parse.c (revision 234) +++ parse.c (working copy) -4934,6 +4934,20 Objects *args = NULL; nextToken(); + if (token.value == TOKdot) { + // __traits.identifier(args, ...) + nextToken(); + if (token.value != TOKidentifier) + { error("__traits.identifier(args...) expected"); + goto Lerr; + } + ident = token.ident; + nextToken(); + if (token.value==TOKlparen) + args = parseTemplateArgumentList2(); + e = new TraitsExp(loc, ident, args); + break; + } check(TOKlparen); if (token.value != TOKidentifier) { error("__traits(identifier, args...) expected");
Nov 02 2009
parent Don <nospam nospam.com> writes:
Don wrote:
 Lars T. Kyllingstad wrote:
 Don wrote:
 Jason House wrote:
 Don Wrote:

 Leandro Lucarella wrote:
 Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
 Actually, I think I like that better than 'traits'.

 -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it.
"compiler"? That could open the door to other types of access to compiler internals, AST, etc.
Yup. I think the 'magic namespace' approach is a simple, clean way to incorporate reflection. It could be like Object and TypeInfo, implicitly available in every module and tightly coupled to the compiler, but can be viewed by the user as if it were just a module. It'd be particularly interesting if some of the functions _were_ actually implemented in library code, when possible.
What about going one step further? You could require an import statement to use traits. For example, import traits=std.traits could reproduce your earlier suggestion, but gives added flexibility to the programmer. It also eliminates a keyword.
It's too fundamental for that. You can't use template constraints without it. BTW, 'scope' is another possible magic namespace. scope.compiles(XXX) -- true if XXX compiles in the current scope. More generally, scope.YYY() would provide metaprogramming information about the property YYY of the current scope.
Do you mean in addition to or instead of the already proposed traits/meta/compiler namespace?
It's another namespace suggestion. Just brainstorming.
 If it's just about avoiding new keywords I think this feature is 
 fundamental enough to deserve its own keyword, and all of the above 
 are more descriptive than 'scope'.

 Is this "magic namespace" proposal technically difficult to implement 
 in the compiler?
See for yourself. For example, the patch below (against svn 234) allows '__traits' as the magic namespace. The existing __traits stuff continues to compile. <g>
And BTW, to allow 'meta' as another synonym for the same magic namespace, add this line to lexer.c, line 2960. { "__traits", TOKtraits }, + { "meta", TOKtraits }, { "__overloadset", TOKoverloadset }, (Hmm. Didn't know __overloadset was a keyword. The things you find...)
Nov 02 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Don, el  2 de noviembre a las 11:14 me escribiste:
 Jason House wrote:
Don Wrote:

Leandro Lucarella wrote:
Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
Actually, I think I like that better than 'traits'.

-Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it.
"compiler"? That could open the door to other types of access to compiler internals, AST, etc.
Yup. I think the 'magic namespace' approach is a simple, clean way to incorporate reflection. It could be like Object and TypeInfo, implicitly available in every module and tightly coupled to the compiler, but can be viewed by the user as if it were just a module. It'd be particularly interesting if some of the functions _were_ actually implemented in library code, when possible.
What about going one step further? You could require an import statement to use traits. For example, import traits=std.traits could reproduce your earlier suggestion, but gives added flexibility to the programmer. It also eliminates a keyword.
It's too fundamental for that. You can't use template constraints without it. BTW, 'scope' is another possible magic namespace. scope.compiles(XXX) -- true if XXX compiles in the current scope. More generally, scope.YYY() would provide metaprogramming information about the property YYY of the current scope.
And what about scope(exit) and friends? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Borrowing money from a friend is like having sex. It just completely changes the relationship. -- George Constanza
Nov 02 2009
prev sibling parent grauzone <none example.net> writes:
Don wrote:
 Jason House wrote:
 Don Wrote:

 Leandro Lucarella wrote:
 Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
 Actually, I think I like that better than 'traits'.

 -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it.
"compiler"? That could open the door to other types of access to compiler internals, AST, etc.
Yup. I think the 'magic namespace' approach is a simple, clean way to incorporate reflection. It could be like Object and TypeInfo, implicitly available in every module and tightly coupled to the compiler, but can be viewed by the user as if it were just a module. It'd be particularly interesting if some of the functions _were_ actually implemented in library code, when possible.
What about going one step further? You could require an import statement to use traits. For example, import traits=std.traits could reproduce your earlier suggestion, but gives added flexibility to the programmer. It also eliminates a keyword.
It's too fundamental for that. You can't use template constraints without it. BTW, 'scope' is another possible magic namespace. scope.compiles(XXX) -- true if XXX compiles in the current scope. More generally, scope.YYY() would provide metaprogramming information about the property YYY of the current scope.
I suggest we use static. static.YYY(), doesn't look that lovely?
Nov 02 2009
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
Don wrote:
  I'm starting to think we need a
 separate namespace for the CT stuff.

   D.compiles(XXX)
   D.typeof(foo)
   D.stringof(T)
   D.allMembers(T)
That's not bad. Can't be 'D', though, has to look like a keyword. Maybe something like 'traits' instead. In exchange, get rid of the '__traits' and 'typeid' keywords. Not sure about typeof, though. traits.compiles(XXX) traits.typeid(TTT) traits.stringof(T) traits.allMembers(T) traits.error("message"); IMHO this looks better than __traits(compiles, XXX) but it actually has the same flexibility, and it's a straightforward transformation inside the compiler. For bonus points, allow 'with(traits)': with(traits) { if (compiles(XXX)) return stringof(T); else error("Can't use " ~ stringof(T) ~ " in a transmogrifier."); }
This could even be implemented in phobos (or object.d to avoid an import when you want to use it), using something like: pragma(traits) struct traits { // Members automatically added by the compiler, or maybe just their // declarations eg: static T delegate()[] allMembers(T)(T type); } This way there's no need to force a certain name, as it can be chosen by the developer (by either using renaming imports or just giving the struct a different name eg pragma(traits) struct meta {}).
Oct 30 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:hcg0qr$fce$1 digitalmars.com...
 Don wrote:
  I'm starting to think we need a
 separate namespace for the CT stuff.

   D.compiles(XXX)
   D.typeof(foo)
   D.stringof(T)
   D.allMembers(T)
That's not bad. Can't be 'D', though, has to look like a keyword. Maybe something like 'traits' instead. In exchange, get rid of the '__traits' and 'typeid' keywords. Not sure about typeof, though. traits.compiles(XXX) traits.typeid(TTT) traits.stringof(T) traits.allMembers(T) traits.error("message"); IMHO this looks better than __traits(compiles, XXX) but it actually has the same flexibility, and it's a straightforward transformation inside the compiler. For bonus points, allow 'with(traits)': with(traits) { if (compiles(XXX)) return stringof(T); else error("Can't use " ~ stringof(T) ~ " in a transmogrifier."); }
This could even be implemented in phobos (or object.d to avoid an import when you want to use it), using something like: pragma(traits) struct traits { // Members automatically added by the compiler, or maybe just their // declarations eg: static T delegate()[] allMembers(T)(T type); } This way there's no need to force a certain name, as it can be chosen by the developer (by either using renaming imports or just giving the struct a different name eg pragma(traits) struct meta {}).
I'm not sure I see the value in being able to rename that. That's like making sure people can rename "for".
Oct 30 2009
parent Robert Clipsham <robert octarineparrot.com> writes:
Nick Sabalausky wrote:
 I'm not sure I see the value in being able to rename that. That's like 
 making sure people can rename "for".
I don't either, that's just a nice side effect for people who dislike whatever name is decided on.
Oct 31 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Lars T. Kyllingstad wrote:
 What I cannot for the life of me understand is WHY the double 
 underscores? What's wrong with just "traits"?
Because D needed the feature, and it wasn't clear what a good syntax for it would be. So __traits is a "put something out there, make it work, if it proves its usefulness and a good syntax for it appears, then that can be adopted."
Oct 29 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 29 de octubre a las 16:06 me escribiste:
 Lars T. Kyllingstad wrote:
What I cannot for the life of me understand is WHY the double
underscores? What's wrong with just "traits"?
Because D needed the feature, and it wasn't clear what a good syntax for it would be. So __traits is a "put something out there, make it work, if it proves its usefulness and a good syntax for it appears, then that can be adopted."
And now, being moderately close to D2 stabilization, isn't a good moment to think about a better syntax or just live with traits() as it is (but without the leading __)? Same for __gshared. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Es mucho mas probable que el salchichón sea primavera a que la primavera sea salchichón. -- Peperino Pómoro
Oct 29 2009
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Leandro Lucarella wrote:
 Walter Bright, el 29 de octubre a las 16:06 me escribiste:
 Lars T. Kyllingstad wrote:
 What I cannot for the life of me understand is WHY the double
 underscores? What's wrong with just "traits"?
Because D needed the feature, and it wasn't clear what a good syntax for it would be. So __traits is a "put something out there, make it work, if it proves its usefulness and a good syntax for it appears, then that can be adopted."
And now, being moderately close to D2 stabilization, isn't a good moment to think about a better syntax or just live with traits() as it is (but without the leading __)? Same for __gshared.
I'm not convinced about __gshared. As far as I've understood, __gshared is a "don't use this unless you know what you are doing" feature. As such, it should probably be a bit ugly. __traits(), on the other hand, is more of a "hey you guys, you should try this traits thing, it's totally neat" feature. -Lars
Oct 30 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Lars T. Kyllingstad, el 30 de octubre a las 08:55 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 29 de octubre a las 16:06 me escribiste:
Lars T. Kyllingstad wrote:
What I cannot for the life of me understand is WHY the double
underscores? What's wrong with just "traits"?
Because D needed the feature, and it wasn't clear what a good syntax for it would be. So __traits is a "put something out there, make it work, if it proves its usefulness and a good syntax for it appears, then that can be adopted."
And now, being moderately close to D2 stabilization, isn't a good moment to think about a better syntax or just live with traits() as it is (but without the leading __)? Same for __gshared.
I'm not convinced about __gshared. As far as I've understood, __gshared is a "don't use this unless you know what you are doing" feature. As such, it should probably be a bit ugly.
D is a system programming language. I don't see why one should be over patronizing. It's enough to clarify what the keyword does in the documentation. __gshared is not *that* rare, if you are interfacing with C, every C global have to be __gshared, it just makes the code uglier for no reason. Maybe it can be renamed to cglobal? I think we need a good descriptive name so people can know what it's about, not an ugly obfuscated one to confuse and scare them. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- I can't watch TV for four minutes without thinking I have five serious diseases. Like: "Do you ever wake up tired in the mornings?" Oh my god I have this, write this down. Whatever it is, I have this.
Oct 30 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Denis Koroskin Wrote:

 On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad  
 <public kyllingen.nospamnet> wrote:
 
 I don't think he uses is(typeof(...)) in the text. The code snippets in  
 question are marked "Note: normally the code below would not be  
 included...", and I suppose he's put them there as a reminder for  
 himself and Walter on what needs to be fixed before the book comes out.

 I agree with you, though, is(typeof(...)) is quite often misused, or at  
 least used in an ugly way. Why not use __traits(compiles, ...) instead?

 -Lars
... which is at least as ugly.
I disagree. Code that isn't readily understandable is uglier than readable code. Certainly, __traits is ugly, but it is easier to understand when readig code and easier to write.
Oct 29 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 29 Oct 2009 15:32:51 +0300, Jason House  
<jason.james.house gmail.com> wrote:

 Denis Koroskin Wrote:

 On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:

 I don't think he uses is(typeof(...)) in the text. The code snippets  
in
 question are marked "Note: normally the code below would not be
 included...", and I suppose he's put them there as a reminder for
 himself and Walter on what needs to be fixed before the book comes  
out.
 I agree with you, though, is(typeof(...)) is quite often misused, or  
at
 least used in an ugly way. Why not use __traits(compiles, ...)  
instead?
 -Lars
... which is at least as ugly.
I disagree. Code that isn't readily understandable is uglier than readable code. Certainly, __traits is ugly, but it is easier to understand when readig code and easier to write.
I was talking about ugliness, not readability. There are only 2 places where is(typeof(...)) feature is used: assert(is(typeof(somePrimes) == int[])); // perfectly fine IMO static assert(!is(typeof(a[length - 1]))); // misused, yes BTW, typeof is a bit inconsistent with .stringof, .alignof, .sizeof etc (typeof(foo) but foo.sizeof). Any chance this inconsistency is going to be fixed? Either assert(typeof(x + y) == int); -> assert(is((x + y).typeof == int)); Or assert((x + y).sizeof == 4); -> assert(is(sizeof(x + y) == 4);
Oct 29 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet? Also, on page 8? a code comment says average of a and b even though the variables don't exist.
Thanks, fixed. I also would like to see is expressions improved, but so far we couldn't find a good solution. There is a proposal currently in Bugzilla which may improve things. Andrei
Oct 29 2009
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
 
 
 Andrei
Maybe I haven't been paying attention lately, but shouldn't assert(x == 0) be assert(x[] == 0) ?
Oct 29 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer wrote:
 Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Maybe I haven't been paying attention lately, but shouldn't assert(x == 0) be assert(x[] == 0) ?
Where does the former occur? Thanks, Andrei
Oct 29 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:
 Ellery Newcomer wrote:
 Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Maybe I haven't been paying attention lately, but shouldn't assert(x == 0) be assert(x[] == 0) ?
Where does the former occur? Thanks, Andrei
top of page 102
Oct 29 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer wrote:
 Andrei Alexandrescu wrote:
 Ellery Newcomer wrote:
 Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Maybe I haven't been paying attention lately, but shouldn't assert(x == 0) be assert(x[] == 0) ?
Where does the former occur? Thanks, Andrei
top of page 102
Thanks. Notice that x is an integer because it was fetched as array[5]. Andrei
Oct 29 2009
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:
 Ellery Newcomer wrote:
 Andrei Alexandrescu wrote:
 Ellery Newcomer wrote:
 Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Maybe I haven't been paying attention lately, but shouldn't assert(x == 0) be assert(x[] == 0) ?
Where does the former occur? Thanks, Andrei
top of page 102
Thanks. Notice that x is an integer because it was fetched as array[5]. Andrei
Oh wow. I'm dyslexic.
Oct 29 2009
prev sibling next sibling parent reply "Saaa" <empty needmail.com> writes:
Andrei Alexandrescu wrote
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Makes me want to read the rest! Will we get the electronic version with the paper version? p2. typo: eenlists p9. Is it ok to expect the order of an array expression to be like in foreach ? Maybe mention a[] = b. p11. typo: no(t) palindrome p12. Should in a safe module "~=" always create a new array? p14. further expansions reads as if expansions have been made especially because the comment is maybe that obvious that I was looking for something else to be there. p16. Is there anything other than the random values, unsafe about void assignment? When you write something to be unsafe, I expect it to not be allowed safe modules. p18. What is unsafe about implicit conversion of static to dynamic array? Meaning getting a dynamic array pointing to a stack allocated array. Any operation changing its size could copy the array to the heap. What am I missing p20. An alternative to figure 4.5 could display row/column properties. p20. change 1,000,000 to 1_000_000 :D to me the comma is a decimal separator anyways. p20. 40 words? <<<< p21. Why use enum iso immutable? Probably in the previous chapters explained :) p21. Second paragraph reads as a solution to the above p22. typo: array!literal p25. Expected to read about ref in foreach That's all :)
Oct 29 2009
next sibling parent "Saaa" <empty needmail.com> writes:
Also, no mention about .dup not being a deep dup. 
Oct 29 2009
prev sibling next sibling parent "Saaa" <empty needmail.com> writes:
crp
 p20. 40 words? <<<<
those <<<< where for myself, to check
Oct 29 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Saaa wrote:
 Will we get the electronic version with the paper version?
I'm not exactly sure how things will roll out. Probably yes.
 p2. typo: eenlists
 p9. Is it ok to expect the order of an array expression to be like in 
 foreach ?
       Maybe mention a[] = b.
 p11. typo: no(t) palindrome
 p12. Should in a safe module "~=" always create a new array?
 p14. further expansions reads as if expansions have been made
         especially because the comment is maybe that obvious that I was 
 looking for something else to be there.
 p16. Is there anything other than the random values, unsafe about void 
 assignment?
         When you write something to be unsafe, I expect it to not be allowed 
 safe modules.
 p18. What is unsafe about implicit conversion of static to dynamic array?
         Meaning getting a dynamic array pointing to a stack allocated array.
         Any operation changing its size could copy the array to the heap. 
 What am I missing
 p20. An alternative to figure 4.5 could display row/column properties.
 p20. change 1,000,000 to 1_000_000 :D to me the comma is a decimal separator 
 anyways.
 p20. 40 words? <<<<
 p21. Why use enum iso immutable? Probably in the previous chapters explained 
 :)
 p21. Second paragraph reads as a solution to the above
 p22. typo: array!literal
 p25. Expected to read about ref in foreach
 
 That's all :) 
Thanks much! Andrei
Oct 29 2009
prev sibling parent reply "Saaa" <empty needmail.com> writes:
Could anybody clear these up for me?

 p16. Is there anything other than the random values, unsafe about void 
 assignment?
 p18. What is unsafe about implicit conversion of static to dynamic array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the heap. 
 What am I missing
 p20. 10 int take up 40 words?
Thanks!
Oct 30 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Saaa wrote:
 Could anybody clear these up for me?
 
 p16. Is there anything other than the random values, unsafe about void 
 assignment?
I'd put your feedback on my pile of things to do, but now that you ask, I made this change to the incriminated paragraph: =========== Such uninitialized arrays are particularly useful for large arrays that serve as temporary buffers. An uninitialized integral may not cause too much harm, but uninitialized values of types with indirections (such as arrays themselves) are unsafe. ===========
 p18. What is unsafe about implicit conversion of static to dynamic array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the heap. 
 What am I missing
T[] fun() { T[10] a; return a; } ... auto x = fun(); // gained access to recycled stack memory There's no change in size there.
 p20. 10 int take up 40 words?
The example given has a per-row payload of 10 ints, i.e. 40 words. Andrei
Oct 30 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrei Alexandrescu wrote:
 Saaa wrote:
 Could anybody clear these up for me?

 p16. Is there anything other than the random values, unsafe about 
 void assignment?
I'd put your feedback on my pile of things to do, but now that you ask, I made this change to the incriminated paragraph: =========== Such uninitialized arrays are particularly useful for large arrays that serve as temporary buffers. An uninitialized integral may not cause too much harm, but uninitialized values of types with indirections (such as arrays themselves) are unsafe. ===========
 p18. What is unsafe about implicit conversion of static to dynamic 
 array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the 
 heap. What am I missing
T[] fun() { T[10] a; return a; } ... auto x = fun(); // gained access to recycled stack memory There's no change in size there.
 p20. 10 int take up 40 words?
The example given has a per-row payload of 10 ints, i.e. 40 words.
It's bytes actually. So finally I rewrote those last words as: "... small per-row payload of~10 int s (40 bytes)." Andrei
Oct 30 2009
parent reply "Saaa" <empty needmail.com> writes:
Andrei Alexandrescu wrote:
 Andrei Alexandrescu wrote:
 Saaa wrote:
 Could anybody clear these up for me?

 p16. Is there anything other than the random values, unsafe about void 
 assignment?
I'd put your feedback on my pile of things to do, but now that you ask, I made this change to the incriminated paragraph: =========== Such uninitialized arrays are particularly useful for large arrays that serve as temporary buffers. An uninitialized integral may not cause too much harm, but uninitialized values of types with indirections (such as arrays themselves) are unsafe. ===========
 p18. What is unsafe about implicit conversion of static to dynamic 
 array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the 
 heap. What am I missing
T[] fun() { T[10] a; return a; } ... auto x = fun(); // gained access to recycled stack memory There's no change in size there.
 p20. 10 int take up 40 words?
The example given has a per-row payload of 10 ints, i.e. 40 words.
It's bytes actually. So finally I rewrote those last words as: "... small per-row payload of~10 int s (40 bytes)." Andrei
Thanks ! Out of interest, do you keep a list of common error or something alike that helps you keep errors at a minimum? Also, do you have automated example checking? Or, more general, I would be interested in a small article explaining how a book like this is written. Maybe After the book is finished :)
Oct 30 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Saaa wrote:
 Andrei Alexandrescu wrote:
 Andrei Alexandrescu wrote:
 Saaa wrote:
 Could anybody clear these up for me?

 p16. Is there anything other than the random values, unsafe about void 
 assignment?
I'd put your feedback on my pile of things to do, but now that you ask, I made this change to the incriminated paragraph: =========== Such uninitialized arrays are particularly useful for large arrays that serve as temporary buffers. An uninitialized integral may not cause too much harm, but uninitialized values of types with indirections (such as arrays themselves) are unsafe. ===========
 p18. What is unsafe about implicit conversion of static to dynamic 
 array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the 
 heap. What am I missing
T[] fun() { T[10] a; return a; } ... auto x = fun(); // gained access to recycled stack memory There's no change in size there.
 p20. 10 int take up 40 words?
The example given has a per-row payload of 10 ints, i.e. 40 words.
It's bytes actually. So finally I rewrote those last words as: "... small per-row payload of~10 int s (40 bytes)." Andrei
Thanks ! Out of interest, do you keep a list of common error or something alike that helps you keep errors at a minimum?
I got as sophisticated as having an email folder dedicated to TDPL.
 Also, do you have automated example checking?
Yes. If you look at the document very closely, you'll see that some snippets have a thin line above and below them. Those are automatically checked every time I save the document. (There are 1-2 examples that aren't checked in the Thermopylae excerpt because I switched editing to a 64-bit machine that can't build D programs (I'll post a question later today). But in the meantime I fixed those.) Very short snippets do not have a thin line above and below them. Those are not checked because they are short enough to warrant that I know what I'm doing. Some checked snippets wouldn't compile without being in a function, for example: enum size_t columns = 128; // Allocate a matrix with 64 rows and 128 columns auto matrix = new double[columns][64]; // No need to allocate each row - they already exist in-situ foreach (ref row; matrix) { ... // use row of type double[columns] } These are automatically entered inside a unittest. Also, my code extraction script (written in D!) automatically eliminates unneeded "...", so the code as seen by the compiler is: unittest { enum size_t columns = 128; // Allocate a matrix with 64 rows and 128 columns auto matrix = new double[columns][64]; // No need to allocate each row - they already exist in-situ foreach (ref row; matrix) { // use row of type double[columns] } } which passes compilation. Some other examples need "invisible" support: writeln("hey"); For those I have a special mechanism to insert invisible code, so my text for the above actually looks like this: \begin{D-invisible} import std.stdio; \end{D-invisible} \begin{D-snippet} writeln("hey"); \end{D-snippet} What the compiler sees is a file importing std.stdio and including the writeln inside a unittest. I wouldn't know how to pull this off reasonably with e.g. Word, but I'm sure it now has mechanisms or extensions that allow that kind of thing. One thing I don't need to worry about with LaTeX is that it's text-based so I can process it easily myself.
 Or, more general, I would be interested in a small article explaining how a 
 book like this is written.
 
 Maybe After the book is finished :) 
I think the topic is well worth an article indeed. I continuously streamline the process of building the book, and it's gotten pretty sophisticated but very helpful as well. Index building is also an interesting subtopic. Andrei
Oct 30 2009
parent "Saaa" <empty needmail.com> writes:
Andrei Alexandrescu wrote
 Saaa wrote:
 Andrei Alexandrescu wrote:
 Andrei Alexandrescu wrote:
 Saaa wrote:
 Could anybody clear these up for me?

 p16. Is there anything other than the random values, unsafe about 
 void assignment?
I'd put your feedback on my pile of things to do, but now that you ask, I made this change to the incriminated paragraph: =========== Such uninitialized arrays are particularly useful for large arrays that serve as temporary buffers. An uninitialized integral may not cause too much harm, but uninitialized values of types with indirections (such as arrays themselves) are unsafe. ===========
 p18. What is unsafe about implicit conversion of static to dynamic 
 array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the 
 heap. What am I missing
T[] fun() { T[10] a; return a; } ... auto x = fun(); // gained access to recycled stack memory There's no change in size there.
 p20. 10 int take up 40 words?
The example given has a per-row payload of 10 ints, i.e. 40 words.
It's bytes actually. So finally I rewrote those last words as: "... small per-row payload of~10 int s (40 bytes)." Andrei
Thanks ! Out of interest, do you keep a list of common error or something alike that helps you keep errors at a minimum?
I got as sophisticated as having an email folder dedicated to TDPL.
 Also, do you have automated example checking?
Yes. If you look at the document very closely, you'll see that some snippets have a thin line above and below them. Those are automatically checked every time I save the document. (There are 1-2 examples that aren't checked in the Thermopylae excerpt because I switched editing to a 64-bit machine that can't build D programs (I'll post a question later today). But in the meantime I fixed those.) Very short snippets do not have a thin line above and below them. Those are not checked because they are short enough to warrant that I know what I'm doing.
:)
 Some checked snippets wouldn't compile without being in a function, for 
 example:

 enum size_t columns = 128;
 // Allocate a matrix with 64 rows and 128 columns
 auto matrix = new double[columns][64];
 // No need to allocate each row - they already exist in-situ
 foreach (ref row; matrix) {
    ... // use row of type double[columns]
 }

 These are automatically entered inside a unittest. Also, my code 
 extraction script (written in D!) automatically eliminates unneeded
I Wouldn't accept it being written in C++ !! :D
 "...", so the code as seen by the compiler is:

 unittest {
 enum size_t columns = 128;
 // Allocate a matrix with 64 rows and 128 columns
 auto matrix = new double[columns][64];
 // No need to allocate each row - they already exist in-situ
 foreach (ref row; matrix) {
     // use row of type double[columns]
 }
 }

 which passes compilation.

 Some other examples need "invisible" support:

 writeln("hey");

 For those I have a special mechanism to insert invisible code, so my text 
 for the above actually looks like this:

 \begin{D-invisible}
 import std.stdio;
 \end{D-invisible}
 \begin{D-snippet}
 writeln("hey");
 \end{D-snippet}

 What the compiler sees is a file importing std.stdio and including the 
 writeln inside a unittest.
nice
 I wouldn't know how to pull this off reasonably with e.g. Word, but I'm 
 sure it now has mechanisms or extensions that allow that kind of thing. 
 One thing I don't need to worry about with LaTeX is that it's text-based 
 so I can process it easily myself.
Somehow I only associate LaTeX with b/w scientific articles :)
 Or, more general, I would be interested in a small article explaining how 
 a book like this is written.

 Maybe After the book is finished :)
I think the topic is well worth an article indeed. I continuously streamline the process of building the book, and it's gotten pretty sophisticated but very helpful as well. Index building is also an interesting subtopic. Andrei
Thanks, looking forward to the article ( and the tools used :P )
Oct 30 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
It looks very nice. A small error in 4.1.7 first code block: auto a = new double[4]; // must be already allocated auto a1 = [ 0.5, -0.5, 1.5, 2 ]; auto a2 = [ 3.5, 5.5, 4.5, -1 ]; a[] = (a1[] + a2[]) / 2; // take the average of b and c ^^^^^^^^^^^^^^^^^^^^^^^^^^^ take the average of a1 and a2? (I think it would be easier to follow using b and c though ;) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Cuando intenté arrimarle mi brazo Se puso a hablar de Miller, de Anais Nin y Picasso Y si osaba intentar robarle un beso Se ponía a leer de Neruda unos versos Me hizo mucho mal la cumbiera intelectual
Oct 29 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
 Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
It looks very nice. A small error in 4.1.7 first code block: auto a = new double[4]; // must be already allocated auto a1 = [ 0.5, -0.5, 1.5, 2 ]; auto a2 = [ 3.5, 5.5, 4.5, -1 ]; a[] = (a1[] + a2[]) / 2; // take the average of b and c ^^^^^^^^^^^^^^^^^^^^^^^^^^^ take the average of a1 and a2? (I think it would be easier to follow using b and c though ;)
BTW, it looks like array literals will be dynamic arrays, from the code in your book. Can you or Walter explain why this is better to make array literals statically stored immutable memory like strings (which adds an inconsistency to the language)? Is this just to avoid [1,2,3].dup; when you want to get a dynamic array from an array literal or is there other reasons? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- En la calle me crucé con un señor muy correcto, que habitualmente anda en Falcon; iba corriendo con dos valijas en la mano y dijo: "Voy para Miami, tiene algún mensaje o ..." y le dije: "No, no, no..." -- Extra Tato (1983, Triunfo de Alfonsín)
Oct 29 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Oct 29, 2009 at 9:31 AM, Leandro Lucarella <llucax gmail.com> wrote=
:
 Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
 Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
It looks very nice. A small error in 4.1.7 first code block: auto a =3D new double[4]; =A0 =A0 =A0 =A0 =A0// must be already allocate=
d
 auto a1 =3D [ 0.5, -0.5, 1.5, 2 ];
 auto a2 =3D [ 3.5, 5.5, 4.5, -1 ];
 a[] =3D (a1[] + a2[]) / 2; =A0 =A0 =A0 =A0 // take the average of b and =
c
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
^^^^^^^^^^^^^^^^^^^^^^^^^^^
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0t=
ake the average of a1 and a2?
 (I think it would be easier to follow using b and c though ;)
BTW, it looks like array literals will be dynamic arrays, from the code i=
n
 your book. Can you or Walter explain why this is better to make array
 literals statically stored immutable memory like strings (which adds an
 inconsistency to the language)? Is this just to avoid [1,2,3].dup; when
 you want to get a dynamic array from an array literal or is there other
 reasons?
It's in the chapter. Basically static arrays just aren't the common use ca= se. It is a bit of a bummer that there's no way to get a static array with the elements counted for you. Some folks suggested things like int[auto] =3D [1,2,3]; or int[$] =3D [1,2,3]; Something like that would be nice. --bb
Oct 29 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
 Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
It looks very nice. A small error in 4.1.7 first code block: auto a = new double[4]; // must be already allocated auto a1 = [ 0.5, -0.5, 1.5, 2 ]; auto a2 = [ 3.5, 5.5, 4.5, -1 ]; a[] = (a1[] + a2[]) / 2; // take the average of b and c ^^^^^^^^^^^^^^^^^^^^^^^^^^^ take the average of a1 and a2? (I think it would be easier to follow using b and c though ;)
BTW, it looks like array literals will be dynamic arrays, from the code in your book. Can you or Walter explain why this is better to make array literals statically stored immutable memory like strings (which adds an inconsistency to the language)? Is this just to avoid [1,2,3].dup; when you want to get a dynamic array from an array literal or is there other reasons?
I don't have a better explanation than the excerpt: Beware, however: if you replace int[3] above with auto , a 's type will be deduced as int[] , not int[3] . Although it seems logical that the type of \cc{[1, 2, 3]} should be int[3] which in a way is more ``precise'' than int[] , it turns out that dynamically-sized arrays are used much more often than fixed-size arrays, so insisting on fixed-size array literals would have been a usability impediment and a source of unpleasant surprises. Effectively, the use of literals would have prevented the gainful use of auto . As it is, array literals are T[] by default, and T[n] if you \emph{ask} for that specific type and if n matches the number of values in the literal (as the code above shows). Andrei
Oct 29 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 29 de octubre a las 12:23 me escribiste:
 Leandro Lucarella wrote:
Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
BTW, it looks like array literals will be dynamic arrays, from the code in your book. Can you or Walter explain why this is better to make array literals statically stored immutable memory like strings (which adds an inconsistency to the language)? Is this just to avoid [1,2,3].dup; when you want to get a dynamic array from an array literal or is there other reasons?
I don't have a better explanation than the excerpt: Beware, however: if you replace int[3] above with auto , a 's type will be deduced as int[] , not int[3] . Although it seems logical that the type of \cc{[1, 2, 3]} should be int[3] which in a way is more ``precise'' than int[] , it turns out that dynamically-sized arrays are used much more often than fixed-size arrays, so insisting on fixed-size array literals would have been a usability impediment and a source of unpleasant surprises. Effectively, the use of literals would have prevented the gainful use of auto . As it is, array literals are T[] by default, and T[n] if you \emph{ask} for that specific type and if n matches the number of values in the literal (as the code above shows).
I saw that, but I think introducing an inconsistency (and depart on how literals usually work) is worse than having to explicitly state the type or adding a .dup to the literal. But I guess it's just me. Another question about the book: you explain dynamic arrays are being represented by a start and end pointer, much like the STL, but that's not the real implementation. I know you say in the book that the implementation doesn't necessarily work like that, but I wonder if you decided to explain things like that because it's planned to change the dynamic arrays implementation or just because you found it more didactic. Thanks. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Algún día los libros desterrarán a la radio y el hombre descubrirá el oculto poder del Amargo Serrano. -- Ricardo Vaporeso. El Bolsón, 1909.
Oct 29 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el 29 de octubre a las 12:23 me escribiste:
 Leandro Lucarella wrote:
 Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
 Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
BTW, it looks like array literals will be dynamic arrays, from the code in your book. Can you or Walter explain why this is better to make array literals statically stored immutable memory like strings (which adds an inconsistency to the language)? Is this just to avoid [1,2,3].dup; when you want to get a dynamic array from an array literal or is there other reasons?
I don't have a better explanation than the excerpt: Beware, however: if you replace int[3] above with auto , a 's type will be deduced as int[] , not int[3] . Although it seems logical that the type of \cc{[1, 2, 3]} should be int[3] which in a way is more ``precise'' than int[] , it turns out that dynamically-sized arrays are used much more often than fixed-size arrays, so insisting on fixed-size array literals would have been a usability impediment and a source of unpleasant surprises. Effectively, the use of literals would have prevented the gainful use of auto . As it is, array literals are T[] by default, and T[n] if you \emph{ask} for that specific type and if n matches the number of values in the literal (as the code above shows).
I saw that, but I think introducing an inconsistency (and depart on how literals usually work) is worse than having to explicitly state the type or adding a .dup to the literal. But I guess it's just me.
It's me as well. The decision didn't go without a fight (I had your viewpoint and Walter didn't). He convinced me with two arguments. One is that 90% of the time you actually want T[], not T[n]. The second is that string literals already have dynamic (not static) type, although the most informative type would be fixed-size.
 Another question about the book: you explain dynamic arrays are being
 represented by a start and end pointer, much like the STL, but that's not
 the real implementation. I know you say in the book that the
 implementation doesn't necessarily work like that, but I wonder if you
 decided to explain things like that because it's planned to change the
 dynamic arrays implementation or just because you found it more didactic.
We will change the implementation at some point, but right now I hope I made it clear enough it's about the notion of a bounded chunk of typed memory, than the representation of it. Andrei
Oct 29 2009
next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On Thu, 29 Oct 2009 13:30:35 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

It's me as well. The decision didn't go without a fight (I had your 
viewpoint and Walter didn't). He convinced me with two arguments. One is 
that 90% of the time you actually want T[], not T[n].
The argument may be flawed because, out of those 90% of arrays, only small part may be initialized from array literals. Many (most?) are created with new or appended. I suspect dynamic arrays created from literals are as rare as static arrays in real world code. Probably, I'll investigate how exactly rare.
Oct 29 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 29 Oct 2009 21:59:13 +0300, Max Samukha <spambox d-coding.com>  
wrote:

 On Thu, 29 Oct 2009 13:30:35 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 It's me as well. The decision didn't go without a fight (I had your
 viewpoint and Walter didn't). He convinced me with two arguments. One is
 that 90% of the time you actually want T[], not T[n].
The argument may be flawed because, out of those 90% of arrays, only small part may be initialized from array literals. Many (most?) are created with new or appended. I suspect dynamic arrays created from literals are as rare as static arrays in real world code. Probably, I'll investigate how exactly rare.
I agree. It also involves a hidden allocation and there is no way around it: int[] t = [0, 1, 2] ~ [3, 4, 5]; // how many allocations here take place? 1? No, 3!
Oct 29 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Max Samukha wrote:
 On Thu, 29 Oct 2009 13:30:35 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 It's me as well. The decision didn't go without a fight (I had your 
 viewpoint and Walter didn't). He convinced me with two arguments. One is 
 that 90% of the time you actually want T[], not T[n].
The argument may be flawed because, out of those 90% of arrays, only small part may be initialized from array literals. Many (most?) are created with new or appended. I suspect dynamic arrays created from literals are as rare as static arrays in real world code. Probably, I'll investigate how exactly rare.
Apparently the need was felt strongly enough that a library made it into Boost that does exactly initialization of collections (and vector in particular), in spite of being based on a very questionable design technique - overloading of the comma operator. Andrei
Oct 29 2009
parent reply Max Samukha <spambox d-coding.com> writes:
On Thu, 29 Oct 2009 16:07:14 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

Apparently the need was felt strongly enough that a library made it into 
Boost that does exactly initialization of collections (and vector in 
particular), in spite of being based on a very questionable design 
technique - overloading of the comma operator.

Andrei
I guess you mean the assignment library http://www.boost.org/doc/libs/1_40_0/libs/assign/doc/index.html. "These lists are particularly useful in learning, testing, and prototyping situations, but can also be handy otherwise." While those are important, I am still not totally convinced that dynamic arrays initialized from literals occur often in production code. It remains a matter of opinion.
Oct 31 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Max Samukha:

 While those are important, I am still not totally convinced that
 dynamic arrays initialized from literals occur often in production
 code. It remains a matter of opinion.
In script-like code literals are common. So when you consider your production code you must count that script-like code too. D is not a scripting language, but it offers some things that allow it to "scale down". Collection literals are one of the things that make D more handy than other lesser languages like C++. Bye, bearophile
Oct 31 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 29 de octubre a las 13:30 me escribiste:
 Leandro Lucarella wrote:
Andrei Alexandrescu, el 29 de octubre a las 12:23 me escribiste:
Leandro Lucarella wrote:
Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
BTW, it looks like array literals will be dynamic arrays, from the code in your book. Can you or Walter explain why this is better to make array literals statically stored immutable memory like strings (which adds an inconsistency to the language)? Is this just to avoid [1,2,3].dup; when you want to get a dynamic array from an array literal or is there other reasons?
I don't have a better explanation than the excerpt: Beware, however: if you replace int[3] above with auto , a 's type will be deduced as int[] , not int[3] . Although it seems logical that the type of \cc{[1, 2, 3]} should be int[3] which in a way is more ``precise'' than int[] , it turns out that dynamically-sized arrays are used much more often than fixed-size arrays, so insisting on fixed-size array literals would have been a usability impediment and a source of unpleasant surprises. Effectively, the use of literals would have prevented the gainful use of auto . As it is, array literals are T[] by default, and T[n] if you \emph{ask} for that specific type and if n matches the number of values in the literal (as the code above shows).
I saw that, but I think introducing an inconsistency (and depart on how literals usually work) is worse than having to explicitly state the type or adding a .dup to the literal. But I guess it's just me.
It's me as well. The decision didn't go without a fight (I had your viewpoint and Walter didn't).
Oh, ok. Thanks for the fight ;)
 He convinced me with two arguments.  One is that 90% of the time you
 actually want T[], not T[n].
I don't know how did he come up with that number. At least, talking about arrays that comes from a literal, I don't think that is the case. In a program I'm sure more than 90% of the array usage are dynamic arrays, but when talking about array literals I'm not very convinced, I think you usually just want an iterable from them.
 The second is that string literals already have dynamic (not static)
 type, although the most informative type would be fixed-size.
Damn! Are you saying that this: auto s = "hello"; Really does something like this in C: char* s = gc_malloc(5, NO_SCAN); memcpy(s, "hello", 5); ? I though it was just like C, a pointer to an statcally allocated memory block. What's the point to heap-allocate an immutable chunk of memory?
Another question about the book: you explain dynamic arrays are being
represented by a start and end pointer, much like the STL, but that's not
the real implementation. I know you say in the book that the
implementation doesn't necessarily work like that, but I wonder if you
decided to explain things like that because it's planned to change the
dynamic arrays implementation or just because you found it more didactic.
We will change the implementation at some point, but right now I hope I made it clear enough it's about the notion of a bounded chunk of typed memory, than the representation of it.
I think the point is taken, I was just curious about what's the plan. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Salvajes, de traje, me quieren enseñar Salvajes, de traje, me quieren educar
Oct 29 2009
prev sibling parent reply Michael Rynn <michaelrynn optusnet.com.au> writes:
On Thu, 29 Oct 2009 12:23:18 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

Leandro Lucarella wrote:
 Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
 Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
Good chapter, I learned some things, and I liked the Unicode exposition. Pg 114. 5 Did not understand why this code is a compiler bug. To me its a 'feature', consistant with behaviour of underlying realloc, capacity and length management, and consistant with having average good efficiency for a ~= item. I do not want a clever compiler trying to predict existance of an array aliasing. Its a nice example of aliasing, only it seems just a bit harsh on the poor old compiler. Not good to have every page virtually subtitled , nice language, shame about the compiler.. I would like to see a function in std.array for D2, that does efficiently what the example asserts should be possible, to force a new allocation when required, in a simple one line statement, syntactically sugared. // At this point a and b are adjacent //a ~= [0, 0, 0, 0]; /// Concantenation function which will gaurantee to return array using only single new memory allocation containing a ~ b, for when you really need it. // T[] concat(T[] a, T[] b) // maybe more varargs a = a.concat([0, 0, 0, 0]); // OR in 2 lines just make the intention clear auto c = a ~ b; // this should work just the same? a = c; assert(b == [40, 50, 60, 70]); // passes; a got reallocated P114. 40 array.length op= something. // compiler message that array.length is not an lvalue. I like the compiler message. Admittedly I would like the shorthand too, but I do not see it as bug, because it reflects the C heritage. Another feature. Would like at least these bugs to be features.. P 123. 30 You didn't mention the in operator for AA returns a pointer to the keys value, or null This got me a little worried, as I liked using the value returned by in operator, and had not used .get at all. P 128 20-25 .."To support this encoding, Unicode allocates no valid characters to numbers in the range 0xD800 through 0xDBFF" Typo , should be: 0xD800 through 0xDFFF here. -- Michael Rynn <michaelrynn optusnet.com.au>
Nov 03 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michael Rynn wrote:
 On Thu, 29 Oct 2009 12:23:18 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Leandro Lucarella wrote:
 Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
 Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
Good chapter, I learned some things, and I liked the Unicode exposition. Pg 114. 5 Did not understand why this code is a compiler bug. To me its a 'feature', consistant with behaviour of underlying realloc, capacity and length management, and consistant with having average good efficiency for a ~= item. I do not want a clever compiler trying to predict existance of an array aliasing. Its a nice example of aliasing, only it seems just a bit harsh on the poor old compiler. Not good to have every page virtually subtitled , nice language, shame about the compiler.. I would like to see a function in std.array for D2, that does efficiently what the example asserts should be possible, to force a new allocation when required, in a simple one line statement, syntactically sugared. // At this point a and b are adjacent //a ~= [0, 0, 0, 0]; /// Concantenation function which will gaurantee to return array using only single new memory allocation containing a ~ b, for when you really need it. // T[] concat(T[] a, T[] b) // maybe more varargs a = a.concat([0, 0, 0, 0]); // OR in 2 lines just make the intention clear auto c = a ~ b; // this should work just the same? a = c; assert(b == [40, 50, 60, 70]); // passes; a got reallocated P114. 40 array.length op= something. // compiler message that array.length is not an lvalue. I like the compiler message. Admittedly I would like the shorthand too, but I do not see it as bug, because it reflects the C heritage. Another feature. Would like at least these bugs to be features.. P 123. 30 You didn't mention the in operator for AA returns a pointer to the keys value, or null This got me a little worried, as I liked using the value returned by in operator, and had not used .get at all. P 128 20-25 .."To support this encoding, Unicode allocates no valid characters to numbers in the range 0xD800 through 0xDBFF" Typo , should be: 0xD800 through 0xDFFF here.
Thanks, I added this to my worklist. Andrei
Nov 03 2009
prev sibling next sibling parent reply "Saaa" <empty needmail.com> writes:
Also, no mention about .dup not being a deep dup. 
Oct 29 2009
next sibling parent "Saaa" <empty needmail.com> writes:
Saaa wrote
 Also, no mention about .dup not being a deep dup.
Sorry, should've been attached to my response
Oct 29 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Saaa wrote:
 Also, no mention about .dup not being a deep dup. 
I've put this on my todo list, but it's difficult. At this point people only know about statements and expressions, so it would be a bit difficult to introduce the subtleties of shallow vs. deep copying. I guess I'll have to do it. Andrei
Oct 29 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
It looks very nice. A small error in 4.1.7 first code block: auto a = new double[4]; // must be already allocated auto a1 = [ 0.5, -0.5, 1.5, 2 ]; auto a2 = [ 3.5, 5.5, 4.5, -1 ]; a[] = (a1[] + a2[]) / 2; // take the average of b and c ^^^^^^^^^^^^^^^^^^^^^^^^^^^ take the average of a1 and a2? (I think it would be easier to follow using b and c though ;)
Thanks! I fixed that to have a and b as sources and c as destination. Andrei
Oct 29 2009
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 29 Oct 2009 00:38:33 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 It's a rough rough draft, but one for the full chapter on arrays,  
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Still reading, but here's a quick comment. I found it odd that the syntax for element-wise copying (4.1.7) comes sections after the section on copying (4.1.4). Perhaps a sentence mentioning where element-wise copying can be found would be appropriate. (Props though on including a memory layout figure. It may not seem like much, but I've seen Java students have no idea what an array is in memory.)
Oct 29 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Thu, 29 Oct 2009 00:38:33 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Still reading, but here's a quick comment. I found it odd that the syntax for element-wise copying (4.1.7) comes sections after the section on copying (4.1.4). Perhaps a sentence mentioning where element-wise copying can be found would be appropriate. (Props though on including a memory layout figure. It may not seem like much, but I've seen Java students have no idea what an array is in memory.)
Good point, thanks. Andrei
Oct 29 2009
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
Thanks for the excerpt! I've only had the time to give it a brief skim so far, but it's looking good. This is what I found: p16: int quadrupeds[100], int legs[4 * quadrupeds.length] <- is the C-style array declaration syntax intended? p20: No mention of the "new T[][](rows, cols)" syntax? p26 (User-Defined Types as Keys): No need for opEquals? -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Oct 29 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tom S wrote:
 Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
Thanks for the excerpt! I've only had the time to give it a brief skim so far, but it's looking good. This is what I found: p16: int quadrupeds[100], int legs[4 * quadrupeds.length] <- is the C-style array declaration syntax intended?
Thanks, fixed.
 p20: No mention of the "new T[][](rows, cols)" syntax?
Oops, completely forgot about that one.
 p26 (User-Defined Types as Keys): No need for opEquals?
There currently is, but there shouldn't and it won't. Andrei
Oct 29 2009
prev sibling next sibling parent reply Manuel <manuel.peinado NOgmailSPAM.com> writes:
Andrei Alexandrescu Wrote:

 
 Any feedback is welcome. Thanks!
 
 
Thanks Andrei, that was an excellent read. Some comments: Page 102, line 23. I'm not a native English speaker, but it seems like you're missing a "such" in the sentence "there is a thing as a" Page 116, line 13: shouldn't "array" be defined as "= void", for efficiency? Section 4.3: As someone who is new to D, I would like to see an example involving a multidimensional array in which all dimensions are fixed. Something like int a[3][2] = [ ??? ];
Oct 29 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Manuel wrote:
 Andrei Alexandrescu Wrote:
 
 Any feedback is welcome. Thanks!
Thanks Andrei, that was an excellent read. Some comments: Page 102, line 23. I'm not a native English speaker, but it seems like you're missing a "such" in the sentence "there is a thing as a" Page 116, line 13: shouldn't "array" be defined as "= void", for efficiency? Section 4.3: As someone who is new to D, I would like to see an example involving a multidimensional array in which all dimensions are fixed. Something like int a[3][2] = [ ??? ];
Great feedback, thank you! Andrei
Oct 29 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet? Also, on page 8? a code comment says average of a and b even though the variables don't exist.
Thanks, fixed. I also would like to see is expressions improved, but so far we couldn't find a good solution. There is a proposal currently in Bugzilla which may improve things. Andrei
What's the bugzilla number?
Oct 30 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 Jason House wrote:
 Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet? Also, on page 8? a code comment says average of a and b even though the variables don't exist.
Thanks, fixed. I also would like to see is expressions improved, but so far we couldn't find a good solution. There is a proposal currently in Bugzilla which may improve things. Andrei
What's the bugzilla number?
http://d.puremagic.com/issues/show_bug.cgi?id=1827 I can't believe I actually found it. Just got lucky - I vaguely know it was submitted by someone in Poland. I never find anything with bugzilla... Andrei
Oct 30 2009
prev sibling next sibling parent Justin Johansson <no spam.com> writes:
Max Samukha Wrote:

 On Thu, 29 Oct 2009 13:30:35 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
It's me as well. The decision didn't go without a fight (I had your 
viewpoint and Walter didn't). He convinced me with two arguments. One is 
that 90% of the time you actually want T[], not T[n].
The argument may be flawed because, out of those 90% of arrays, only small part may be initialized from array literals. Many (most?) are created with new or appended. I suspect dynamic arrays created from literals are as rare as static arrays in real world code. Probably, I'll investigate how exactly rare.
Is this the same argument as Andrei's rhetorical question (in relation to proposed removal of D complex literals), "Name me five significant complex numbers" from a few weeks ago? (Sorry can't find the NG link just right now).
Oct 30 2009
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
 
 
 Andrei
p.28 line 16:
 symbols in less bits
should be
 symbols in fewer bits
Oct 31 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Mike Parker wrote:
 Andrei Alexandrescu wrote:
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
p.28 line 16: >>> symbols in less bits should be >>> symbols in fewer bits
Thanks, fixed. Andrei
Oct 31 2009
prev sibling next sibling parent reply duser4ever <no spam.com> writes:
Andrei Alexandrescu Wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
 
 
 Andrei
Sure I haven't come across anything that someone else hasn't already pointed out, but here it is any: P133 "Table 9.1 on page 301 summarizes dynamic array operations" should read "Table 3.4 on page 134 summarizes dynamic array operations" P118 something sounds wrong here also: "However, if a function returns T[n], that not automatically converted to T[]--it must be T[n]." maybe "it is not automatically" vice "that not automatically"? P117 this sentence does not sound natural to me; "This means that copying arrays, passing arrays into functions, and returning arrays from functions -- these all copy entire arrays." P111 change "in it" on line 8 to read "into it" P111 change "bailout" on line 21 to read "bail out" P110 change "responsible in making" to "responsible for making" Not clear what you are saying here: "The compiler is free to assume that when optimizing the operations into primitive vector operations offered by the host processor." What is it assuming? That I'm responsible? That the arrays do not overlap? P109 auto a = [1.0, 2.5, 3.6]; auto b = [4.5, 5.5, 1.4]; auto c = new double[3]; // changing to "auto c = (new double[3])[] = 0.0;" or adding the line "c[] = 0.0;" should do the trick c[] += 4 * a[] + b[]; will not work. Since c is of type double[3] it's initial value is set to [nan, nan, nan]; As a result any transaction performed on this array will result in the same if it is not first initialized. P102 eenlists should read enlists P101 change "comes just handy" to "comes in handy"
Oct 31 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
duser4ever wrote:
 Andrei Alexandrescu Wrote:
 
 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei
Sure I haven't come across anything that someone else hasn't already pointed out, but here it is any: P133 "Table 9.1 on page 301 summarizes dynamic array operations" should read "Table 3.4 on page 134 summarizes dynamic array operations"
Thanks, I'd forgotten to clean the intermediate files before building the entire book.
 P118 something sounds wrong here also:
      "However, if a function returns T[n], that not automatically
      converted to T[]--it must be T[n]."
      
      maybe "it is not automatically" vice "that not automatically"?
 
 P117 this sentence does not sound natural to me;
      "This means that copying arrays, passing arrays into functions, 
      and returning arrays from functions -- these all
      copy entire arrays."
 	
 P111 change "in it" on line 8 to read "into it" 
 
 P111 change "bailout" on line 21 to read "bail out" 
 
 P110 change "responsible in making" to "responsible for making"
 
      Not clear what you are saying here:
 	
      "The compiler is free to assume that when optimizing the operations into
primitive vector operations offered by the host processor."
 	
      What is it assuming? That I'm responsible? That the arrays do not overlap?
 
 P109
      auto a = [1.0, 2.5, 3.6];
      auto b = [4.5, 5.5, 1.4];
      auto c = new double[3]; // changing to "auto c = (new double[3])[] =
0.0;" or adding the line "c[] = 0.0;" should do the trick
      c[] += 4 * a[] + b[];
 	
      will not work. Since c is of type double[3] it's initial value is set to
[nan, nan, nan];
      As a result any transaction performed on this array will result in the
same if it is not first initialized.
 	
 P102 eenlists should read enlists
 
 P101 change "comes just handy" to "comes in handy"
Thanks! Quite a few of these are new. I've added this to my worklist, and as I see you give no email and no name, please email me privately your name so I can add it to acknowledgments. (I'll do so for everyone who sent me feedback.) Andrei
Oct 31 2009
prev sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Thu, Oct 29, 2009 at 05:38, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:

 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!
Well, if that's a rough rough draft, I'll happily read the entire book... I'm reading the AA part, and found that .dup doesn't exist for associative arrays (D2.036). It's bug 816, I guess. What's strange is that it's not listed as a bug in your text (red markings and such). Did you define a dup(K,V) function somewhere else? Philippe
Nov 11 2009