www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Errors in TDPL

reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Okay. I am in no way trying to say anything negative about TDPL. In fact, 
from what I've read so far, it's absolutely fantastic and quite possibly the 
most entertaining programming book that I've read in addition to being quite 
informative about D. However, no one's perfect (Andrei included), and there 
are bound to be errors in the book which didn't get caught.

My thought was that we could point out any errors that we've found so that 
Andrei can get them fixed in future printings and/or we can find out that 
they aren't actually errors.

The only errors that I've found so far have been omissions in the list of 
keywords on page 31. I'm listing them according to my understanding of 
whether they're still keywords, since I think that some have been removed as 
keywords or at least are no longer supposed to be keywords.

Definitely should be there
--------------------------
immutable
lazy
pure
nothrow
shared

I _think_ that it's supposed to be there
----------------------------------------
cent
ucent

I think that they might not supposed to be keywords anymore
-----------------------------------------------------------
cdouble
cfloat
creal
delete
idouble
ifloat
ireal
foreach_reverse

Everything under "definitely" appears to be used in TDPL as keywords but not 
listed as them. cent and ucent aren't listed, but as far as I know are still 
keywords (albeit not implemented yet). The ones that are missing which I 
think have been removed are still listed in the online docs' list of 
keywards but not in the book. IIRC, the c/i floating points got moved to 
phobos; according to TDPL, delete was deprecated (though I hadn't picked up 
on that); and I believe that foreach_reverse has been deprecated in favor of 
using the combination of foreach and retro. So, TDPL is missing at least 
some keywords in its list, and the online docs have too many.

In any case, I figured that it would be helpful if any errors in TDPL could 
be pointed out, since it could be helpful to Andrei and could be helpful to 
those reading it if the error isn't obvious. However, I certainly do _not_ 
want to in any way indicate displeasure with the book. It's quite good. It's 
just that it does appear to have some errors in it that snuck through.

- Jonathan M Davis
Jun 21 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

An online Errata Corrige will be very useful.

 and I believe that foreach_reverse has been deprecated in favor of 
 using the combination of foreach and retro.

How do you write this? foreach_reverse (i; 0 .. 10) Bye, bearophile
Jun 21 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:
 foreach(i; retro(iota(0, 10))) { }

Oh, right! Or even just: foreach (i; retro(iota(10))) {} But abstraction has a cost, see below. I have written three test programs. ---------------- // test1 import std.c.stdio: printf; void main() { enum int N = 100_000_000; int count; for (int i; i < N; i++) count++; printf("%d\n", count); } Asm of the inner code of the test1, opt version: 5: inc ECX inc EAX cmp EAX,05F5E100h jb L5 ---------------- // test2 import std.c.stdio: printf; void main() { enum int N = 100_000_000; int count; foreach_reverse (i; 0 .. N) count++; printf("%d\n", count); } Asm of the inner code of the test2, opt version: LF: dec ECX inc EDX mov EAX,ECX inc EAX jg LF ---------------- // test3 import std.c.stdio: printf; import std.range: iota, retro; void main() { enum int N = 100_000_000; int count; foreach (i; retro(iota(N))) count++; printf("%d\n", count); } Asm of the inner code of the test3, opt version: L6A: inc EBX lea EAX,010h[ESP] call near ptr _D3std5range145__T4TakeTS3std5range112__T8SequenceVAyaa27_612e6669656c645b305d202b206e202a20612eD0677AACB4B6BC826B92E7DBB9E1E359 cmp dword ptr 020h[ESP],0 jne L6A _D3std5range145__T4TakeTS3std5range112__T8SequenceVAyaa27_612e6669656c645b305d202b206e202a20612eD0677AACB4B6BC826B92E7DBB9E1E359 comdat L0: sub ESP,01Ch mov ECX,offset FLAT:_D3std5range145__T4TakeTS3std5range112__T8SequenceVAyaa27_612e6669656c645b305d202b206e202a20612e0B5C6D6E0C89B8D48DF56A414048DB6F push EBX push ESI mov ESI,EAX mov EDX,010h[ESI] mov 0Ch[ESP],EAX neg EDX sbb EDX,EDX neg EDX xor DL,1 mov 010h[ESP],ECX je L46 mov EDX,ECX push dword ptr FLAT:_DATA[064h] push dword ptr FLAT:_DATA[060h] push 051Fh mov EAX,018h[ESP] mov EBX,018h[ESP] call EDX push EDX push EAX call near ptr _D3std9contracts7bailOutFAyaixAaZv L46: dec dword ptr 010h[ESI] pop ESI pop EBX add ESP,01Ch ret _D3std9contracts7bailOutFAyaixAaZv is extern. ------------------ Running time, best of 3, seconds: test1: 0.31 test1 opt: 0.07 test2: 0.31 test2 opt: 0.12 test3: 6.38 test3 opt: 0.52 not opt version = dmd (no other option) opt version = dmd -O -release -inline Compile times opt version, seconds: test1: 0.05 test2: 0.05 test3: 0.28 So with the current dmd compiler in the inner loop in a performance-critical routine you can't use foreach(retro(iota(N))). In future a D compiler can recognize and optimize such usage of foreach(iota()) and foreach(retro(iota())) as ShedSkin does with usage of xrange()/range() in a loop. Bye, bearophile
Jun 21 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/21/2010 04:06 PM, bearophile wrote:
 Adam Ruppe:
 foreach(i; retro(iota(0, 10))) { }

Oh, right! Or even just: foreach (i; retro(iota(10))) {} But abstraction has a cost, see below. I have written three test programs.

Nice work. iota() currently uses the formula initial + i * step to compute the ith element. This is to make sure that iota works properly with floating point numbers as well as integers. We should specialize iota for integrals to use increment, which should count for some efficiency gains (currently the optimizer cannot figure out the equivalence, so it generates the multiply and add in the loop). If efficiency is still sub-par, retro could detect that it's working with iota and generate specialized code. That's not too difficult; for integers, retro(iota(a, b)) could actually be a rewrite to iota(b - 1, a, -1). Figuring out all corner cases, steps greater than 1, and what to do for floating point numbers is doable but not trivial either, and works against modularity. Anyway, it does look like it's all about an implementation matter. Andrei
Jun 21 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/21/2010 06:35 PM, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 21 de junio a las 17:43 me escribiste:
 If efficiency is still sub-par, retro could detect that it's working
 with iota and generate specialized code. That's not too difficult;
 for integers, retro(iota(a, b)) could actually be a rewrite to
 iota(b - 1, a, -1). Figuring out all corner cases, steps greater
 than 1, and what to do for floating point numbers is doable but not
 trivial either, and works against modularity. Anyway, it does look
 like it's all about an implementation matter.

I'm scared, I've heard that in C++ so many times... =)

Particularly in conjunction with iostreams. Their slow speed has been an implementation issue for, what, 26 years and still going strong. :o) Fortunately, in the case of iota, it's pretty clear what needs to be done. Andrei
Jun 21 2010
prev sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
On 22/06/10 00:35, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 21 de junio a las 17:43 me escribiste:
 If efficiency is still sub-par, retro could detect that it's working
 with iota and generate specialized code. That's not too difficult;
 for integers, retro(iota(a, b)) could actually be a rewrite to
 iota(b - 1, a, -1). Figuring out all corner cases, steps greater
 than 1, and what to do for floating point numbers is doable but not
 trivial either, and works against modularity. Anyway, it does look
 like it's all about an implementation matter.

I'm scared, I've heard that in C++ so many times... =)

Writing an efficient library is a complex task. No language will ever change that. The beauty of D is that this complexity can be hidden from the user (unlike in C++ where error messages become increasingly ugly).
Jun 23 2010
prev sibling next sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 21/06/2010 20:09, Jonathan M Davis wrote:
 Okay. I am in no way trying to say anything negative about TDPL. In fact,
 from what I've read so far, it's absolutely fantastic and quite possibly the
 most entertaining programming book that I've read in addition to being quite
 informative about D. However, no one's perfect (Andrei included), and there
 are bound to be errors in the book which didn't get caught.

 My thought was that we could point out any errors that we've found so that
 Andrei can get them fixed in future printings and/or we can find out that
 they aren't actually errors.

 The only errors that I've found so far have been omissions in the list of
 keywords on page 31. I'm listing them according to my understanding of
 whether they're still keywords, since I think that some have been removed as
 keywords or at least are no longer supposed to be keywords.

 Definitely should be there
 --------------------------
 immutable
 lazy
 pure
 nothrow
 shared

 I _think_ that it's supposed to be there
 ----------------------------------------
 cent
 ucent

 I think that they might not supposed to be keywords anymore
 -----------------------------------------------------------
 cdouble
 cfloat
 creal
 delete
 idouble
 ifloat
 ireal
 foreach_reverse

 Everything under "definitely" appears to be used in TDPL as keywords but not
 listed as them. cent and ucent aren't listed, but as far as I know are still
 keywords (albeit not implemented yet). The ones that are missing which I
 think have been removed are still listed in the online docs' list of
 keywards but not in the book. IIRC, the c/i floating points got moved to
 phobos; according to TDPL, delete was deprecated (though I hadn't picked up
 on that); and I believe that foreach_reverse has been deprecated in favor of
 using the combination of foreach and retro. So, TDPL is missing at least
 some keywords in its list, and the online docs have too many.

 In any case, I figured that it would be helpful if any errors in TDPL could
 be pointed out, since it could be helpful to Andrei and could be helpful to
 those reading it if the error isn't obvious. However, I certainly do _not_
 want to in any way indicate displeasure with the book. It's quite good. It's
 just that it does appear to have some errors in it that snuck through.

 - Jonathan M Davis

Good Idea! I must admit I skipped over that table, didn't look overly interesting as tables go (><) but good catch! There is only one mention of lazy evaluation in the index and it doesn't mention the lazy k/w at all. I seem to remember Andrei dislikes it, but also that there is another way to get function params to be evaluated lazily without using it. immutable, nothrow, pure and shared are definitely oversights though. I've not spotted anything D-specific myself yet, I'm not a particularly speedy reader ^^ A...
Jun 21 2010
next sibling parent reply =?iso-8859-2?B?VG9tZWsgU293afFza2k=?= <just ask.me> writes:
Dnia 21-06-2010 o 21:57:49 Alix Pexton <alix.DOT.pexton gmail.dot.com>  =

napisa=B3(a):

 There is only one mention of lazy evaluation in the index and it doesn=

 mention the lazy k/w at all. I seem to remember Andrei dislikes it, bu=

 also that there is another way to get function params to be evaluated =

 lazily without using it.

Yeah, speaking of which - what happened to that proposal*? *The proposal AFAIR was (correct me if wrong): if a function has a = parameterless delegate as a parameter, then on the call site any = expression in the delegate slot is implicitly turned into a delegate. I = = think the delegate ought to be pure to make the magic happen. Yeah, speaking of which - do/will we have pure delegates? Tomek
Jun 21 2010
next sibling parent BCS <none anon.com> writes:
Hello Tomek,

 I think the delegate ought to be pure to make the magic happen.
 

That would be a god idea if the feature were strictly for lazy (no cost unless you need it) evaluation but there are other use that need to be able to cause side effects. -- ... <IXOYE><
Jun 21 2010
prev sibling parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 21/06/2010 21:51, Tomek SowiŮski wrote:
 Dnia 21-06-2010 o 21:57:49 Alix Pexton <alix.DOT.pexton gmail.dot.com>
 napisa≥(a):

 There is only one mention of lazy evaluation in the index and it
 doesn't mention the lazy k/w at all. I seem to remember Andrei
 dislikes it, but also that there is another way to get function params
 to be evaluated lazily without using it.

Yeah, speaking of which - what happened to that proposal*? *The proposal AFAIR was (correct me if wrong): if a function has a parameterless delegate as a parameter, then on the call site any expression in the delegate slot is implicitly turned into a delegate. I think the delegate ought to be pure to make the magic happen. Yeah, speaking of which - do/will we have pure delegates? Tomek

This is the "trick" I was refering to, from a post by the programmer formerly known as downs... Amusing D facts: typesafe variadic arrays are lazy!
 Did you know the following code compiles?

 module test;

 import std.stdio;

 void Assert(bool cond, string delegate()[] dgs...) {
   debug if (!cond) {
     string str;
     foreach (dg; dgs) str ~= dg();
     throw new Exception(str);
   }
 }

 void main() {
   Assert(false, "O hai thar! ");
 }


It's true! :)

A...
Jun 22 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/21/2010 02:57 PM, Alix Pexton wrote:
 There is only one mention of lazy evaluation in the index and it doesn't
 mention the lazy k/w at all. I seem to remember Andrei dislikes it, but
 also that there is another way to get function params to be evaluated
 lazily without using it.

lazy is quite, no, _very_ ill-defined. Walter and I decided to not mention it in the book and leave room for either a better definition of lazy or a feature that obviates it. Andrei
Jun 21 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 6/21/10, bearophile <bearophileHUGS lycos.com> wrote:
 How do you write this?
 foreach_reverse (i; 0 .. 10)

foreach(i; retro(iota(0, 10))) { } ?
Jun 21 2010
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
I was biting my tongue on the subject, but on page 73 the grammar for 
the do while loop has a semicolon at the end. AAHHHHHHHHHHHHH!!!!!!!! 
THERE IS NOOOOOOO SEMICOLON AT THE END.

Wow. Sorry. This is a pet peeve of mine.
Jun 21 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/21/2010 03:32 PM, Ellery Newcomer wrote:
 I was biting my tongue on the subject, but on page 73 the grammar for
 the do while loop has a semicolon at the end. AAHHHHHHHHHHHHH!!!!!!!!
 THERE IS NOOOOOOO SEMICOLON AT THE END.

 Wow. Sorry. This is a pet peeve of mine.

Can't help that, sorry... Andrei
Jun 21 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Andrei Alexandrescu wrote:

 On 06/21/2010 03:32 PM, Ellery Newcomer wrote:
 I was biting my tongue on the subject, but on page 73 the grammar for
 the do while loop has a semicolon at the end. AAHHHHHHHHHHHHH!!!!!!!!
 THERE IS NOOOOOOO SEMICOLON AT THE END.

 Wow. Sorry. This is a pet peeve of mine.

Can't help that, sorry... Andrei

Well, while I, personally, would put a semicolon there (it feels naked to me without one), dmd doesn't actually seem to require it. But TDPL says that the semicolon is required. So, it does appear to be an error in the text. Of course, there's no helping his pet peeve regardless, but the semicolon doesn't appear to be required. - Jonathan M Davis
Jun 22 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/22/2010 04:14 PM, Jonathan M Davis wrote:
 Andrei Alexandrescu wrote:

 On 06/21/2010 03:32 PM, Ellery Newcomer wrote:
 I was biting my tongue on the subject, but on page 73 the grammar for
 the do while loop has a semicolon at the end. AAHHHHHHHHHHHHH!!!!!!!!
 THERE IS NOOOOOOO SEMICOLON AT THE END.

 Wow. Sorry. This is a pet peeve of mine.

Can't help that, sorry... Andrei

Well, while I, personally, would put a semicolon there (it feels naked to me without one), dmd doesn't actually seem to require it. But TDPL says that the semicolon is required. So, it does appear to be an error in the text. Of course, there's no helping his pet peeve regardless, but the semicolon doesn't appear to be required. - Jonathan M Davis

Walter, was that intentional? The grammar has no semicolon but the example does. That makes the example wrong because you agreed there is no solitary semicolon statement in D, and TDPL does mention that. IMHO the semicolon makes for more robust code. Consider: do { ... lotsa code ... } while (fun(i)) ++i; A maintainer might see the while and conclude that ++i; was meant to be the loop, indent it, and call it a day. The absence of the semicolon thus created a contextual dependency on the presence of the "do" keyword upstream. Walter, can we require a semicolon please? Andrei
Jun 22 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
you agreed there is no solitary semicolon statement in D,<

This compiles, is this a solitary semicolon statement? void main() { goto FOO; FOO:; }
 Walter, can we require a semicolon please?

+1 Bye, bearophile
Jun 22 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/22/2010 04:53 PM, bearophile wrote:
 Andrei Alexandrescu:
 you agreed there is no solitary semicolon statement in D,<

This compiles, is this a solitary semicolon statement? void main() { goto FOO; FOO:; }

Yes. It shouldn't compile. Walter and I agreed that solitary semicolons are useless (you can always use {} as an empty statement and that actually makes things clearer to everyone), but it's a low-priority issue so he hasn't implemented that yet. Andrei
Jun 22 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:
 void main() {
      goto FOO;
      FOO:;
 }

Yes. It shouldn't compile. Walter and I agreed that solitary semicolons are useless (you can always use {} as an empty statement and that actually makes things clearer to everyone),

I have had to use a LABEL:; in D code, to implement a finite state machine. So I guess I'll have to write it like this: LABEL: {} Bye, bearophile
Jun 22 2010
parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Andrei:
 void main() {
      goto FOO;
      FOO:;
 }

are useless (you can always use {} as an empty statement and that actually makes things clearer to everyone),

I have had to use a LABEL:; in D code, to implement a finite state machine. So I guess I'll have to write it like this: LABEL: {} Bye, bearophile

I think the ; is part of the label statement. If not, it should be removed entirely.
Jun 23 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/23/2010 04:56 AM, Don wrote:
 bearophile wrote:
 Andrei:
 void main() {
 goto FOO;
 FOO:;
 }

semicolons are useless (you can always use {} as an empty statement and that actually makes things clearer to everyone),

I have had to use a LABEL:; in D code, to implement a finite state machine. So I guess I'll have to write it like this: LABEL: {} Bye, bearophile

I think the ; is part of the label statement. If not, it should be removed entirely.

Fortunately there's no label statement. A label is a distinct entity and may precede any statement. Andrei
Jun 23 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Andrei Alexandrescu wrote:

 
 Walter, was that intentional? The grammar has no semicolon but the
 example does. That makes the example wrong because you agreed there is
 no solitary semicolon statement in D, and TDPL does mention that.
 
 IMHO the semicolon makes for more robust code. Consider:
 
 do
 {
      ... lotsa code ...
 }
 while (fun(i))
 ++i;
 
 A maintainer might see the while and conclude that ++i; was meant to be
 the loop, indent it, and call it a day. The absence of the semicolon
 thus created a contextual dependency on the presence of the "do" keyword
 upstream.
 
 Walter, can we require a semicolon please?
 
 
 Andrei

I have zero problem requiring a semicolon (I'd prefer it actually), but I believe that a lone semicolon is generally a perfectly valid statement in D as long as it's not where optional braces could be. Per the grammar: Statement: ; NonEmptyStatement ScopeBlockStatement I believe that all the constructs with optional braces have a ScopBlockStatement for their body and therefore can't have a lone semicolon. But a statement by itself can be a lone semicolon. Though why you'd do that, I don't know. The only place that I've run into that being useful has been with macros (which don't exist in D). - Jonathan M Davis
Jun 22 2010
prev sibling next sibling parent reply Rick Trelles <RTrelles bellsouth.net> writes:
Saving a keystroke, if it is in sound and clear way, is a plus.
At least the option to save the keystroke should be maintained.

I don't see now any advantages in using a pair of braces over a single 
semicolon for a null statement, but why not keep it both ways?

I never liked the semicolon after while() but surely it wouldn't hurt to 
interpret it as a null statement for those who are used to it.

By the way, I always glue the closing bracket to while

do{

. . .

}while( . . . )  // plus ";" if coding in C


Rick Trelles
Jun 23 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/23/2010 02:11 AM, Rick Trelles wrote:
 Saving a keystroke, if it is in sound and clear way, is a plus.
 At least the option to save the keystroke should be maintained.

 I don't see now any advantages in using a pair of braces over a single
 semicolon for a null statement, but why not keep it both ways?

We've all seen that requiring "{}" after the likes of if, while etc. are very beneficial for readability. Then why not generalize that? As far as I can tell the only vestigial use of the lone ";" is with labels that don't precede any instruction (a very rare case). At this point, ";" needs more justification to stay than to go.
 I never liked the semicolon after while() but surely it wouldn't hurt to
 interpret it as a null statement for those who are used to it.

 By the way, I always glue the closing bracket to while

 do{

 . . .

 }while( . . . ) // plus ";" if coding in C


 Rick Trelles

That's great, except for those who enjoy "brace on its own line" formatting style. For those, the "}while" would look jarring. Andrei
Jun 23 2010
parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 23/06/2010 16:24, Andrei Alexandrescu wrote:
 On 06/23/2010 02:11 AM, Rick Trelles wrote:
 Saving a keystroke, if it is in sound and clear way, is a plus.
 At least the option to save the keystroke should be maintained.

 I don't see now any advantages in using a pair of braces over a single
 semicolon for a null statement, but why not keep it both ways?

We've all seen that requiring "{}" after the likes of if, while etc. are very beneficial for readability. Then why not generalize that? As far as I can tell the only vestigial use of the lone ";" is with labels that don't precede any instruction (a very rare case). At this point, ";" needs more justification to stay than to go.
 I never liked the semicolon after while() but surely it wouldn't hurt to
 interpret it as a null statement for those who are used to it.

 By the way, I always glue the closing bracket to while

 do{

 . . .

 }while( . . . ) // plus ";" if coding in C


 Rick Trelles

That's great, except for those who enjoy "brace on its own line" formatting style. For those, the "}while" would look jarring. Andrei

I find that the "}while(..." style is the best way to highlight that you are looking a a do...while and not a regular while loop, that it is jarring is exactly the point ^^ Making the the semicolon on the end a requirement helps if you are familiar with D and know it is not allowed on a regular while, but the less enlightened might see a classic bug pattern where there isn't one and try to "maintain" it away >< In some ways I think it was a mistake in to reuse while in the first place, but that was a decision that was made a loong time before D... A...
Jun 23 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Alix Pexton:
 In some ways I think it was a mistake in to reuse while in the first 
 place, but that was a decision that was made a loong time before D...

Pascal-like languages use repeat-until, but I prefer the C do-while because the condition in repeat-until is the opposite of the one you use in a while loop, and every time I use repeat-until I have to remember what's the correct stopping condition to write. Bye, bearophile
Jun 23 2010
parent reply eles <eles eles.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Alix Pexton:
 In some ways I think it was a mistake in to reuse while in the


 place, but that was a decision that was made a loong time before


 Pascal-like languages use repeat-until, but I prefer the C do-while

use in a while loop, and every time I use repeat-until I have to remember what's the correct stopping condition to write. Quite the oposite here. When I have a loop like that, I think rather about the exit condition (so in terms of "repeat/until"). This is why I often write: do{ //code } while(!([exit_condition_here])); I also think re-using while() in the do ... while loop is a mistake, exactly because of difficulties arising in code maintenance. I would like to have another keyword for that, or maybe the "repeat/ until" loop all-together. It is a shame that compatibility issues prevail over quality and improvement. Ditching the do...while loop could be unacceptable now, but why do not propose a better alternative mechanism? That way, we would have both compatibility and quality. eles
 Bye,
 bearophile

Jun 23 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
eles wrote:

 It is a shame that compatibility issues prevail over quality and
 improvement. Ditching the do...while loop could be unacceptable now,
 but why do not propose a better alternative mechanism? That way, we
 would have both compatibility and quality.
 
 eles

Quality prevails over compatibility when the quality gain is deemed to exceed the problems incurred by losing compatibility. In this case, do-while works just fine. Lots of people are used to using it and have never even heard of repeat-until, having never used Pascal or any other language that used it. At this point, C's influence far outweights Pascal's. Also, AFAIK, do-while is not generally a major source of bugs. As such, while another construct might be better, since the current one isn't much of a problem, it's not worth breaking compatibility. If it were shown that do- while was a big problem, then it might be. But at this point, do-while works just fine, so it's not worth changing it. - Jonathan M Davis
Jun 23 2010
parent eles <eles eles.com> writes:
 I did not try to start a polemic, but to give something to think about. There
are more opinions on the matter and, as you may see, mine differs of yours. Is
not a tragedy.

 However, I think one should be more aware when supporting habit per se.

 Maybe adding "until" as an aliasing for "while not" would you seem more
acceptable? Or, at least, accepting "do{/* code */}aslongas(/*condition*/);" as
an alternative "do{/* code */}while(/*condition*/);" would be less disruptive?

 That way, people could use "do/while", but this will open the door for "do/
aslongas", if this is considered suitable. This will also avoid ambiguous cases
like pointed out in this thread (i.e. the danger of interpreting "while(/
*condition*/;i++" as a ";" bug). This will break no compatibility.

 Robustness of relying solely on the code indentation ("}while();" instead of
"while();") is not persuasive for me. Why dismissing an opportunity to avoid a
potential bug?

eles


== Quote from Jonathan M Davis (jmdavisProg gmail.com)'s article
 Quality prevails over compatibility when the quality gain is deemed to
 exceed the problems incurred by losing compatibility.
 In this case, do-while works just fine. Lots of people are used to using it
 and have never even heard of repeat-until, having never used Pascal or any
 other language that used it. At this point, C's influence far outweights
 Pascal's.
 Also, AFAIK, do-while is not generally a major source of bugs. As such,
 while another construct might be better, since the current one isn't much of
 a problem, it's not worth breaking compatibility. If it were shown that do-
 while was a big problem, then it might be. But at this point, do-while works
 just fine, so it's not worth changing it.
 - Jonathan M Davis

Jun 24 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/23/2010 05:44 PM, Alix Pexton wrote:
 On 23/06/2010 16:24, Andrei Alexandrescu wrote:
 On 06/23/2010 02:11 AM, Rick Trelles wrote:
 Saving a keystroke, if it is in sound and clear way, is a plus.
 At least the option to save the keystroke should be maintained.

 I don't see now any advantages in using a pair of braces over a single
 semicolon for a null statement, but why not keep it both ways?

We've all seen that requiring "{}" after the likes of if, while etc. are very beneficial for readability. Then why not generalize that? As far as I can tell the only vestigial use of the lone ";" is with labels that don't precede any instruction (a very rare case). At this point, ";" needs more justification to stay than to go.
 I never liked the semicolon after while() but surely it wouldn't hurt to
 interpret it as a null statement for those who are used to it.

 By the way, I always glue the closing bracket to while

 do{

 . . .

 }while( . . . ) // plus ";" if coding in C


 Rick Trelles

That's great, except for those who enjoy "brace on its own line" formatting style. For those, the "}while" would look jarring. Andrei

I find that the "}while(..." style is the best way to highlight that you are looking a a do...while and not a regular while loop, that it is jarring is exactly the point ^^ Making the the semicolon on the end a requirement helps if you are familiar with D and know it is not allowed on a regular while, but the less enlightened might see a classic bug pattern where there isn't one and try to "maintain" it away >< In some ways I think it was a mistake in to reuse while in the first place, but that was a decision that was made a loong time before D... A...

Walter agreed to fix do-while to require a semicolon. Andrei
Jun 23 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Walter agreed to fix do-while to require a semicolon.

Good. This was the relative bug: http://d.puremagic.com/issues/show_bug.cgi?id=4374 Bye, bearophile
Jun 23 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Rory McGuire wrote:

 On Tue, 22 Jun 2010 23:37:59 +0200, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Walter, can we require a semicolon please?

With the semi colon missing its as bad as: for (;i<100;i++); writeln(i); esp. with large amount of code
 Andrei

Rory

It's not that bad. for(; i < 100; ++i); writeln(i); would be a bug (if it were legal) because you'd expect the writeln() to be part of the loop when it isn't. The loop wouldn't be run like you'd expect it to, and it's hard to catch. do { ... } while(test) does not have that problem. The problem you run into is this: do { ... } while(test) { ... } If you're _really_ not paying attention, you'd think that the second set of braces started a while loop. But since you'd have to have way more spacing than makes sense for it to happen, it becomes way more obvious and is not the same level of problem. However, I do think that it _is_ a problem, and the above example could definitely be confusing if you're just quickly scanning over code. I don't see any real reason to allow the lack of semicolon, and I do think that it's a problem, but I don't think that it's a problem on the same level as allowing a semicolon to be used as an empty body for an if statement or loop. - Jonathan M Davis
Jun 23 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 Well, while I, personally, would put a semicolon there (it feels naked to me 
 without one), dmd doesn't actually seem to require it. But TDPL says that 
 the semicolon is required. So, it does appear to be an error in the text. Of 
 course, there's no helping his pet peeve regardless, but the semicolon 
 doesn't appear to be required.

For reference for this discussion, the current grammar does not require it: http://www.digitalmars.com/d/2.0/statement.html#DoStatement The C grammar does require it: do statement while ( expression ) ;
Jun 23 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/23/2010 11:40 AM, Walter Bright wrote:
 Jonathan M Davis wrote:
 Well, while I, personally, would put a semicolon there (it feels naked
 to me without one), dmd doesn't actually seem to require it. But TDPL
 says that the semicolon is required. So, it does appear to be an error
 in the text. Of course, there's no helping his pet peeve regardless,
 but the semicolon doesn't appear to be required.

For reference for this discussion, the current grammar does not require it: http://www.digitalmars.com/d/2.0/statement.html#DoStatement The C grammar does require it: do statement while ( expression ) ;

I mistakingly assumed D followed C in that regard. Given the argument stated in this thread (that absent semicolons require more context to be absorbed while reading), do you agree that D should make the semicolon required? Andrei
Jun 23 2010
parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 23/06/2010 17:51, Andrei Alexandrescu wrote:
 On 06/23/2010 11:40 AM, Walter Bright wrote:
 Jonathan M Davis wrote:
 Well, while I, personally, would put a semicolon there (it feels naked
 to me without one), dmd doesn't actually seem to require it. But TDPL
 says that the semicolon is required. So, it does appear to be an error
 in the text. Of course, there's no helping his pet peeve regardless,
 but the semicolon doesn't appear to be required.

For reference for this discussion, the current grammar does not require it: http://www.digitalmars.com/d/2.0/statement.html#DoStatement The C grammar does require it: do statement while ( expression ) ;

I mistakingly assumed D followed C in that regard. Given the argument stated in this thread (that absent semicolons require more context to be absorbed while reading), do you agree that D should make the semicolon required? Andrei

++vote A...
Jun 23 2010
prev sibling next sibling parent "Rory McGuire" <rmcguire neonova.co.za> writes:
On Tue, 22 Jun 2010 23:37:59 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Walter, can we require a semicolon please?

With the semi colon missing its as bad as: for (;i<100;i++); writeln(i); esp. with large amount of code
 Andrei

Rory
Jun 23 2010
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 23 Jun 2010 11:56:12 +0200, Don wrote:

 bearophile wrote:
 Andrei:
 void main() {
      goto FOO;
      FOO:;
 }

semicolons are useless (you can always use {} as an empty statement and that actually makes things clearer to everyone),

I have had to use a LABEL:; in D code, to implement a finite state machine. So I guess I'll have to write it like this: LABEL: {} Bye, bearophile

I think the ; is part of the label statement. If not, it should be removed entirely.

This does not compile: void main() { goto Lfoo; Lfoo: } test.d(5): found '}' instead of statement It seems to me like it should be valid code, but I'm not sure it's worth making it a special case. -Lars
Jun 23 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 I mistakingly assumed D followed C in that regard. Given the argument  
 stated in this thread (that absent semicolons require more context to be  
 absorbed while reading), do you agree that D should make the semicolon  
 required?

Yes -- Simen
Jun 24 2010
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 23 Jun 2010 11:51:40 -0500, Andrei Alexandrescu wrote:

 On 06/23/2010 11:40 AM, Walter Bright wrote:
 Jonathan M Davis wrote:
 Well, while I, personally, would put a semicolon there (it feels naked
 to me without one), dmd doesn't actually seem to require it. But TDPL
 says that the semicolon is required. So, it does appear to be an error
 in the text. Of course, there's no helping his pet peeve regardless,
 but the semicolon doesn't appear to be required.

For reference for this discussion, the current grammar does not require it: http://www.digitalmars.com/d/2.0/statement.html#DoStatement The C grammar does require it: do statement while ( expression ) ;

I mistakingly assumed D followed C in that regard. Given the argument stated in this thread (that absent semicolons require more context to be absorbed while reading), do you agree that D should make the semicolon required?

Absolutely. -Lars
Jun 24 2010
prev sibling next sibling parent reply Spacen Jasset <spacenjasset yahoo.co.uk> writes:
I am only on page ten, I believe I saw a minor typo somewhere in the 
preface, that's all so far. I look forward to pondering the rest in the 
coming days.

oh yes.

Preface
"D is a language that attempts to consistently do the right thing within 
the constraints it choose: sys...." etc

missing s, I gues.
Jun 21 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/21/2010 05:35 PM, Spacen Jasset wrote:
 I am only on page ten, I believe I saw a minor typo somewhere in the
 preface, that's all so far. I look forward to pondering the rest in the
 coming days.

 oh yes.

 Preface
 "D is a language that attempts to consistently do the right thing within
 the constraints it choose: sys...." etc

 missing s, I gues.

Thanks for your note. The current text uses "chose", i.e. the past tense of "to choose", so I think it is correct. Andrei
Jun 21 2010
parent Spacen Jasset <spacenjasset yahoo.co.uk> writes:
Andrei Alexandrescu wrote:
 On 06/21/2010 05:35 PM, Spacen Jasset wrote:
 I am only on page ten, I believe I saw a minor typo somewhere in the
 preface, that's all so far. I look forward to pondering the rest in the
 coming days.

 oh yes.

 Preface
 "D is a language that attempts to consistently do the right thing within
 the constraints it choose: sys...." etc

 missing s, I gues.

Thanks for your note. The current text uses "chose", i.e. the past tense of "to choose", so I think it is correct. Andrei

Jun 21 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/21/2010 02:09 PM, Jonathan M Davis wrote:
 Okay. I am in no way trying to say anything negative about TDPL.

You are being too kind about this :o). Of course we need an errata list. I was hoping I'd need to set it up later, but hey, that's a sign people actually are reading the book and care about keeping everything in check. I started an errata list in form of a community wiki at http://www.erdani.com/tdpl/errata and primed the errata with your report. Thanks very much! I'll see to it that future printings fix the issues in the errata list. Andrei
Jun 21 2010
next sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Andrei Alexandrescu wrote:

 On 06/21/2010 02:09 PM, Jonathan M Davis wrote:
 Okay. I am in no way trying to say anything negative about TDPL.

You are being too kind about this :o).

Well, I didn't want to post on the main D list and come across as saying that the new book is full of errors and sucks. wIt really is quite an entertaining read (for a programming book anyway) with talk of jumping through rings of syntactic fire, describing casts as well-intended genies, and plenty of other humourous descriptions. And, of course, it's quite instructive along the way. Now if I can only get my co-workers to read it... - Jonathan M Davis
Jun 21 2010
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
On 22.06.2010 00:39, Andrei Alexandrescu wrote:
 I started an errata list in form of a community wiki at

 http://www.erdani.com/tdpl/errata

For those of us who have still only got the pdf version, is that the same text as the printed one? Should we report errors in the pdf version, or wait until we get the printed edition?
Jun 21 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/21/2010 06:30 PM, torhu wrote:
 On 22.06.2010 00:39, Andrei Alexandrescu wrote:
 I started an errata list in form of a community wiki at

 http://www.erdani.com/tdpl/errata

For those of us who have still only got the pdf version, is that the same text as the printed one? Should we report errors in the pdf version, or wait until we get the printed edition?

The PDF on Rough Cuts is identical to the printed book. Please report straight in the errata. Andrei
Jun 21 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
On page 82 of TDPL, it's talking about try/catch/finally statements, and it 
says that "all controlled statement must be block statements; that is they 
must be enclosed with braces." However, dmd does not seem to require that 
try/catch/finally blocks have braces, which is what I would expect that 
sentence to mean. C++ has that restriction for reasons that I don't 
understand, but as far as I can tell, D does not - certainly dmd doesn't 
appear to require it. Is the statement correct but refers to something else, 
or is it in error?

- Jonathan M Davis
Jun 21 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/21/2010 08:47 PM, Jonathan M Davis wrote:
 On page 82 of TDPL, it's talking about try/catch/finally statements, and it
 says that "all controlled statement must be block statements; that is they
 must be enclosed with braces." However, dmd does not seem to require that
 try/catch/finally blocks have braces, which is what I would expect that
 sentence to mean. C++ has that restriction for reasons that I don't
 understand, but as far as I can tell, D does not - certainly dmd doesn't
 appear to require it. Is the statement correct but refers to something else,
 or is it in error?

 - Jonathan M Davis

That's a surprise to me. Walter, is that intentional? Andrei
Jun 21 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 On 06/21/2010 08:47 PM, Jonathan M Davis wrote:
 On page 82 of TDPL, it's talking about try/catch/finally statements, 
 and it
 says that "all controlled statement must be block statements; that is 
 they
 must be enclosed with braces." However, dmd does not seem to require that
 try/catch/finally blocks have braces, which is what I would expect that
 sentence to mean. C++ has that restriction for reasons that I don't
 understand, but as far as I can tell, D does not - certainly dmd doesn't
 appear to require it. Is the statement correct but refers to something 
 else,
 or is it in error?

 - Jonathan M Davis

That's a surprise to me. Walter, is that intentional?

They do not require braces, they just require that the controlling statement not be a single ;. In the grammar, this is a ScopeStatement, which is a NonEmptyStatement or a BlockStatement. http://www.digitalmars.com/d/2.0/statement.html#ScopeStatement
Jun 22 2010
parent reply biozic <dransic free.fr> writes:
Le 22/06/10 10:54, Walter Bright a écrit :
 Andrei Alexandrescu wrote:
 On 06/21/2010 08:47 PM, Jonathan M Davis wrote:
 On page 82 of TDPL, it's talking about try/catch/finally statements,
 and it
 says that "all controlled statement must be block statements; that is
 they
 must be enclosed with braces." However, dmd does not seem to require
 that
 try/catch/finally blocks have braces, which is what I would expect that
 sentence to mean. C++ has that restriction for reasons that I don't
 understand, but as far as I can tell, D does not - certainly dmd doesn't
 appear to require it. Is the statement correct but refers to
 something else,
 or is it in error?

 - Jonathan M Davis

That's a surprise to me. Walter, is that intentional?

They do not require braces, they just require that the controlling statement not be a single ;. In the grammar, this is a ScopeStatement, which is a NonEmptyStatement or a BlockStatement. http://www.digitalmars.com/d/2.0/statement.html#ScopeStatement

Not always: http://d.puremagic.com/issues/show_bug.cgi?id=4024
Jun 22 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
biozic wrote:
 Le 22/06/10 10:54, Walter Bright a écrit :
 Andrei Alexandrescu wrote:
 On 06/21/2010 08:47 PM, Jonathan M Davis wrote:
 On page 82 of TDPL, it's talking about try/catch/finally statements,
 and it
 says that "all controlled statement must be block statements; that is
 they
 must be enclosed with braces." However, dmd does not seem to require
 that
 try/catch/finally blocks have braces, which is what I would expect that
 sentence to mean. C++ has that restriction for reasons that I don't
 understand, but as far as I can tell, D does not - certainly dmd 
 doesn't
 appear to require it. Is the statement correct but refers to
 something else,
 or is it in error?

 - Jonathan M Davis

That's a surprise to me. Walter, is that intentional?

They do not require braces, they just require that the controlling statement not be a single ;. In the grammar, this is a ScopeStatement, which is a NonEmptyStatement or a BlockStatement. http://www.digitalmars.com/d/2.0/statement.html#ScopeStatement

Not always: http://d.puremagic.com/issues/show_bug.cgi?id=4024

Bugs in the compiler aren't errors in TDPL!
Jun 22 2010
parent biozic <dransic free.fr> writes:
Le 22/06/10 15:53, Walter Bright a écrit :
 biozic wrote:
 Le 22/06/10 10:54, Walter Bright a écrit :
 Andrei Alexandrescu wrote:
 On 06/21/2010 08:47 PM, Jonathan M Davis wrote:
 On page 82 of TDPL, it's talking about try/catch/finally statements,
 and it
 says that "all controlled statement must be block statements; that is
 they
 must be enclosed with braces." However, dmd does not seem to require
 that
 try/catch/finally blocks have braces, which is what I would expect
 that
 sentence to mean. C++ has that restriction for reasons that I don't
 understand, but as far as I can tell, D does not - certainly dmd
 doesn't
 appear to require it. Is the statement correct but refers to
 something else,
 or is it in error?

 - Jonathan M Davis

That's a surprise to me. Walter, is that intentional?

They do not require braces, they just require that the controlling statement not be a single ;. In the grammar, this is a ScopeStatement, which is a NonEmptyStatement or a BlockStatement. http://www.digitalmars.com/d/2.0/statement.html#ScopeStatement

Not always: http://d.puremagic.com/issues/show_bug.cgi?id=4024

Bugs in the compiler aren't errors in TDPL!

I totally agree. I was saying that the requirement for braces was not always intentional :S
Jun 22 2010
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jun 21, 2010 at 3:39 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 On 06/21/2010 02:09 PM, Jonathan M Davis wrote:
 Okay. I am in no way trying to say anything negative about TDPL.

[snip] You are being too kind about this :o). Of course we need an errata list. I was hoping I'd need to set it up later, but hey, that's a sign people actually are reading the book and care about keeping everything in check. I started an errata list in form of a community wiki at http://www.erdani.com/tdpl/errata and primed the errata with your report. Thanks very much! I'll see to it that future printings fix the issues in the errata list.

Will you fix all the god-awful puns too if we add those to the list? :-) Just kidding, I'm sure suffering through them helps build character or something. --bb
Jun 22 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/22/2010 01:45 PM, Bill Baxter wrote:
 On Mon, Jun 21, 2010 at 3:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:
 On 06/21/2010 02:09 PM, Jonathan M Davis wrote:
 Okay. I am in no way trying to say anything negative about TDPL.

[snip] You are being too kind about this :o). Of course we need an errata list. I was hoping I'd need to set it up later, but hey, that's a sign people actually are reading the book and care about keeping everything in check. I started an errata list in form of a community wiki at http://www.erdani.com/tdpl/errata and primed the errata with your report. Thanks very much! I'll see to it that future printings fix the issues in the errata list.

Will you fix all the god-awful puns too if we add those to the list? :-) Just kidding, I'm sure suffering through them helps build character or something.

If my puns suck I sure want to know which! Andrei
Jun 22 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Bill Baxter wrote:

 On Mon, Jun 21, 2010 at 3:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 On 06/21/2010 02:09 PM, Jonathan M Davis wrote:
 Okay. I am in no way trying to say anything negative about TDPL.

[snip] You are being too kind about this :o). Of course we need an errata list. I was hoping I'd need to set it up later, but hey, that's a sign people actually are reading the book and care about keeping everything in check. I started an errata list in form of a community wiki at http://www.erdani.com/tdpl/errata and primed the errata with your report. Thanks very much! I'll see to it that future printings fix the issues in the errata list.

Will you fix all the god-awful puns too if we add those to the list? :-) Just kidding, I'm sure suffering through them helps build character or something. --bb

Aw. Those were awesome. Of course, I love puns, so I'm not about to complain about them unless they're really bad, and Andrei's were good. - Jonathan M Davis
Jun 22 2010
prev sibling next sibling parent Graham Fawcett <fawcett uwindsor.ca> writes:
On Tue, 22 Jun 2010 11:45:39 -0700, Bill Baxter wrote:

 On Mon, Jun 21, 2010 at 3:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 On 06/21/2010 02:09 PM, Jonathan M Davis wrote:
 Okay. I am in no way trying to say anything negative about TDPL.

[snip] You are being too kind about this :o). Of course we need an errata list. I was hoping I'd need to set it up later, but hey, that's a sign people actually are reading the book and care about keeping everything in check. I started an errata list in form of a community wiki at http://www.erdani.com/tdpl/errata and primed the errata with your report. Thanks very much! I'll see to it that future printings fix the issues in the errata list.

Will you fix all the god-awful puns too if we add those to the list? :-) Just kidding, I'm sure suffering through them helps build character or something.

Awful puns, you say? Now I have to buy a copy! Graham
Jun 22 2010
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jun 22, 2010 at 11:52 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 On 06/22/2010 01:45 PM, Bill Baxter wrote:
 On Mon, Jun 21, 2010 at 3:39 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> =A0wrote:
 On 06/21/2010 02:09 PM, Jonathan M Davis wrote:
 Okay. I am in no way trying to say anything negative about TDPL.

[snip] You are being too kind about this :o). Of course we need an errata list=



 I
 was hoping I'd need to set it up later, but hey, that's a sign people
 actually are reading the book and care about keeping everything in chec=



 I started an errata list in form of a community wiki at

 http://www.erdani.com/tdpl/errata

 and primed the errata with your report.

 Thanks very much! I'll see to it that future printings fix the issues i=



 the
 errata list.

Will you fix all the god-awful puns too if we add those to the list? =A0=


 Just kidding, I'm sure suffering through them helps build character or
 something.

If my puns suck I sure want to know which! Andrei

They're fine. I'm just kidding. "A pun is the lowest form of humor-- if you didn't think of it first." -- Oscar Levant --bb
Jun 22 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Andrei Alexandrescu, el 21 de junio a las 17:43 me escribiste:
 If efficiency is still sub-par, retro could detect that it's working
 with iota and generate specialized code. That's not too difficult;
 for integers, retro(iota(a, b)) could actually be a rewrite to
 iota(b - 1, a, -1). Figuring out all corner cases, steps greater
 than 1, and what to do for floating point numbers is doable but not
 trivial either, and works against modularity. Anyway, it does look
 like it's all about an implementation matter.

I'm scared, I've heard that in C++ so many times... =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- HOMBRE DESNUDO AMENAZA A LOS VECINOS CON UNA "KATANA" DESDE SU BALCON -- Crónica TV
Jun 21 2010
prev sibling next sibling parent reply BCS <none anon.com> writes:
On page 6 it say: "the code sample above also introduced the if statement" 
but none of them do. 

-- 
... <IXOYE><
Jun 21 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/21/2010 10:01 PM, BCS wrote:
 On page 6 it say: "the code sample above also introduced the if
 statement" but none of them do.

Could you please add that to the errata? http://erdani.com/tdpl/errata Andrei
Jun 21 2010
prev sibling next sibling parent reply Byron Heads <wyverex.cypher gmail.com> writes:
On pg. 12 you define a recursive binary search, you forgot to pass value 
on the recursive call.

-B
Jun 22 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/22/2010 11:16 AM, Byron Heads wrote:
 On pg. 12 you define a recursive binary search, you forgot to pass value
 on the recursive call.

 -B

Saw the erratum you posted - thanks! Andrei
Jun 22 2010
prev sibling next sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
Can someone sanity check me on the code on pages 334-5?

Does the method push really need !empty in its in contract?

I might not be fully awake yet ><

A...
Jun 24 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Alix Pexton wrote:

 Can someone sanity check me on the code on pages 334-5?
 
 Does the method push really need !empty in its in contract?
 
 I might not be fully awake yet ><
 
 A...

It has to be an error. If you couldn't push onto an empty stack, then you'd never be able to put anything on the stack. - Jonathan M Davis
Jun 24 2010
parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 24/06/2010 09:09, Jonathan M Davis wrote:
 Alix Pexton wrote:

 Can someone sanity check me on the code on pages 334-5?

 Does the method push really need !empty in its in contract?

 I might not be fully awake yet><

 A...

It has to be an error. If you couldn't push onto an empty stack, then you'd never be able to put anything on the stack. - Jonathan M Davis

That's what I thought, but it's there in the example over the page as well, so I though maybe I was missing something >< A...
Jun 24 2010
parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Alix Pexton wrote:

 On 24/06/2010 09:09, Jonathan M Davis wrote:
 Alix Pexton wrote:

 Can someone sanity check me on the code on pages 334-5?

 Does the method push really need !empty in its in contract?

 I might not be fully awake yet><

 A...

It has to be an error. If you couldn't push onto an empty stack, then you'd never be able to put anything on the stack. - Jonathan M Davis

That's what I thought, but it's there in the example over the page as well, so I though maybe I was missing something >< A...

I haven't look at it in detail yet, but it definitely looks like it's a copy-paste error, and it makes no sense for a push function to insist that something have already been pushed before you can push anything onto the stack. - Jonathan M Davis
Jun 24 2010
prev sibling parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
Does anyone else feel that the following is a fair clarification?

Page 396
...
	This means that communicating processors "forget" the exact order in 
which data was written: one tread writes x and then y and for a while 
another thread sees the new y but only the old x.

vvv

	This means that communicating processors "forget" the exact order in 
which data was written: one tread writes to x and then to y and for a 
while another thread sees the new value of y but only the old value of x.

...


Once I got my head around what is being claimed, I realised that it is 
correct as it appears, but it took me several reading to get there. It 
might just be because I'm a bit of a concurrency novice, but I'm sure 
I'm not the only one with a copy of tDPL ^^

A...
Jun 24 2010