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 co
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 tha
Andrei Alexandrescu 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
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 err
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 yo
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
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...
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
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
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
== Quote from bearophile (bearophileh...@lycos.com)'s article
> 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
becau
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
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
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.
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
semi
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
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 re
Rory McGuire wrote:
> On Tue, 22 Jun 2010 23:37:59 +0200, Andrei Alexandrescu
> wrote:
>
>> Walter, can we require a semicolon please?
> +1
>
> 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 th
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 b
On 06/23/2010 04:56 AM, Don wrote:
bearophile wrote:
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
On Wed, 23 Jun 2010 11:56:12 +0200, Don wrote:
> bearophile wrote:
>> 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
bearophile wrote:
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
On Tue, 22 Jun 2010 23:37:59 +0200, Andrei Alexandrescu
wrote:
Walter, can we require a semicolon please?
+1
With the semi colon missing its as bad as:
for (;i<100;i++);
writeln(i);
esp. with large amount of code
Andrei
Rory
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 r
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 afte
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,
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
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. Consid
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
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. AAH
THERE IS NOOO SEMICOLON AT T
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. AAH
>> THERE IS NOOO SEMICOLON AT THE END.
>>
>> Wow. Sorry. This is a pet p
On Tue, Jun 22, 2010 at 11:52 AM, Andrei Alexandrescu
wrote:
> On 06/22/2010 01:45 PM, Bill Baxter wrote:
>>
>> On Mon, Jun 21, 2010 at 3:39 PM, 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 ab
Bill Baxter wrote:
> On Mon, Jun 21, 2010 at 3:39 PM, 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.
>>
>> [snip]
>>
>> You are being too kind about this :o). Of course we need an errata list
On Tue, 22 Jun 2010 11:45:39 -0700, Bill Baxter wrote:
> On Mon, Jun 21, 2010 at 3:39 PM, 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.
>>
>> [snip]
>>
>> You are being too kind about this :
On 06/22/2010 01:45 PM, Bill Baxter wrote:
On Mon, Jun 21, 2010 at 3:39 PM, 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.
[snip]
You are being too kind about this :o). Of course we need an errata
On Mon, Jun 21, 2010 at 3:39 PM, 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.
>
> [snip]
>
> You are being too kind about this :o). Of course we need an errata list. I
> was hoping I'd need to se
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
On pg. 12 you define a recursive binary search, you forgot to pass value
on the recursive call.
-B
ment 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 t
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!
On 06/22/2010 07:18 AM, bearophile wrote:
So I suggest to replace that line in the iota() costructor with:
enforce(step != 0);
And then create an empty generator if pastLast<= current (and the step is 1).
Absolutely. I wrote that test to simplify my life, but in the final
version iota should
Andrei:
>I optimized things such that the commonly used path (many calls to empty,
>front, and popFront) is as fast as possible. The initial work will be
>amortized for most loops.<
New timings:
Running time, best of 3, seconds:
test1: 0.31
test1 opt: 0.07
test2: 0.31
test2 opt
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 brac
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
On 21/06/2010 21:51, Tomek Sowiński wrote:
Dnia 21-06-2010 o 21:57:49 Alix Pexton
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
t
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
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
On 6/21/2010 8:12 PM, Andrei Alexandrescu wrote:
>
> I optimized things such that the commonly used path (many calls to
> empty, front, and popFront) is as fast as possible. The initial work
> will be amortized for most loops.
>
> On my machine, test4 is still 2x slower than foreach_reverse in an
On 06/21/2010 08:28 PM, bearophile wrote:
Andrei Alexandrescu:
That's not too difficult; for integers, retro(iota(a, b)) could actually be a
rewrite to iota(b - 1, a, -1).<
This is good. In my dlibs the xchain converts xchain(xchain(x, y), z) and
similar into xchain(x, y, z).
Figuring ou
On page 6 it say: "the code sample above also introduced the if statement"
but none of them do.
--
... <
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.
--
... <
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
Andrei Alexandrescu:
>That's not too difficult; for integers, retro(iota(a, b)) could actually be a
>rewrite to iota(b - 1, a, -1).<
This is good. In my dlibs the xchain converts xchain(xchain(x, y), z) and
similar into xchain(x, y, z).
>Figuring out all corner cases, steps greater than 1, an
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 b
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
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 er
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 un
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.
> [snip]
>
> 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
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 th
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 con
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 c
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. AAH
THERE IS NOOO SEMICOLON AT THE END.
Wow. Sorry. This is a pet peeve of mine.
Can't help that, sorry...
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 quit
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 boo
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
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;
Dnia 21-06-2010 o 21:57:49 Alix Pexton
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 i
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. AAH
THERE IS NOOO SEMICOLON AT THE END.
Wow. Sorry. This is a pet peeve of mine.
On 6/21/10, bearophile wrote:
> How do you write this?
> foreach_reverse (i; 0 .. 10)
foreach(i; retro(iota(0, 10))) { }
?
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 helpf
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
ted 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
72 matches
Mail list logo
