www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Case Range Statement ..

reply Tim Matthews <tim.matthews7 gmail.com> writes:
The case range statement is currently this

case FirstExp : .. case LastExp :

Would it be ambiguous to the compiler if it was

case FirstExp .. case LastExp :

or even

case FirstExp .. LastExp :


Considering that we can correctly identify a slice rather than decimal 
by just giving it a priority:

a = b[3..6];
Jul 06 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tim Matthews wrote:
 The case range statement is currently this
 
 case FirstExp : .. case LastExp :
 
 Would it be ambiguous to the compiler if it was
 
 case FirstExp .. case LastExp :
 
 or even
 
 case FirstExp .. LastExp :
 
 
 Considering that we can correctly identify a slice rather than decimal 
 by just giving it a priority:
 
 a = b[3..6];
I'm tired of typing this multiple times, so please indulge me while I cut & paste from one of them: Because 1. case X..Y: looks like 2. foreach(e; X..Y) 3. array[X..Y] yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and (2) and (3) are exclusive of Y. Having a very different meaning means it should have a distinctly different syntax.
Jul 06 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Now a FAQ entry!

http://www.digitalmars.com/d/2.0/faq.html#case_range
Jul 06 2009
parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Walter Bright wrote:
 Now a FAQ entry!
 
 http://www.digitalmars.com/d/2.0/faq.html#case_range
But it only explains the inclusive/exclusiveness and not any of the other points. Do you not agree that the syntax looks a little ugly?
Jul 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tim Matthews wrote:
 But it only explains the inclusive/exclusiveness and not any of the 
 other points.
Let's start with agreeing on why: case X..Y: is not appropriate.
 Do you not agree that the syntax looks a little ugly?
I haven't seen any thing less ugly that is workable.
Jul 06 2009
next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Walter Bright wrote:
 Tim Matthews wrote:
 But it only explains the inclusive/exclusiveness and not any of the 
 other points.
Let's start with agreeing on why: case X..Y: is not appropriate.
Do we have to be so immature about this, it's an actual topic rather than the random trolls that have been posted by many here. I was originally asking about the ambiguity of not having the extra colon but anyway: Yes I agree double dot for case range is inconsistent with the double dot for range due to one being inclusive of the endpoint. berophile suggested using tripple dot in announce and he got "why?" as a reply. The "why" has already been posted but the "why not" hasn't yet people reply to me with "here we go again!". Alternatively don't use dots. I think the issue with the extra "case" and/ ";" needs to be treated differently. There or not the syntax may seem inconsistent to new D users.
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tim Matthews wrote:
 Walter Bright wrote:
 Tim Matthews wrote:
 But it only explains the inclusive/exclusiveness and not any of the 
 other points.
Let's start with agreeing on why: case X..Y: is not appropriate.
Do we have to be so immature about this, it's an actual topic rather than the random trolls that have been posted by many here. I was originally asking about the ambiguity of not having the extra colon but anyway:
There is no ambiguity in removing the extra colon.
 Yes I agree double dot for case range is inconsistent with the double 
 dot for range due to one being inclusive of the endpoint. berophile 
 suggested using tripple dot in announce and he got "why?" as a reply.
 The "why" has already been posted but the "why not" hasn't yet people 
 reply to me with "here we go again!".
My "why" embedded two longer comments: a) Currently "..." ends something and ".." separates something, much like in natural language. His suggestion would have "..." separate something. Why? b) Even if we ignore (a) for the moment, the "why" is legitimate at face value: we have a syntax that is implemented and works. Any change to the syntax should mark an improvement. Where is the improvement? Just because it doesn't not work doesn't mean it must be adopted! It has also been suggested in an earlier thread a range with ".." should mean open and a range with "..." should mean closed. I explained back then how that proposal was a complete disaster.
 Alternatively don't use dots.
How would that work? And... why?
 I think the issue with the extra "case" and/ ";" needs to be treated 
 differently. There or not the syntax may seem inconsistent to new D users.
I swear if I didn't know anything about the feature and saw the syntax "case a: .. case b:" I'd know exactly what it does in a millisecond. Why would the syntax seem inconsistent to new D users? First of all, inconsistent with what? And how would you treat the issue differently? Andrei
Jul 07 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:
 I swear if I didn't know anything about the feature and saw the syntax
 "case a: .. case b:" I'd know exactly what it does in a millisecond. Why
 would the syntax seem inconsistent to new D users? First of all,
 inconsistent with what? And how would you treat the issue differently?
 
 
 Andrei
I think something that might help is if you started using the syntax like this:
 case a:
 ..
 case b:
     blah
Now it's clear that it represents a sequence of case labels where all but the first and last have been elided VERSUS representing a case label where the label is a range. I get the sneaking suspicion that the major problem people have with the syntax is that when you write "case a: .. case b:" all on one line, they treat it as the latter when they should be thinking in terms of the former; the various suggestions that have been made would seem to support this.
Jul 07 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Daniel Keep escribió:
 Andrei Alexandrescu wrote:
 I swear if I didn't know anything about the feature and saw the syntax
 "case a: .. case b:" I'd know exactly what it does in a millisecond. Why
 would the syntax seem inconsistent to new D users? First of all,
 inconsistent with what? And how would you treat the issue differently?


 Andrei
I think something that might help is if you started using the syntax like this:
 case a:
 ..
 case b:
     blah
Now it's clear that it represents a sequence of case labels where all but the first and last have been elided VERSUS representing a case label where the label is a range.
That's nice! I'll make Descent format code like that. And NO, you won't be able to change that, and it will format it when you are typing, and you won't be able to change it's form even if you wanted. Nah, just kidding.
Jul 07 2009
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Daniel Keep wrote:
 Andrei Alexandrescu wrote:
 I swear if I didn't know anything about the feature and saw the syntax
 "case a: .. case b:" I'd know exactly what it does in a millisecond. Why
 would the syntax seem inconsistent to new D users? First of all,
 inconsistent with what? And how would you treat the issue differently?


 Andrei
I think something that might help is if you started using the syntax like this:
 case a:
 ..
 case b:
     blah
Now it's clear that it represents a sequence of case labels where all but the first and last have been elided VERSUS representing a case label where the label is a range. I get the sneaking suspicion that the major problem people have with the syntax is that when you write "case a: .. case b:" all on one line, they treat it as the latter when they should be thinking in terms of the former; the various suggestions that have been made would seem to support this.
I've been keeping quiet on the subject to see how it plays out... Now I've seen it written like this I'm sold! :D
Jul 07 2009
prev sibling parent Tim Matthews <tim.matthews7 gmail.com> writes:
Andrei Alexandrescu wrote:

 
 I swear if I didn't know anything about the feature and saw the syntax 
 "case a: .. case b:" I'd know exactly what it does in a millisecond. Why 
 would the syntax seem inconsistent to new D users? First of all, 
 inconsistent with what? And how would you treat the issue differently?
 
 
 Andrei
When I said inconsistent I was agreeing with walter previously stated that it has a very different meaning. Because between the case and colons there is the double dot previously just used in range's start and 1 past endpoint. In case range we include the endpoint. We just now have an extra verbose syntax that would be great for minimizing ambiguity but instead is getting used to minimize inconsistency.
Jul 07 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Tim Matthews wrote:
 Walter Bright wrote:
 Tim Matthews wrote:
 But it only explains the inclusive/exclusiveness and not any of the 
 other points.
Let's start with agreeing on why: case X..Y: is not appropriate.
Do we have to be so immature about this, it's an actual topic rather than the random trolls that have been posted by many here.
You did pose that case, and please forgive me for being a bit testy about it being repeatedly asked and answered.
 I was originally asking about the ambiguity of not having the extra 
 colon but anyway:
 
 Yes I agree double dot for case range is inconsistent with the double 
 dot for range due to one being inclusive of the endpoint. berophile 
 suggested using tripple dot in announce and he got "why?" as a reply. 
 The "why" has already been posted but the "why not" hasn't yet people 
 reply to me with "here we go again!".

 Alternatively don't use dots.
As for the "why not" of: case X .. case Y: it's really the same reason that ; is used to terminate a statement. The ; is not strictly necessary, but it provides a nice anchor for parsing when things go wrong. You get a reasonably well targeted message with the right line number instead of something erratic. As for the "why not" of ...: ... and .. are not visually very distinguishable, and frankly I can't see a compelling "why" for it.
Jul 07 2009
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I have not read this entire topic, but what about the following:

case 5, .., 9:

Or even:

case 5.., 9:

This actually can be very logical, IMHO, because it's saying that 9 is 
included very specifically.

Other possibilities that could be explored:

case for 5, 9:
case somekindofrange!(5, 9):

In any case, I am unsure how to indent the current syntax within my 
coding standards.  This is unacceptable to me:

case 5: .. case 9:

(which honestly has the same problem you name.)  I guess I have to use this:

case 5: ...
case 9:

But, certainly that .. will get lost.  Alas, I suppose I will pretend 
this feature of D does not exist, then.  I have serious concerns with 
loading multiple statements on one line, and otherwise it's invisible.

-[Unknown]


Walter Bright wrote:
 Tim Matthews wrote:
 But it only explains the inclusive/exclusiveness and not any of the 
 other points.
Let's start with agreeing on why: case X..Y: is not appropriate.
 Do you not agree that the syntax looks a little ugly?
I haven't seen any thing less ugly that is workable.
Jul 11 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Jul 11, 2009 at 4:37 PM, Unknown W.
Brackets<unknown simplemachines.org> wrote:
 I have not read this entire topic, but what about the following:

 case 5, .., 9:
I don't have a problem with the current syntax, but the mathematical side of my brain squealed with fanboyish glee when it saw this. This would be FANTASTIC.
Jul 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Sat, Jul 11, 2009 at 4:37 PM, Unknown W.
 Brackets<unknown simplemachines.org> wrote:
 I have not read this entire topic, but what about the following:

 case 5, .., 9:
I don't have a problem with the current syntax, but the mathematical side of my brain squealed with fanboyish glee when it saw this. This would be FANTASTIC.
At some point, we need to just move on with this. As to ,.., I suggest is it not visually very distinct in many fonts (the comma and the .) and may lead to frustrating syntax errors. While there are many "programmers' fonts" that do a good job making the characters all distinguishable, the language shouldn't rely too heavily on that. There's already enough trouble with 0 and O.
Jul 11 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Jul 11, 2009 at 4:59 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 On Sat, Jul 11, 2009 at 4:37 PM, Unknown W.
 Brackets<unknown simplemachines.org> wrote:
 I have not read this entire topic, but what about the following:

 case 5, .., 9:
I don't have a problem with the current syntax, but the mathematical side of my brain squealed with fanboyish glee when it saw this. =A0This would be FANTASTIC.
At some point, we need to just move on with this. As to ,.., I suggest is=
it
 not visually very distinct in many fonts (the comma and the .) and may le=
ad
 to frustrating syntax errors.

 While there are many "programmers' fonts" that do a good job making the
 characters all distinguishable, the language shouldn't rely too heavily o=
n
 that. There's already enough trouble with 0 and O.
int O_O =3D 0_0;
Jul 11 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Jul 11, 2009 at 4:42 PM, Jarrett
Billingsley<jarrett.billingsley gmail.com> wrote:
 On Sat, Jul 11, 2009 at 4:37 PM, Unknown W.
 Brackets<unknown simplemachines.org> wrote:
 I have not read this entire topic, but what about the following:

 case 5, .., 9:
I don't have a problem with the current syntax, but the mathematical side of my brain squealed with fanboyish glee when it saw this. =A0This would be FANTASTIC.
Oh man, and it's even extensible and would mesh perfectly with the existing syntax: case 1, 3: // 1 or 3 case 5, .., 9: // 5, 6, 7, 8, 9 case 10, 12, .., 17, 19: 10, 12, 13, 14, 15, 16, 17, 19
Jul 11 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sat, Jul 11, 2009 at 1:37 PM, Unknown W.
Brackets<unknown simplemachines.org> wrote:
 I have not read this entire topic, but what about the following:

 case 5, .., 9:
Agreed. That would be a nicer syntax. --bb
Jul 11 2009
prev sibling next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Walter Bright wrote:
 I'm tired of typing this multiple times, so please indulge me while I 
 cut & paste from one of them:
I don't mean to frustrate. I thought it may be in at least on of those replies but I think it deserves it's own subject.
 Having a very different meaning means it should have a distinctly 
 different syntax.
I agree there in many ways but D doesn't really follow the rule for example: static import bar; //must use fully qualified name static int i; //persistent across calls static void foo() {} //member of class rather than instance have you considered a syntax that is radically different from case FirstExp : .. case LastExp : like many of the posts in announce have suggested
Jul 06 2009
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 07 Jul 2009 17:56:31 +1200, Tim Matthews wrote:

I want to try and using similar terminology to show that 'static' is used 
with the same principle.

 static import bar;   //must use fully qualified name 
The module "owns" the members (functions, globals). Since the owner is the module you must ask the module for its use.
 static int i;    //persistent across calls 
The function "owns" the variable. Rather than having each call to a function have the int i, all calls use the same one since the function owns it and not the call.
 static void foo() {} //member of class rather than instance
The class "owns" the function. Much like the previous one, the class instance doesn't own it, the class does, so all instances share the same thing.
 have you considered a syntax that is radically different from case
 FirstExp : .. case LastExp : like many of the posts in announce have
 suggested
I do believe they have, and do agree the syntax is a little... odd... but I think the alternatives have been turned down for good reason.
  case FirstExp .. case LastExp :
Is nice, but I don't think removing the : really adds much, besides, Daniel Keep's shown form of writing it looks better with the : and ultimately better than the above form.
Jul 06 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  6 de julio a las 22:24 me escribiste:
 Tim Matthews wrote:
The case range statement is currently this
case FirstExp : .. case LastExp :
Would it be ambiguous to the compiler if it was
case FirstExp .. case LastExp :
or even
case FirstExp .. LastExp :
Considering that we can correctly identify a slice rather than decimal by just 
giving it a priority:
a = b[3..6];
I'm tired of typing this multiple times, so please indulge me while I cut & paste from one of them: Because 1. case X..Y: looks like 2. foreach(e; X..Y) 3. array[X..Y] yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and (2) and (3) are exclusive of Y. Having a very different meaning means it should have a distinctly different syntax.
I think this is a weak argument, because you are still using the ".."! You're just adding extra chars in the mix which looks like syntactic noise to me. Why won't you think that case 5: .. case 10: is inclusive when foreach(e; 5 .. 10) is exclusive? I just don't get it... I think the ... operator makes perfect sense because it's more general, yo could use array[X...Y] and case X..Y: where appropriate. I have to confess that arranged like this: switch (x) { case 5: .. case 10: // .. } doesn't look so bad though, but I think it could be easy to miss the ".." when reviewing the code and there is still the semantic issue you talk about the ".." operator being inconsistently inclusive and exclusive depending on the context. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Walter Bright, el  6 de julio a las 22:24 me escribiste:
 Tim Matthews wrote:
 The case range statement is currently this
 case FirstExp : .. case LastExp :
 Would it be ambiguous to the compiler if it was
 case FirstExp .. case LastExp :
 or even
 case FirstExp .. LastExp :
 Considering that we can correctly identify a slice rather than decimal by just 
 giving it a priority:
 a = b[3..6];
I'm tired of typing this multiple times, so please indulge me while I cut & paste from one of them: Because 1. case X..Y: looks like 2. foreach(e; X..Y) 3. array[X..Y] yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and (2) and (3) are exclusive of Y. Having a very different meaning means it should have a distinctly different syntax.
I think this is a weak argument, because you are still using the ".."!
Various different expressions are using various other tokens giving them different meanings, and nobody blinks an eye.
 You're just adding extra chars in the mix which looks like syntactic noise
 to me.
Those make it clear at the first sight what the construct does.
 Why won't you think that case 5: .. case 10: is inclusive when
 foreach(e; 5 .. 10) is exclusive? I just don't get it...
Because: a) People coming from C, C++, or Java would be used to the notion of iterating over right-open integral ranges from e.g. iterating over arrays using indexes. b) When writing down case labels, nobody expects to write one down knowing it won't be effected.
 I think the ... operator makes perfect sense because it's more general,
 yo could use array[X...Y] and case X..Y: where appropriate.
Is Y a global? :o) (Trick question.)
 I have to confess that arranged like this:
 
 switch (x)
 {
 case 5:
 ..
 case 10:
 // ..
 
 }
 
 doesn't look so bad though, but I think it could be easy to miss the ".."
 when reviewing the code and there is still the semantic issue you talk
 about the ".." operator being inconsistently inclusive and exclusive
 depending on the context.
How in the world can one miss ".." and not miss various other tokens? Token meaning has ALWAYS depended on context. ALWAYS. Andrei
Jul 07 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  7 de julio a las 10:19 me escribiste:
 Token meaning has ALWAYS depended on context. ALWAYS.
I can use the exact same argument for using case X..Y: then =) At least let's agree one is as arbitrary as the other... I can live with that syntax if you (people who likes case X: .. case Y: is better) accept that is just a cosmetic issue and you like your syntax better (and since who make the decisions likes it better, it will stay like that). Can you at least use: case X: .. case Y: in the examples/documentation/specs? I think most case X: .. case Y: haters found that format pretty acceptable, so we can all be a little happier =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el  7 de julio a las 10:19 me escribiste:
 Token meaning has ALWAYS depended on context. ALWAYS.
I can use the exact same argument for using case X..Y: then =)
You could, but it would be much more of a stretch. This is because expression1..expression2 is already a grammatical construct, so we're not talking only about one token anymore.
 At least let's agree one is as arbitrary as the other...
No. I don't agree at all.
 I can live with
 that syntax if you (people who likes case X: .. case Y: is better) accept
 that is just a cosmetic issue and you like your syntax better (and since
 who make the decisions likes it better, it will stay like that).
"case X: .. case Y:" is a cosmetic issue over e.g "case X .. case Y:" but is worlds better than "case X .. Y" and most or all other suggested syntaxes.
 Can you at least use:
 case X:
 ..
 case Y:
 
 in the examples/documentation/specs? I think most case X: .. case Y:
 haters found that format pretty acceptable, so we can all be a little
 happier =)
To me they look the same, but if people are happier with wasting vertical space, sure. Andrei
Jul 07 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 11:01:12 -0500, Andrei Alexandrescu wrote:

 To me they look the same, but if people are happier with wasting 
 vertical space, sure.
I think I've finally worked out why I don't like this syntax. Consider this ... switch (X) { case 1: funcA(); break; case 2,5,7,10 .. 17, 24, 32: funcB(); break; case 3,6,8,18 .. 23: funcC(); break; } In other words, allowing a range of value inside a list of values. How is this possible in today's D? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wed, Jul 08, 2009 at 02:48:31AM +1000, Derek Parnell wrote:
    switch (X) {
       case 1: funcA(); break;
       case 2,5,7,10 .. 17, 24, 32: funcB(); break;
       case 3,6,8,18 .. 23: funcC(); break;
    }
 In other words, allowing a range of value inside a list of values.
 
 How is this possible in today's D?
switch(X) { case 1: stuff; break; case 2,5,7: case 10: .. case 17: case 24,32: stuff; break; case 3,6,8: case 18: .. case 23: stuff; break; } This compiles on the new dmd. Only one item is allowed on a case range, but you can just use fall through behaviour to make it its own case right after the list. -- Adam D. Ruppe http://arsdnet.net
Jul 07 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 7, 2009 at 9:48 AM, Derek Parnell<derek psych.ward> wrote:
 On Tue, 07 Jul 2009 11:01:12 -0500, Andrei Alexandrescu wrote:

 To me they look the same, but if people are happier with wasting
 vertical space, sure.
I think I've finally worked out why I don't like this syntax. Consider th=
is
 ...


 =A0 switch (X) {
 =A0 =A0 =A0case 1: funcA(); break;
 =A0 =A0 =A0case 2,5,7,10 .. 17, 24, 32: funcB(); break;
 =A0 =A0 =A0case 3,6,8,18 .. 23: funcC(); break;
 =A0 }

 In other words, allowing a range of value inside a list of values.

 How is this possible in today's D?
By adding the word "case" several more times. I really wish we would just go with two-dots for exclusive, three-dots for inclusive, and make that work consistently everywhere. The "too similar to see the difference" argument just doesn't hold weight with me. Unless you're programming in a proportional-width font the difference is pretty obvious. Or define some other char sequence to mean inclusive range. Like a ..|b or a..:b or a..^b, etc. --bb
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 I really wish we would just go with two-dots for exclusive, three-dots
 for inclusive, and make that work consistently everywhere.
 
 The "too similar to see the difference" argument just doesn't hold
 weight with me.  Unless you're programming in a proportional-width
 font the difference is pretty obvious.  
That is troublesome because it introduces very weird semantics driven by counting dots and inserting whitespace. Consider: int wyda; void main() { int wyda; foreach (i; 0...wyda) { .... } } Now there are several problems with this. All of the following compile: 0.....wyda 0....wyda 0... .wyda 0. .. .wyda 0.... wyda 0. ...wyda 0. ....wyda 0.. .wyda and many others too. Using "..." as a separator in addition to a trailing symbol is bound to be a complete disaster.
 Or define some other char
 sequence to mean inclusive range.  Like  a ..|b  or a..:b or a..^b,
 etc.
That is more sensible. But as far as switch is concerned, I'm thoroughly content with what we have now, modulo the 256 limit. Andrei
Jul 07 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:
 Now there are several problems with this. All of the following compile:
Possible solution: treat all sequences as dots as part of the same token, always.
 0.....wyda
 0....wyda
 0.... wyda
 0... .wyda
 0.. .wyda
 0. ....wyda
All rejected by the lexer.
 0. .. .wyda
 0. ...wyda
Legal and unambiguous. -- Rainer Deyke - rainerd eldwood.com
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:
 Andrei Alexandrescu wrote:
 Now there are several problems with this. All of the following compile:
Possible solution: treat all sequences as dots as part of the same token, always.
 0.....wyda
 0....wyda
 0.... wyda
 0... .wyda
 0.. .wyda
 0. ....wyda
All rejected by the lexer.
No. Actually, some, yes :o).
 0. .. .wyda
 0. ...wyda
Legal and unambiguous.
And throroughly confusing, which was my point. Andrei
Jul 07 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Rainer Deyke wrote:
 Andrei Alexandrescu wrote:
 Now there are several problems with this. All of the following compile:
Possible solution: treat all sequences as dots as part of the same token, always.
 0.....wyda
 0....wyda
 0.... wyda
 0... .wyda
 0.. .wyda
 0. ....wyda
All rejected by the lexer.
No. Actually, some, yes :o).
I think he meant those /could/ be made to be rejected by the lexer. At least rejecting more than three consecutive dots leaves you with: 0... .wyda 0.. .wyda which are ok. Also "0." and the like should be rejected.
 
 0. .. .wyda
 0. ...wyda
Legal and unambiguous.
And throroughly confusing, which was my point.
The ".name" syntax and the "number." are the things that are confusing, not the inclusive/exclusive ranges.
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Rainer Deyke wrote:
 Andrei Alexandrescu wrote:
 Now there are several problems with this. All of the following compile:
Possible solution: treat all sequences as dots as part of the same token, always.
 0.....wyda
 0....wyda
 0.... wyda
 0... .wyda
 0.. .wyda
 0. ....wyda
All rejected by the lexer.
No. Actually, some, yes :o).
I think he meant those /could/ be made to be rejected by the lexer.
Hack the lexer to support a useless and dangerous feature? Now we got something going.
 At 
 least rejecting more than three consecutive dots leaves you with:
 
 0... .wyda
 0.. .wyda
 
 which are ok. Also "0." and the like should be rejected.
Yup, more gratuitous changes to the language. We are left with "the little space that could change everything".
 0. .. .wyda
 0. ...wyda
Legal and unambiguous.
And throroughly confusing, which was my point.
The ".name" syntax and the "number." are the things that are confusing, not the inclusive/exclusive ranges.
The .name syntax and the number. syntax are confusing. Using "..." as a separator multiplies confusion by a billion. Andrei
Jul 07 2009
parent Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 14:47:06 -0500, Andrei Alexandrescu wrote:

 The .name syntax and the number. syntax are confusing. Using "..." as a 
 separator multiplies confusion by a billion.
A "billion" - really? And yet I'm not confused by it, so does that make me very clever or very stupid ... hmmmm? By the way, I don't like triple-dot either, but just making a point. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
Or define some other char sequence to mean inclusive range.  Like  a ..|b  or
a..:b or a..^b, etc.<
The Chapel language uses: That I think is better than all your alternatives. But I think Andrei doesn't like this too. Bye, bearophile
Jul 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Bill Baxter:
 Or define some other char sequence to mean inclusive range.  Like  a ..|b  or
a..:b or a..^b, etc.<
The Chapel language uses: That I think is better than all your alternatives. But I think Andrei doesn't like this too.
I like: a .. b+1 to mean inclusive range.
Jul 07 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright Wrote:
 I like:
     a .. b+1
 to mean inclusive range.
Me too, but does it work when the upper interval is int.max, char.max, ulong.max, ucent.max, etc? Bye, bearophile
Jul 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Walter Bright Wrote:
 I like:
     a .. b+1
 to mean inclusive range.
Me too, but does it work when the upper interval is int.max, char.max, ulong.max, ucent.max, etc?
Nope. Wrap around is always a special case, not just for ranges. It's in the nature of 2's complement arithmetic.
Jul 07 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:h30845$2kla$2 digitalmars.com...
 bearophile wrote:
 Walter Bright Wrote:
 I like:
     a .. b+1
 to mean inclusive range.
Me too, but does it work when the upper interval is int.max, char.max, ulong.max, ucent.max, etc?
Nope. Wrap around is always a special case, not just for ranges. It's in the nature of 2's complement arithmetic.
Suppose, hypothetically, that we did have a "right-inclusive-range" token. 'poopiesOnAFlyingStick', whatever. Now, as has been pointed out far to many times by now to still not get: a .. int.max+1 // wraparound breaks it a right_inclusive_range_tok int.max // works fine, wraparound isn't even relevant. And another problem people have already pointed out numerous times with making "a .. b+1" the inclusive range syntax: double a=1, b=5; // Let's make an inclusive range from 1.0 to 5.0! a .. b+1 // Oh look! 5.5f is in the range! It didn't f*^* work! And yet another: float a=1, b=somethingReallyLarge; assert(b+1 == b); // Let's make an inclusive range! a .. b+1 // Oh look! b is missing from the range! It didn't f*^* work again! "a .. b+1" as *the* inclusive range is just plain broken. There is no "Yea, but...!" that can change that. And while I'm ranting, why in the world is anyone defending the continued existance of "5." and ".5"? "Because it's already there and it basically still works and isn't hurting anyone." Well it seems to be hurting the adoption of an inclusive range that actually works. I thougt the point of D was to clean up useless cruft like that, even if it still works (header files) to make way for better approaches.
Jul 07 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:
 why in the world is anyone defending the continued existance of "5." and ".5"?<
I'm for disallowing them; 5.0 ad 0.5 are better. Anyone else pro/against this idea? Regarding number literals, I'm also for: B) turning the current octal syntax into a syntax error and introducing a safer octal syntax (see Python 3); C) adding unbounded integral literals for multi-precisions integral numbers (to be used by bigintegers implemented in the std lib or other D code). (This is to teach D another bit of fishing, using Andrei metaphor). Bye, bearophile
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 C) adding unbounded integral literals for multi-precisions integral
 numbers (to be used by bigintegers implemented in the std lib or
 other D code). (This is to teach D another bit of fishing, using
 Andrei metaphor).
No, it's exactly the opposite - putting on the table a rotten fish. Big integer literals can be accommodated as compile-time strings. Andrei
Jul 07 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 No, it's exactly the opposite - putting on the table a rotten fish.<
If it's so smelly all people will avoid it quickly, so no harm done :-)
Big  integer literals can be accommodated as compile-time strings.
Do you mean like this? BigInt a = "12_345_678_900_345_678_900_000"; If that's what you say, then it's OK. There are more important things to think about. Bye, bearophile
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 No, it's exactly the opposite - putting on the table a rotten fish.<
If it's so smelly all people will avoid it quickly, so no harm done :-)
 Big  integer literals can be accommodated as compile-time strings.
Do you mean like this? BigInt a = "12_345_678_900_345_678_900_000"; If that's what you say, then it's OK. There are more important things to think about.
Needs to be something like: BigInt a = bigIntLiteral!"12_345_678_900_345_678_900_000"; Anyway, I think this feature is thoroughly useless. An adage says that the only numeric literals in a program should be 0, 1, and -1. How many big integer literals can you think of right now? Andrei
Jul 07 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Anyway, I think this feature is thoroughly useless. An adage says that 
 the only numeric literals in a program should be 0, 1, and -1. How many 
 big integer literals can you think of right now?
OK, let's forget big integer literals for now :-) I agree that there are bigger fishes to talk about. For example I may like some things present in Delight, like especially this one (already discussed in the past, of course): http://delight.sourceforge.net/null.html Smaller things in Delight: Good to have: - An important difference between D and Delight is that a Delight array is considered true if and only if its length is non-zero: I like: - Also, D allows null to be used to mean an empty array. In Delight, you can only use []. Improvements in the imports: - Import all symbols into our namespace: import example.utils: * - Import a module, accessed by its full name: import dlt.io void sayHi(dlt.io.Printer p): ... Bye, bearophile
Jul 07 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Anyway, I think this feature is thoroughly useless. An adage says that 
 the only numeric literals in a program should be 0, 1, and -1. How many 
 big integer literals can you think of right now?
The deficit?
Jul 07 2009
prev sibling parent BCS <none anon.com> writes:
Hello Andrei,

 Anyway, I think this feature is thoroughly useless. An adage says that
 the only numeric literals in a program should be 0, 1, and -1. How
 many big integer literals can you think of right now?
The Avogadro constant is slightly less than 2^79. (~2^78.99)
Jul 07 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:

 Nick Sabalausky:
 why in the world is anyone defending the continued existance of "5." and ".5"?<
I'm for disallowing them; 5.0 ad 0.5 are better. Anyone else pro/against this idea?
I would not complain if trailing dot and leading dot were disallowed. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:
 
 Nick Sabalausky:
 why in the world is anyone defending the continued existance of "5." and ".5"?<
I'm for disallowing them; 5.0 ad 0.5 are better. Anyone else pro/against this idea?
I would not complain if trailing dot and leading dot were disallowed.
I think the question that should be asked is: would anyone complain if they were kept? We have bigger rocks to move than that one. Andrei
Jul 07 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 I think the question that should be asked is: would anyone complain if
 they were kept? We have bigger rocks to move than that one.
D has small differences, like disallowing 156l (only 156L is allowed). Such small details build up improving the language. For example I have put a real bug in a Python program of mine because I have written xrange(100000) instead of xrange(1000000). In D I avoid such bug because I always write such numbers as 1_000_000. After that bug I now write in Python like this: xrange(1000*1000) (Python has recently added a peephole optimizer, so that multiplication is now not done at run-time, oh marvel), but that way can't be used for other kind of integer literals. I've asked two times to introduce _ in integer literals in Python too, but at the end Hettinger has answered me that it requires too many changes in the C code and the gain is little because most Python programs don't contain many integer literals (D contains them more often). I don't agree with Hettinger. Disallowing octal syntax and 5. .5 can be positive :-) Bye, bearophile
Jul 07 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello Andrei,

 Derek Parnell wrote:
 
 On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:
 
 Nick Sabalausky:
 
 why in the world is anyone defending the continued existance of
 "5." and ".5"?<
 
I'm for disallowing them; 5.0 ad 0.5 are better. Anyone else pro/against this idea?
I would not complain if trailing dot and leading dot were disallowed.
I think the question that should be asked is: would anyone complain if they were kept? We have bigger rocks to move than that one. Andrei
Dropping them makes lexing cleaner: strictly "5..5" should lex as "5." ".5" based on maximal munch ( http://en.wikipedia.org/wiki/Maximal_munch )
Jul 07 2009
parent Matti Niemenmaa <see_signature for.real.address> writes:
BCS wrote:
 Hello Andrei,
 
 Derek Parnell wrote:

 On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:

 Nick Sabalausky:

 why in the world is anyone defending the continued existance of
 "5." and ".5"?<
I'm for disallowing them; 5.0 ad 0.5 are better. Anyone else pro/against this idea?
I would not complain if trailing dot and leading dot were disallowed.
I think the question that should be asked is: would anyone complain if they were kept? We have bigger rocks to move than that one. Andrei
Dropping them makes lexing cleaner: strictly "5..5" should lex as "5." ".5" based on maximal munch ( http://en.wikipedia.org/wiki/Maximal_munch )
http://d.puremagic.com/issues/show_bug.cgi?id=1466
Jul 07 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 07 Jul 2009 20:20:18 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:
 
 Nick Sabalausky:
 why in the world is anyone defending the continued existance of "5."
 and ".5"?<
I'm for disallowing them; 5.0 ad 0.5 are better. Anyone else pro/against this idea?
I would not complain if trailing dot and leading dot were disallowed.
I think the question that should be asked is: would anyone complain if they were kept? We have bigger rocks to move than that one. Andrei
Why would this be hard to deal with, just say it isn't allowed in the spec and note that DMD does not conform. Is DMD really going to conform to the D2 spec upon release? Personally I use .5 in writing all the time, but never even considered it for coding and don't really like it.
Jul 07 2009
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 I would not complain if trailing dot and leading dot were disallowed.
I think the question that should be asked is: would anyone complain if they were kept? We have bigger rocks to move than that one.
It seems rather disingenuous to complain loudly about '...' used as a separator, but to accept leading/trailing dots without question. I'm sure you remember this list:
 0.....wyda
 0....wyda
 0... .wyda
 0. .. .wyda
 0.... wyda
 0. ...wyda
 0. ....wyda
 0.. .wyda
I'm sure you agree that this is a mess. Never mind if any of these token sequences are syntactically valid, this is a mess at the lexical level. If '0.....wyda' is interpreted as the token sequence '0. ... . wyda', then you have bigger things to worry about than whether or not that token sequence is ever syntactically valid. -- Rainer Deyke - rainerd eldwood.com
Jul 07 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Rainer Deyke wrote:
 Never mind if any of these
 token sequences are syntactically valid, this is a mess at the lexical
 level.  If '0.....wyda' is interpreted as the token sequence '0. ... .
 wyda', then you have bigger things to worry about than whether or not
 that token sequence is ever syntactically valid.
Back in the 80's, there was some n.g. discussion about what x++++y meant and how it was lexed and parsed. The best answer was: "Here a plus, there a plus, everywhere a plus plus."
Jul 07 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:
 Back in the 80's, there was some n.g. discussion about what x++++y meant
 and how it was lexed and parsed. The best answer was:
 
 "Here a plus, there a plus, everywhere a plus plus."
What I'd really like to see is a lexer that parses operators by rules rather than lists. If '+' is a token and '++' is a single token, then '+++' and '++++++++++' should also be recognized as tokens (which aren't used by the language). The only actual effect would be to would turn currently legal expressions like 'a+++++b' (and '5....a') into syntax errors. -- Rainer Deyke - rainerd eldwood.com
Jul 08 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 I would not complain if trailing dot and leading dot were disallowed.
I think the question that should be asked is: would anyone complain if they were kept? We have bigger rocks to move than that one.
It seems rather disingenuous to complain loudly about '...' used as a separator, but to accept leading/trailing dots without question.
Well it's rather congruent. The leading and trailing dots have been in the language for a good while and haven't caused major problems. So I am not bent on eliminating them. On the other hand, I don't feel like throwing ellipses in the mix just to make things more confusing.
 I'm
 sure you remember this list:
 
 0.....wyda
 0....wyda
 0... .wyda
 0. .. .wyda
 0.... wyda
 0. ...wyda
 0. ....wyda
 0.. .wyda
I'm sure you agree that this is a mess.
I do.
 Never mind if any of these
 token sequences are syntactically valid, this is a mess at the lexical
 level.
They all are parsable if ellipsis is to be allowed as separator. Not at all. They are very easy to parse lexically. It's the humans who have problems.
 If '0.....wyda' is interpreted as the token sequence '0. ... .
 wyda', then you have bigger things to worry about than whether or not
 that token sequence is ever syntactically valid.
What you describe is standard lexing. The sequence 0.....wyda is lexed using maximum munch (the longest thing that looks like a token is chosen left to right). First we have a 0 and so the longest token is 0. Then follow four dots, but a maximum of three form a token. Finally, we have .wyda which is a token. And that's about it. The rule is not complicated, but of course having to count the dots and exacerbating the importance of whitespace placement is undesirable. Andrei
Jul 07 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 7, 2009 at 8:08 PM, bearophile<bearophileHUGS lycos.com> wrote:
 Nick Sabalausky:
 why in the world is anyone defending the continued existance of "5." and ".5"?<
I'm for disallowing them; 5.0 ad 0.5 are better. Anyone else pro/against this idea?
Totally agree. They're cruft that just complicate lexical analysis.
 Regarding number literals, I'm also for:
 B) turning the current octal syntax into a syntax error and introducing a
safer octal syntax (see Python 3);
Or just drop octal altogether. Outside of chmod, when is there any legitimate need for it these days?
Jul 07 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 Totally agree.  They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is readily available.
 Or just drop octal altogether.  Outside of chmod, when is there any
 legitimate need for it these days?
Translating C code to D.
Jul 07 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 7, 2009 at 11:20 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 Totally agree. =A0They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is readily available.
I'm not going to argue this anymore.
 Or just drop octal altogether. =A0Outside of chmod, when is there any
 legitimate need for it these days?
Translating C code to D.
I don't see this as a reasonable justification. Octal isn't used that much in C either, and D is already so far from C that you need an automated tool to do it, so you might as well just have the tool translate them. The compiler could even disallow leading zeroes, giving you an error on any integer literals that weren't automatically translated.
Jul 07 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 11:20 PM, Walter
 Translating C code to D.
I don't see this as a reasonable justification. Octal isn't used that much in C either, and D is already so far from C that you need an automated tool to do it, so you might as well just have the tool translate them. The compiler could even disallow leading zeroes, giving you an error on any integer literals that weren't automatically translated.
I've translated code, and a tool isn't really necessary. But translating octal constants to hex like 077733 is very error prone. And yes, I ran into a bunch of them just recently in the OSX system header files. So they exist. I don't see a good reason to make things difficult to translate.
Jul 07 2009
parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 11:20 PM, Walter
 Translating C code to D.
I don't see this as a reasonable justification. Octal isn't used that much in C either, and D is already so far from C that you need an automated tool to do it, so you might as well just have the tool translate them. The compiler could even disallow leading zeroes, giving you an error on any integer literals that weren't automatically translated.
I've translated code, and a tool isn't really necessary. But translating octal constants to hex like 077733 is very error prone. And yes, I ran into a bunch of them just recently in the OSX system header files. So they exist. I don't see a good reason to make things difficult to translate.
Make a leading 0 illegal, and either: (1) change the octal syntax into 0c77733, or(better) (2) provide an octal conversion function in the standard library. Because of CTFE, so we can actually do (2) very nicely. I don't see any need for it to be a language feature when a library can do a better job.
Jul 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Make a leading 0 illegal,
I'm not sure what benefit that accomplishes.
 and either:
 (1) change the octal syntax into 0c77733,
 or(better) (2) provide an octal conversion function in the standard 
 library.
 
 Because of CTFE, so we can actually do (2) very nicely. I don't see any 
 need for it to be a language feature when a library can do a better job.
Jul 08 2009
parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Don wrote:
 Make a leading 0 illegal,
I'm not sure what benefit that accomplishes.
It catches occasional mistakes such as: int [] foo = [ 001 010 100 ]; which are admittedly very rare, though it actually happened to me earlier this year. It's quite baffling when it happens -- took me ages to track down. It's pretty similar to the way you made 'l' illegal as a integer suffix. int x = 0011l; Looks like x==111, but in C, x is 9!
Jul 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Walter Bright wrote:
 Don wrote:
 Make a leading 0 illegal,
I'm not sure what benefit that accomplishes.
It catches occasional mistakes such as: int [] foo = [ 001 010 100 ]; which are admittedly very rare, though it actually happened to me earlier this year. It's quite baffling when it happens -- took me ages to track down. It's pretty similar to the way you made 'l' illegal as a integer suffix. int x = 0011l; Looks like x==111, but in C, x is 9!
I see your point, but I'd like to add that it is rare enough that it has never happened to me in 30 years.
Jul 08 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:
 Don wrote:
 It catches occasional mistakes such as:
 int [] foo = [
   001
   010
   100
 ];
I see your point, but I'd like to add that it is rare enough that it has never happened to me in 30 years.
It has happened to me once or twice. I have never intentionally used an octal integer constant. -- Rainer Deyke - rainerd eldwood.com
Jul 08 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el  7 de julio a las 23:40 me escribiste:
 On Tue, Jul 7, 2009 at 11:20 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 Totally agree.  They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is readily available.
I'm not going to argue this anymore.
I will =) That's not a good enough reason. Having *one* front-end (lexer/parser/semantic analizer) is not good enough. D was supposed to make this easy to encourage different implementations. If the D specs are twisted and making a new lexer is... confusing, I think that's a failure. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- FALTAN 325 DIAS PARA LA PRIMAVERA -- Crónica TV
Jul 08 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 That's not a good enough reason. Having *one* front-end
 (lexer/parser/semantic analizer) is not good enough. D was supposed to
 make this easy to encourage different implementations. If the D specs are
 twisted and making a new lexer is... confusing, I think that's a failure.
It's 8 lines of code in the lexer to distinguish an octal literal from a non-octal one. I don't see a pressing case for disastrous complexity. Here they are: case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': state = STATE_octal; break; case '_': state = STATE_octal; p++; continue; D integer literals are identical to C ones, with the addition of _ and the elidation of trailing l. It's hard for me to see how this, which has been around 30 years in practice and 20 years as a standard, is an understandability problem in practice or specification.
Jul 08 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello Walter,

 Jarrett Billingsley wrote:
 
 Totally agree.  They're cruft that just complicate lexical analysis.
 
Not a significant issue, as the code to lex it is done, works, and is readily available.
But that assumes that just using the lexer is acceptable. What if someone needs to generate there own lexer? Say in a different language, like D?. Or they want to generate a token highlighter? Or what about if they need to make a tool in a shop that has a bad case of NIH? Or where they must /own/ the code for legal reasons.
Jul 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 Hello Walter,
 
 Jarrett Billingsley wrote:

 Totally agree.  They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is readily available.
But that assumes that just using the lexer is acceptable. What if someone needs to generate there own lexer? Say in a different language, like D?. Or they want to generate a token highlighter?
Oh please, it's trivial to translate.
 Or what about if 
 they need to make a tool in a shop that has a bad case of NIH? Or where 
 they must /own/ the code for legal reasons.
For a fee that would be less than what it would cost them to develop a simpler integer lexer, I'd license it to them under whatever terms they want. Sure, I've run into companies that would cheerfully blow through $30,000 of engineering time trying to duplicate what I'd license to them for $500, but NIH people are determined to immolate themselves anyway.
Jul 07 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Walter,

 BCS wrote:
 
 Hello Walter,
 
 Jarrett Billingsley wrote:
 
 Totally agree.  They're cruft that just complicate lexical
 analysis.
 
Not a significant issue, as the code to lex it is done, works, and is readily available.
But that assumes that just using the lexer is acceptable. What if someone needs to generate there own lexer? Say in a different language, like D?. Or they want to generate a token highlighter?
Oh please, it's trivial to translate.
Not to regex.
 Or what about if they need to make a tool in a shop that has a bad
 case of NIH? Or where they must /own/ the code for legal reasons.
 
For a fee that would be less than what it would cost them to develop a simpler integer lexer, I'd license it to them under whatever terms they want.
What would you sell it outright for? As in I would own it and have every right I would have if I was the original author.
Jul 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 What would you sell it outright for? As in I would own it and have every 
 right I would have if I was the original author.
As a non-exclusive license, probably $500. If you can develop it for less than that, then it wasn't really that hard <g>. For less than $500, it isn't even worth spending the time writing a contract.
Jul 07 2009
parent reply BCS <none anon.com> writes:
Hello Walter,

 BCS wrote:
 
 What would you sell it outright for? As in I would own it and have
 every right I would have if I was the original author.
 
As a non-exclusive license, probably $500.
Not a license, *own*. As in I *own* my hat. (ignoring the question of would you still own your copy) But that's really beside the point. I could come up with several somewhat reasonable reasons why "just use my code" isn't a good answer to having gotcha in the lexical spec. If you really want to go that way, then the lexical spec should officially BE the lexer source code.
Jul 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 BCS wrote:

 What would you sell it outright for? As in I would own it and have
 every right I would have if I was the original author.
As a non-exclusive license, probably $500.
Not a license, *own*. As in I *own* my hat. (ignoring the question of would you still own your copy)
You can't have two people own the same copyright. One owns the copyright, and the other has a non-exclusive license to do whatever he wants with it. The other has effective ownership, but it's done as a license. I'm not going to transfer the copyright, because then what am I going to put in the D compiler?
 But that's really beside the point. I could come up with several 
 somewhat reasonable reasons why "just use my code" isn't a good answer 
 to having gotcha in the lexical spec. If you really want to go that way, 
 then the lexical spec should officially BE the lexer source code.
I don't see where the "gotcha" is. It's not trivial, but it's specifiable, and the code implementing it is there and is correct.
Jul 07 2009
parent reply BCS <none anon.com> writes:
Hello Walter,

 BCS wrote:
 
 BCS wrote:
 
 What would you sell it outright for? As in I would own it and have
 every right I would have if I was the original author.
 
As a non-exclusive license, probably $500.
Not a license, *own*. As in I *own* my hat. (ignoring the question of would you still own your copy)
You can't have two people own the same copyright. One owns the copyright, and the other has a non-exclusive license to do whatever he wants with it. The other has effective ownership, but it's done as a license. I'm not going to transfer the copyright, because then what am I going to put in the D compiler?
I didn't expect you would even consider it and I can easely see some pointy haired boss refusing to allow licenced code into a product.
 But that's really beside the point. I could come up with several
 somewhat reasonable reasons why "just use my code" isn't a good
 answer to having gotcha in the lexical spec. If you really want to go
 that way, then the lexical spec should officially BE the lexer source
 code.
 
I don't see where the "gotcha" is. It's not trivial, but it's specifiable, and the code implementing it is there and is correct.
well for one thing the spec is wrong: http://d.puremagic.com/issues/show_bug.cgi?id=1466
Jul 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 I don't see where the "gotcha" is. It's not trivial, but it's
 specifiable, and the code implementing it is there and is correct.
well for one thing the spec is wrong: http://d.puremagic.com/issues/show_bug.cgi?id=1466
That issue has nothing to do with octal literals, and removing them will have no affect on it.
Jul 08 2009
parent reply BCS <none anon.com> writes:
Hello Walter,

 BCS wrote:
 
 I don't see where the "gotcha" is. It's not trivial, but it's
 specifiable, and the code implementing it is there and is correct.
 
well for one thing the spec is wrong: http://d.puremagic.com/issues/show_bug.cgi?id=1466
That issue has nothing to do with octal literals, and removing them will have no affect on it.
I think this strand of the thread (and what I was talking about) was not about octal but about complexity in the lexical design. That bugzilla issue was brought up as an issue and IS the first point that comes to my mind in that direction. disallowing leading or trailing decimal points would fix that issue and I for one would approve of it on that grounds as well as the the other advantages (it's harder to read wrong for one thing).
Jul 08 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 I think this strand of the thread (and what I was talking about) was not 
 about octal but about complexity in the lexical design. That bugzilla 
 issue was brought up as an issue and IS the first point that comes to my 
 mind in that direction. disallowing leading or trailing decimal points 
 would fix that issue and I for one would approve of it on that grounds 
 as well as the the other advantages (it's harder to read wrong for one 
 thing).
 
Don't use them if you don't like 'em. Since these are the same rules C and C++ have used for decades, and nobody seems to have a problem lexing them, I'm not sure it's a problem worth worrying about.
Jul 08 2009
prev sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Walter Bright wrote:
 BCS wrote:
 Hello Walter,

 Jarrett Billingsley wrote:

 Totally agree.  They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is readily available.
But that assumes that just using the lexer is acceptable. What if someone needs to generate there own lexer? Say in a different language, like D?. Or they want to generate a token highlighter?
Oh please, it's trivial to translate.
Been there. Trivial, but really obnoxious for this and a few other points. My ll(k) lexer grammar is ugly and hackish, and probably still buggy.
Jul 08 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 20:20:28 -0700, Walter Bright wrote:

 Or just drop octal altogether.  Outside of chmod, when is there any
 legitimate need for it these days?
Translating C code to D.
On Tue, 07 Jul 2009 20:29:40 -0700, Walter Bright wrote:
 Sometimes I run across someone else's code that does:
 
     for (i = 0; i <= 10; i++)
     {
 	... array[i] ...
     }
 
 and I'll always rewrite it as i<11, because the former confuses my brain 
 into creating bugs.
On Tue, 07 Jul 2009 21:06:11 -0700, Walter Bright wrote:
 I've translated code, and a tool isn't really necessary. But translating 
 octal constants to hex like 077733 is very error prone. And yes, I ran 
 into a bunch of them just recently in the OSX system header files. So 
 they exist. I don't see a good reason to make things difficult to translate.
So ... Octal literals are so common that we need compiler/language support. Character ranges are so rare that we do not need compiler/language support. Compatibility with C is paramount, except when it's not. Technical merit trumps human interface. I think that I'm not ready for the D programming language after all. I'll drop by the sandbox from time to time out of curiosity, I suppose. Good luck and thanks for all the fish. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 So ...
 Octal literals are so common that we need compiler/language support.
 Character ranges are so rare that we do not need compiler/language support.
 Compatibility with C is paramount, except when it's not.
 Technical merit trumps human interface.
If you're looking for absolutes in any useful engineering design, you won't find them. You might be interested in this paper: A. R. Koenig and B. Stroustrup: As Close as Possible to C - but no Closer. The C++ Report. Vol 1 No 7 July 1989. Also, AT&T C++ Translator Release Notes, February 1990.
 I think that I'm not ready for the D programming language after all. I'll
 drop by the sandbox from time to time out of curiosity, I suppose. Good
 luck and thanks for all the fish.
You'll be welcome back anytime you want!
Jul 07 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 So ...
... just in case you look over your shoulder:
 Octal literals are so common that we need compiler/language support.
We don't need, we have it.
 Character ranges are so rare that we do not need compiler/language support.
This is just immature. It's not that character ranges are rare; it's just that we can express them properly without some special mechanism.
 Compatibility with C is paramount, except when it's not.
You didn't understand. Compatibility with C is important in the sense that we want to have a clean-cut answer to a function rsa_encrypt() taken from C and pasted into D: either it compiles and runs with the same result, or it doesn't compile. That's the scenario. I don't understand how you make a case of duplicity out of this one.
 Technical merit trumps human interface.
Humans define technicality. To your question "Would any answer make a difference?" I retorted "Of course, as long as it has technical merit." Maybe that answer was misunderstood - I mean technical as opposed to the nontechnical arguments that had been put forth.
 I think that I'm not ready for the D programming language after all. I'll
 drop by the sandbox from time to time out of curiosity, I suppose. Good
 luck and thanks for all the fish.
Out of curiosity, which superior language are you careening towards? (I'd also be curious what "superdude" would answer to that. I recall he managed in the *same post* to state some utterly conflicting requirements for his would-be language, sort of like a woman who wants a guy who's "strong, you know, but also totally sensitive." Then superdude kind of implicitly concluded he has no idea where to go but left nonetheless with the tail up. How competent does one have to be to make even the last proud shot a misfire?) Anyhow... it would be a bummer if the negative atmosphere as of late in the group would cause people like you just lose interest. I can't understand what's going on. It starts looking like a disfunctional relationship: the more Walter and others do, the less content people on the group are. I don't care much for being pat on the back, but it's extremely disheartening to see that the more we do the more we're getting yelled at. What I guess I'll do is just lay low and wait for the negative ions to go away. Andrei
Jul 07 2009
next sibling parent reply grauzone <none example.net> writes:
 Compatibility with C is paramount, except when it's not.
You didn't understand. Compatibility with C is important in the sense that we want to have a clean-cut answer to a function rsa_encrypt() taken from C and pasted into D: either it compiles and runs with the same result, or it doesn't compile. That's the scenario. I don't understand how you make a case of duplicity out of this one.
Eh. You know, we have something like... what was it called? Link compatibility to C! Also, your paragraph about superdude shows that you just can't forgot about people who aren't as awesome as you and who attacked you in one way or another. Learn to be more like Walter, or you'll piss off even more people. I mean, you don't want that, and the community doesn't want that either.
Jul 08 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 Compatibility with C is paramount, except when it's not.
You didn't understand. Compatibility with C is important in the sense that we want to have a clean-cut answer to a function rsa_encrypt() taken from C and pasted into D: either it compiles and runs with the same result, or it doesn't compile. That's the scenario. I don't understand how you make a case of duplicity out of this one.
Eh. You know, we have something like... what was it called? Link compatibility to C! Also, your paragraph about superdude shows that you just can't forgot about people who aren't as awesome as you and who attacked you in one way or another. Learn to be more like Walter, or you'll piss off even more people. I mean, you don't want that, and the community doesn't want that either.
*cough* pot *cough* kettle *cough* black... :o) Andrei
Jul 08 2009
parent grauzone <none example.net> writes:
 *cough* pot *cough* kettle *cough* black... :o)
Are you alright?
Jul 08 2009
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Anyhow... it would be a bummer if the negative atmosphere as of late in 
 the group would cause people like you just lose interest. I can't 
 understand what's going on.
I think it would help if you weren't so condescending to people all the time. People don't like that much.
Jul 11 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:
 Andrei Alexandrescu wrote:
 Anyhow... it would be a bummer if the negative atmosphere as of late 
 in the group would cause people like you just lose interest. I can't 
 understand what's going on.
I think it would help if you weren't so condescending to people all the time. People don't like that much.
I understand. My perception is that negativity predates my being condescending, which roots from exasperation. For every annoying message of mine there are dozens patient messages making a similar point. But you're right, if a point is made the wrong way its correctness is not that relevant anymore. Andrei
Jul 11 2009
parent Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 Anyhow... it would be a bummer if the negative atmosphere as of late 
 in the group would cause people like you just lose interest. I can't 
 understand what's going on.
I think it would help if you weren't so condescending to people all the time. People don't like that much.
I understand. My perception is that negativity predates my being condescending, which roots from exasperation. For every annoying message of mine there are dozens patient messages making a similar point. But you're right, if a point is made the wrong way its correctness is not that relevant anymore.
I empathize. I enjoy issuing a sly and well-worded skewer just as much as the next guy. But, when those kinds of retorts are perceived as coming from the top down, they create resentment. Like it or not, you're "the man". :) --benji
Jul 12 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el  7 de julio a las 22:28 me escribiste:
 On Tue, Jul 7, 2009 at 8:08 PM, bearophile<bearophileHUGS lycos.com> wrote:
 Nick Sabalausky:
 why in the world is anyone defending the continued existance of "5."
 and ".5"?<
I'm for disallowing them; 5.0 ad 0.5 are better. Anyone else pro/against this idea?
Totally agree. They're cruft that just complicate lexical analysis.
Me Too! (TM)
 Regarding number literals, I'm also for:
 B) turning the current octal syntax into a syntax error and
 introducing a safer octal syntax (see Python 3);
Or just drop octal altogether. Outside of chmod, when is there any legitimate need for it these days?
I think being a system language, that alone is a good reason to keep some sort of octal notation. But well, maybe for these rare cases a nasty "compile-time string literal" can be used like chmod(path, oct!("664")); -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Hey you, standing in the aisles With itchy feet and fading smiles Can you feel me?
Jul 08 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Not a significant issue, as the code to lex it is done, works, and is 
 readily available.
It's not an issue for the compiler, but a modern programming language has to be designed for programmers, to be as little bug-prone as possible. Literals as .5 and 5. are not correct in my natural language, they look ugly, and they are a bit dangerous. That's why I think it's better to disallow them.
Translating C code to D.<
The main problem is turning a literal like 0555 into a syntax error, but failing silently or giving a different answer. Now in Python 3+ literals like 0720 are disallowed, you have to use 0o720 instead. I was one of the people that have suggested and voted for this change. It's one of the few changes in Python that come from a suggestion of mine. Regarding Python 3, it contains a single built-in module that's named 2to3, it's not too much long and it's quite useful: http://docs.python.org/library/2to3.html I think that writing a similar standard and built-in Python module to translate C/H code to D can be positive. Then all D distributions can contain it. Among the things it does it to reformat code and convert C octals to D octals :-) Bye, bearophile
Jul 08 2009
parent Don <nospam nospam.com> writes:
bearophile wrote:
 Walter Bright:
 Not a significant issue, as the code to lex it is done, works, and is 
 readily available.
It's not an issue for the compiler, but a modern programming language has to be designed for programmers, to be as little bug-prone as possible. Literals as .5 and 5. are not correct in my natural language, they look ugly, and they are a bit dangerous. That's why I think it's better to disallow them.
 Translating C code to D.<
The main problem is turning a literal like 0555 into a syntax error, but failing silently or giving a different answer.
 Now in Python 3+ literals like 0720 are disallowed, you have to use 0o720
instead. I was one of the people that have suggested and voted for this change.
It's one of the few changes in Python that come from a suggestion of mine.
 
 Regarding Python 3, it contains a single built-in module that's named 2to3,
it's not too much long and it's quite useful:
 http://docs.python.org/library/2to3.html
 I think that writing a similar standard and built-in Python module to
translate C/H code to D can be positive. Then all D distributions can contain
it. Among the things it does it to reformat code and convert C octals to D
octals :-)
 
 Bye,
 bearophile
Just make a CTFE function for converting an octal string to an int. T octalLiteral(T=int)(string s) { T r=0; foreach(c; s) { assert(c>='0' && c<='7', "Invalid character in octal literal"); r *= 8; r += (c-'0'); } return r; } static assert(octalLiteral("012")==012); static assert(octalLiteral("0716")==0716); static assert(octalLiteral!(long)("071625636464")==071625636464L); Why do we need language support for something which is so obscure and can be so trivially implemented in a library? (Note that it's only possible because of CTFE).
Jul 08 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

I can't understand what's going on. It starts looking like a disfunctional
relationship: the more Walter and others do, the less content people on the
group are. I don't care much for being pat on the back, but it's extremely
disheartening to see that the more we do the more we're getting yelled at. What
I guess I'll do is just lay low and wait for the negative ions to go away.<
The last release has a large number of bug fixes, and it contains nice things, like:
Use of with symbols that shadow local symbols is no longer allowed<
Warning on no return expr; is now an error.<
And after I have hasked for a smarter building process many times Walter has now done a first step in the right direction (other people have already found a way to improve this):
Bugzilla 3122: [patch] Adding support for fast and reliable build tools to the
frontend<
So this update was a lot of work, I think no one will deny this. Regarding what you say, people may look 'less content' partially because of the human nature: the more you have the more greedy you become and you want more. (Someone may be 'less content' because they understand they are not as good programmers as Walter, but I don't respect such people). But I think that's not the main problem. I think the main problems are (I may be wrong, so I may talk just for myself): - The syntax of the case range statements has not reached a consensus in the newsgroup, that means not enough people was agreeing with it. Yet, it's being implemented. - The new rules for integral conversion have being introduced with no public discussion first. People don't like that. (I have to test how such rules work in real programs before commenting about them again.) Eventually most people may appreciate this new feature anyway. I suggest to not implement something if 30% or more of people don't like it during the discussions. Even if you like the case range syntax, some people don't like it :-) And in the end keep in mind that lot of people criticize only the things they like and care of, and they just ignore the things they aren't interested of. So if they complain it means they appreciate D and the work done by Walter :-) Bye, bearophile
Jul 08 2009
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu Wrote:

 Anyhow... it would be a bummer if the negative atmosphere as of late in 
 the group would cause people like you just lose interest. I can't 
 understand what's going on. It starts looking like a disfunctional 
 relationship: the more Walter and others do, the less content people on 
 the group are. I don't care much for being pat on the back, but it's 
 extremely disheartening to see that the more we do the more we're 
 getting yelled at. What I guess I'll do is just lay low and wait for the 
 negative ions to go away.
 
 
 Andrei
 
oh please, who are you kidding? we all know that the problem ain't lies with Walter. this is all your doing with your negative and condescending attitude towards others in the NG. I'm sure I'm not the first to say that. Let's compare: Bartosz took upon himself the task of designing concurrency for D. For that he put forth a lot of effort to explain the design and the rational behind it, he also encouraged discussion of the subject in the NG and answered questions. You've re-implemented phobos from scratch, but in contrast, your phobos (however great and superior in design) is a one man job. you didn't involve the community in the process like Bartosz has done even though you know that a new API in the standard library has a huge impact on the community. especially irritating to me is the fact that after all the hard work Bartosz has put into designing and explaining his idea you simply canceled it with a two line post. Have you found flaws in his design? please explain to us simple humans so that we can share that understanding and provide a better design. Remember, There's a saying in business - "The customer is always right" and here the community of D programmers are those "customers" of the D language. No matter how stupid, annoying, ignorant or whatever they can be (I'm sure I fall under some of these categories) if you continue condescending them they *will* Personally, I already switched. I see no future in D as long as you keep torturing its community.
Jul 11 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:
 Let's compare: 
 Bartosz took upon himself the task of designing concurrency for D. For that he
put forth a lot of effort to explain the design and the rational behind it, he
also encouraged discussion of the subject in the NG and answered questions.
 You've re-implemented phobos from scratch, but in contrast, your phobos
(however great and superior in design) is a one man job. you didn't involve the
community in the process like Bartosz has done even though you know that a new
API in the standard library has a huge impact on the community. 
The new phobos is mostly based on ranges, which have been thoroughly discussed in this group before being implemented. I have often discussed dilemmas I've had and am still having (such choosing between value containers and reference containers) in this group. Ideas and code submitted by others have been integrated into Phobos with credit, most recently Shin Fujishiro's code for printing and parsing enums as symbols which has been added to std.conv (and Shiro has been added to the list of module authors). I'm still working on integrating Shin's code for BlackHole and WhiteHole, which is awesome but very involved. By the way, it seems that Walter hasn't regenerated the documentation when releasing 2.031, for example search this page for "enum" http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/conv.d vs. this page: http://www.digitalmars.com/d/2.0/phobos/std_conv.html
 especially irritating to me is the fact that after all the hard work Bartosz
has put into designing and explaining his idea you simply canceled it with a
two line post. Have you found flaws in his design? please explain to us simple
humans so that we can share that understanding and provide a better design.
This group has discussed Bartosz's design only a little. I've discussed a lot more with Bartosz and others. My issue with his design can be resumed to one point. The design helps with only one style of concurrent programming. That particular style is IMHO becoming obsolete and should not be the focus of a major language addition. Anyway, you are ascribing way too much influence of my opinion: Walter makes the decision, and Bartosz communicates with him as much as I do.
 Remember, There's a saying in business - "The customer is always right" and
here the community of D programmers are those "customers" of the D language. No
matter how stupid, annoying, ignorant or whatever they can be (I'm sure I fall
under some of these categories) if you continue condescending them they *will*

You're right, thanks for sharing that.
 Personally, I already switched. I see no future in D as long as you keep
torturing its community. 
Now, torture is illegal isn't it :o). Andrei
Jul 11 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 By the way, it seems that Walter hasn't regenerated the documentation 
 when releasing 2.031, for example search this page for "enum"
 
 http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/conv.d
 
 vs. this page:
 
 http://www.digitalmars.com/d/2.0/phobos/std_conv.html
The online docs have been corrected now. They are correct in the zip file, I had just failed to upload the html. The fault is entirely mine, not Andrei's.
Jul 11 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h30845$2kla$2 digitalmars.com...
 bearophile wrote:
 Walter Bright Wrote:
 I like:
     a .. b+1
 to mean inclusive range.
Me too, but does it work when the upper interval is int.max, char.max, ulong.max, ucent.max, etc?
Nope. Wrap around is always a special case, not just for ranges. It's in the nature of 2's complement arithmetic.
Suppose, hypothetically, that we did have a "right-inclusive-range" token. 'poopiesOnAFlyingStick', whatever. Now, as has been pointed out far to many times by now to still not get: a .. int.max+1 // wraparound breaks it a right_inclusive_range_tok int.max // works fine, wraparound isn't even relevant.
Writing an inclusive e.g. loop that goes all the way to the largest integers is tricky no matter what. So this is not a problem with open ranges. Open ranges are there for a good reason.
 And another problem people have already pointed out numerous times with 
 making "a .. b+1" the inclusive range syntax:
 
 double a=1, b=5;
 // Let's make an inclusive range from 1.0 to 5.0!
 a .. b+1
 // Oh look! 5.5f is in the range! It didn't f*^* work!
b+1 is correct if the range is iterated by 1, as in foreach or as an array index. That's what Walter meant because that's what's in the language. If you want to define a floating-point range that is closed to the right, you may want to use an open range from a to nextUp(b). The nextUp function (defined in std.math by Don I think) returns the very next floating point value. That's exactly what I do in std.random.
 And yet another:
 float a=1, b=somethingReallyLarge;
 assert(b+1 == b);
 // Let's make an inclusive range!
 a .. b+1
 // Oh look! b is missing from the range! It didn't f*^* work again!
This is not a problem with ranges. It's an issue inherent to floating-point arithmetic.
 "a .. b+1" as *the* inclusive range is just plain broken. There is no "Yea, 
 but...!" that can change that.
Yeah, but nextUp.
 And while I'm ranting, why in the world is anyone defending the continued 
 existance of "5." and ".5"? "Because it's already there and it basically 
 still works and isn't hurting anyone." Well it seems to be hurting the 
 adoption of an inclusive range that actually works. I thougt the point of D 
 was to clean up useless cruft like that, even if it still works (header 
 files) to make way for better approaches.
There is no need for a right-closed range in the language. It can be defined with ease as a library, although I'm not finding myself in need of one. Andrei
Jul 07 2009
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 19:29:21 -0500, Andrei Alexandrescu wrote:

 There is no need for a right-closed range in the language. It can be 
 defined with ease as a library, although I'm not finding myself in need 
 of one.
Process all the characters from 'a' to 'z' inclusive. Currently, ('a' .. 'z'+1) Logically, ('a' .. 'z') -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Tue, 07 Jul 2009 19:29:21 -0500, Andrei Alexandrescu wrote:
 
 There is no need for a right-closed range in the language. It can be 
 defined with ease as a library, although I'm not finding myself in need 
 of one.
Process all the characters from 'a' to 'z' inclusive. Currently, ('a' .. 'z'+1) Logically, ('a' .. 'z')
Do we need a language feature for that? Andrei
Jul 07 2009
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 19:42:00 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Tue, 07 Jul 2009 19:29:21 -0500, Andrei Alexandrescu wrote:
 
 There is no need for a right-closed range in the language. It can be 
 defined with ease as a library, although I'm not finding myself in need 
 of one.
Process all the characters from 'a' to 'z' inclusive. Currently, ('a' .. 'z'+1) Logically, ('a' .. 'z')
Do we need a language feature for that?
Would any answer make a difference? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Tue, 07 Jul 2009 19:42:00 -0500, Andrei Alexandrescu wrote:
 
 Derek Parnell wrote:
 On Tue, 07 Jul 2009 19:29:21 -0500, Andrei Alexandrescu wrote:

 There is no need for a right-closed range in the language. It can be 
 defined with ease as a library, although I'm not finding myself in need 
 of one.
Process all the characters from 'a' to 'z' inclusive. Currently, ('a' .. 'z'+1) Logically, ('a' .. 'z')
Do we need a language feature for that?
Would any answer make a difference?
Of course, as long as it has technical merit. Andrei
Jul 07 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Tue, 07 Jul 2009 19:42:00 -0500, Andrei Alexandrescu wrote:
 
 Derek Parnell wrote:
 On Tue, 07 Jul 2009 19:29:21 -0500, Andrei Alexandrescu wrote:

 There is no need for a right-closed range in the language. It can be 
 defined with ease as a library, although I'm not finding myself in need 
 of one.
Process all the characters from 'a' to 'z' inclusive. Currently, ('a' .. 'z'+1) Logically, ('a' .. 'z')
Do we need a language feature for that?
Would any answer make a difference?
Of course, as long as it has technical merit. Andrei
Jul 07 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-07 20:42:00 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Process all the characters from 'a' to 'z' inclusive.
 
 Currently, ('a' .. 'z'+1)
 
 Logically, ('a' .. 'z')
Do we need a language feature for that?
The two reasons in favor of a language feature are: 1. It might be more readable. 2. It allows ranges to include the *.max value. The first is obviously just a cosmetic issue, which I don't think is worth it on its own. The second makes it easier to work with an edge case, which I don't think is worth it on its own either. Solving both together is a little more worth it, but enought to warant a language feature, I have some doubths. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 07 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 Solving both 
 together is a little more worth it, but enought to warant a language 
 feature, I have some doubths.
I'm fairly convinced it is not worth a language feature. It looks good in the abstract, but is useless in practice. I write loops every day, and I can't recall ever having a need for it. Sometimes I run across someone else's code that does: for (i = 0; i <= 10; i++) { ... array[i] ... } and I'll always rewrite it as i<11, because the former confuses my brain into creating bugs. D has a lot of features. We should be parsimonious with new ones in that they should offer a convincing big payoff, not merely a miniscule hypothetical one.
Jul 07 2009
prev sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Andrei Alexandrescu wrote:
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message=20
 news:h30845$2kla$2 digitalmars.com...
 bearophile wrote:
 Walter Bright Wrote:
 I like:
     a .. b+1
 to mean inclusive range.
Me too, but does it work when the upper interval is int.max,=20 char.max, ulong.max, ucent.max, etc?
Nope. Wrap around is always a special case, not just for ranges. It's=
=20
 in the nature of 2's complement arithmetic.
Suppose, hypothetically, that we did have a "right-inclusive-range"=20 token. At the moment I don't give a rat's ass what it actually is,=20 pointed out far to many times by now to still not get: a .. int.max+1 // wraparound breaks it a right_inclusive_range_tok int.max // works fine, wraparound isn't=
=20
 even relevant.
=20 Writing an inclusive e.g. loop that goes all the way to the largest=20 integers is tricky no matter what. So this is not a problem with open=20 ranges. Open ranges are there for a good reason. =20
 And another problem people have already pointed out numerous times=20
 with making "a .. b+1" the inclusive range syntax:

 double a=3D1, b=3D5;
 // Let's make an inclusive range from 1.0 to 5.0!
 a .. b+1
 // Oh look! 5.5f is in the range! It didn't f*^* work!
=20 b+1 is correct if the range is iterated by 1, as in foreach or as an=20 array index. That's what Walter meant because that's what's in the=20 language. If you want to define a floating-point range that is closed t=
o=20
 the right, you may want to use an open range from a to nextUp(b). The=20
 nextUp function (defined in std.math by Don I think) returns the very=20
 next floating point value. That's exactly what I do in std.random.
=20
So, the correct way to define an inclusive range is with "+1"=20 except when it's with "nextUp", unless you're talking about the=20 right end of the range where it is inclusive by default and the=20 right way to make it exclusive is with "+1" except when it's with=20 "nextUp"? That's what I call consistent! Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 08 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jérôme M. Berger wrote:
     So, the correct way to define an inclusive range is with "+1" except 
 when it's with "nextUp", unless you're talking about the right end of 
 the range where it is inclusive by default and the right way to make it 
 exclusive is with "+1" except when it's with "nextUp"?
 
     That's what I call consistent!
I completely disagree with your assessment. First, you didn't mention what the range is supposed to do. For example, what primitives should the range have? Are you talking about a built-in type or a library-defined type? etc. There are two places in the language where expression1..expression2 comes into play: when slicing an array, and when iterating with foreach. In both cases the range is discrete with step 1, and so it makes sense to discuss that when expression1..expression2 is being talked about. Now you can't just silently redefine what you mean by range and then claim inconsistency. If you want to make a case, please state clearly what are you talking about. Nobody can be consistent with a definition that doesn't exist. Andrei
Jul 08 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Jul 8, 2009 at 4:12 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 J=E9r=F4me M. Berger wrote:
 =A0 =A0So, the correct way to define an inclusive range is with "+1" exc=
ept
 when it's with "nextUp", unless you're talking about the right end of th=
e
 range where it is inclusive by default and the right way to make it
 exclusive is with "+1" except when it's with "nextUp"?

 =A0 =A0That's what I call consistent!
I completely disagree with your assessment. First, you didn't mention what the range is supposed to do. For example, what primitives should the range have? Are you talking about a built-in type or a library-defined type? etc. There are two places in the language where expression1..expression2 comes into play: when slicing an array, and when iterating with foreach. In both cases the range is discrete with step 1, and so it makes sense to discuss that when expression1..expression2 is being talked about. Now you can't just silently redefine what you mean by range and then claim inconsistency. If you want to make a case, please state clearly what are you talking about. Nobody can be consistent with a definition that doesn't exist.
I think what Jerome is getting at is that we could be getting more mileage out of the xpr1..xpr2 syntax. It would be useful syntax for more than just integral, dense ranges in foreach and slices. The equivalents I've used or seen in Ruby, Python and Matlab are more versatile than D's. Perhaps that can't be translated in any useful way to a static language like D, I dunno. But it leaves one with the feeling that D's slice literals are underpowered and that the case range thing is just plugging a hole in a dilapidated boat rather than building us a nice new sleek yacht. --bb
Jul 08 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I think what Jerome is getting at is that we could be getting more
 mileage out of the xpr1..xpr2 syntax.  It would be useful syntax for
 more than just integral, dense ranges in foreach and slices.  The
 equivalents I've used or seen in Ruby, Python and Matlab are more
 versatile than D's.  Perhaps that can't be translated in any useful
 way to a static language like D, I dunno.  But it leaves one with the
 feeling that D's slice literals are underpowered and that the case
 range thing is just plugging a hole in a dilapidated boat rather than
 building us a nice new sleek yacht.
How are python's so much better? 1. python's ranges are exclusive of the endpoint 2. python doesn't have a switch statement, so case ranges being better in python makes no sense
Jul 08 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Jul 8, 2009 at 8:26 PM, Walter Bright<newshound1 digitalmars.com> w=
rote:
 Bill Baxter wrote:
 I think what Jerome is getting at is that we could be getting more
 mileage out of the xpr1..xpr2 syntax. =A0It would be useful syntax for
 more than just integral, dense ranges in foreach and slices. =A0The
 equivalents I've used or seen in Ruby, Python and Matlab are more
 versatile than D's. =A0Perhaps that can't be translated in any useful
 way to a static language like D, I dunno. =A0But it leaves one with the
 feeling that D's slice literals are underpowered and that the case
 range thing is just plugging a hole in a dilapidated boat rather than
 building us a nice new sleek yacht.
How are python's so much better? 1. python's ranges are exclusive of the endpoint 2. python doesn't have a switch statement, so case ranges being better in python makes no sense
Not every one of those has every feature you could imagine. But nice things about Python's slices include: * optional step size, * step size can be negative. * nice compact notation * And the a:b syntax maps to a slice object so that you can manipulate them and pass them around. Ruby is the only one I mentioned that has both inclusive and exclusive ranges (using two dots for inclusive, three dots for exclusive). Matlab's are always inclusive. But they all have an optional step size. Python's are a little annoying in that, like D, you can't use them outside of indexing expressions. Can't even use them in loops. In NumPy, the numerical library for Python, they've invented some quirky objects like numpy.r_ which you index to create a range literal. Like >>> numpy.r_[0:4:0.5] array([ 0. , 0.5, 1. , 1.5, 2. , 2.5, 3. , 3.5]) You could do the same in D, but I don't think anyone in NumPy thinks of it as a particularly elegant way to make ranges (compared to matlab where just plain 0:4:0.5 gets you the same thing). Also you'd most often like to have that 4.0 in there, so you have to tweak the range to be [0:4.5:0.5] to get that inclusivity, because python doesn't have inclusive ranges. Not ideal. So they also have Anyway, you seem pretty satisfied with what you've got, so don't mind me. You've got to draw the line somewhere. --bb
Jul 09 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 Python's are a little annoying in that, like D, you can't use
 them outside of indexing expressions.  Can't even use them in loops.
 In NumPy, the numerical library for Python, they've invented some
 quirky objects like numpy.r_ which you index to create a range
 literal.  Like
   >>>   numpy.r_[0:4:0.5]
   array([ 0. ,  0.5,  1. ,  1.5,  2. ,  2.5,  3. ,  3.5])
 You could do the same in D, but I don't think anyone in NumPy thinks
 of it as a particularly elegant way to make ranges (compared to matlab
 where just plain 0:4:0.5 gets you the same thing).  Also you'd most
 often like to have that 4.0 in there, so you have to tweak the range
 to be [0:4.5:0.5] to get that inclusivity, because python doesn't have
 inclusive ranges.  Not ideal.  So they also have
For other people here:
 class C(object):
... def __getitem__(self, key): return key ...

 c[10]
10
 c[10:20]
slice(10, 20, None)
 c[10:20:30]
slice(10, 20, 30)
 c[...]
Ellipsis So inside __getitem__ (that's like opIndex) the key is turned into a slice object, or even into a built-in Ellipsis object :-) Bye, bearophile
Jul 09 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Wed, Jul 8, 2009 at 8:26 PM, Walter Bright<newshound1 digitalmars.com>
wrote:
 Bill Baxter wrote:
 I think what Jerome is getting at is that we could be getting more
 mileage out of the xpr1..xpr2 syntax.  It would be useful syntax for
 more than just integral, dense ranges in foreach and slices.  The
 equivalents I've used or seen in Ruby, Python and Matlab are more
 versatile than D's.  Perhaps that can't be translated in any useful
 way to a static language like D, I dunno.  But it leaves one with the
 feeling that D's slice literals are underpowered and that the case
 range thing is just plugging a hole in a dilapidated boat rather than
 building us a nice new sleek yacht.
How are python's so much better? 1. python's ranges are exclusive of the endpoint 2. python doesn't have a switch statement, so case ranges being better in python makes no sense
Not every one of those has every feature you could imagine. But nice things about Python's slices include: * optional step size, * step size can be negative. * nice compact notation * And the a:b syntax maps to a slice object so that you can manipulate them and pass them around. Ruby is the only one I mentioned that has both inclusive and exclusive ranges (using two dots for inclusive, three dots for exclusive). Matlab's are always inclusive. But they all have an optional step size. Python's are a little annoying in that, like D, you can't use them outside of indexing expressions. Can't even use them in loops. In NumPy, the numerical library for Python, they've invented some quirky objects like numpy.r_ which you index to create a range literal. Like >>> numpy.r_[0:4:0.5] array([ 0. , 0.5, 1. , 1.5, 2. , 2.5, 3. , 3.5]) You could do the same in D, but I don't think anyone in NumPy thinks of it as a particularly elegant way to make ranges (compared to matlab where just plain 0:4:0.5 gets you the same thing). Also you'd most often like to have that 4.0 in there, so you have to tweak the range to be [0:4.5:0.5] to get that inclusivity, because python doesn't have inclusive ranges. Not ideal. So they also have Anyway, you seem pretty satisfied with what you've got, so don't mind me. You've got to draw the line somewhere.
Nevertheless, I think these all are great ideas for additions to std.range. Andrei
Jul 09 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Not every one of those has every feature you could imagine.  But nice
 things about Python's slices include:
 * optional step size,
 * step size can be negative.
 * nice compact notation
 * And the a:b syntax maps to a slice object so that you can manipulate
 them and pass them around.
Having a step size requires, of course, a third operand. This doesn't work too well with infix operator notation (the only 3 operand infix operator is ?:). Having such a third operand, however, should mesh quite well with Andrei's range library construct.
Jul 09 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Having such a third operand, however, should mesh quite well with 
 Andrei's range library construct.
In normal usage slices are sometimes useful, but slicing is mostly useful when you work with rectangular matrices, so you can slice and dice them in many ways, across axes, etc. NumPy and Matlab show such usages well. Such operations can probably be done well enough by a refined D matrix library designed for "heavy" numerical processing. An option is to not change the current design of slices, keeping them simple, with no stride. I can accept this. (One thing I don't like much of it is that "out of bound" slices are an hazard, you can't slice past the real size of an array. Time ago I have shown here that Python is safer in such regard, and performs something similar to: slice(a,b) === slice(max(0, min(a, $)), max(0, min(b, $))). This is quite handy (and later I have asked to Python designers, it's not a wart, it's the way they have wanted it), but it's also slower at run-time, so the current less handy behavior of D slices may be acceptable). It's also possible to replace the current a..b syntax with something like a..b:c or a:b:c or a..b..c, etc. This is a bit more elastic than the current semantics, but not much. Even if I have asked for it in the past, I don't feel so much need for it. There are other more important features I now like to have. If D wants to appeal to programmers that have to write numerical computations (and I think this may become one of the purposes of the D language, this means to replace some of the programs today done with Fortran and Matlab), then it may add a more general scaffold, that probably later will be used by a numeric processing library. The Chapel language is designed for such numerical computations, among other things it has Domains, they are "index spaces". You can define arithmetic Domains, that are just one or more arithmetic ranges, open and closed, with stride (so they define an n dimensional arithmetic range, for example [0..10, 0..10] defines the space of the indexes of a 2D matrix 10x10). It allows to slice domains, to create sub-domains, un-ordered domains, associative domains and more. Then you can use them to iterate on, to initialize arrays, matrices or associative arrays defined on such Domain of indexes. It may sound complex, but I've seen it's easy to use, you can write Chapel code that uses such things only after reading about them for 20-40 minutes. Such abstraction of the idea of index space gives safety (most loops become foreach, no many out of bound situations anymore, this also means more performance because the compiler can avoid many run-time array bound checks), possibilities for the compiler to optimize and/or parallelize their usage, etc. Bye, bearophile
Jul 09 2009
prev sibling parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:

 Having a step size requires, of course, a third operand. This doesn't
 work too well with infix operator notation (the only 3 operand infix
 operator is ?:).
 
 Having such a third operand, however, should mesh quite well with
 Andrei's range library construct.
In the programming language I'm currently designing, .. is overloaded twice to get the desired effect. ---------------------------------------- Interval interval(int a, int b) { result.lower <- a; result.upper <- b; } Interval interval(Interval a, int b) { result <- a; result.stride <- b; } for (i, 1..10..-1) { // i = 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 } ---------------------------------------- (Clarification: 'interval' is the function name used to overload the .. operator. <- is the assignment operator. 'result' is automatically declared and returned.) You see, .. can remain a binary operator. Perhaps something like this can work for D. -- Michiel Helvensteijn
Jul 10 2009
prev sibling parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Bill Baxter wrote:
 On Wed, Jul 8, 2009 at 4:12 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 J=E9r=F4me M. Berger wrote:
    So, the correct way to define an inclusive range is with "+1" exce=
pt
 when it's with "nextUp", unless you're talking about the right end of=
the
 range where it is inclusive by default and the right way to make it
 exclusive is with "+1" except when it's with "nextUp"?

    That's what I call consistent!
I completely disagree with your assessment. First, you didn't mention what the range is supposed to do. For example, what primitives should the range have? Are you talking about a built-in type or a library-defined type? etc. There are two places in the language where expression1..expression2 comes into play: when slicing an array, and when iterating with foreac=
h.
 In both cases the range is discrete with step 1, and so it makes sense=
 to discuss that when expression1..expression2 is being talked about. N=
ow
 you can't just silently redefine what you mean by range and then claim=
 inconsistency.

 If you want to make a case, please state clearly what are you talking
 about. Nobody can be consistent with a definition that doesn't exist.
=20 I think what Jerome is getting at is that we could be getting more mileage out of the xpr1..xpr2 syntax. It would be useful syntax for more than just integral, dense ranges in foreach and slices. The equivalents I've used or seen in Ruby, Python and Matlab are more versatile than D's. Perhaps that can't be translated in any useful way to a static language like D, I dunno. But it leaves one with the feeling that D's slice literals are underpowered and that the case range thing is just plugging a hole in a dilapidated boat rather than building us a nice new sleek yacht. =20
Exactly. Especially when I seem to remember several discussions=20 where Walter and Andrei talked about giving D a more mathematics and=20 scientific orientation (might be confusing with someone else though). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 09 2009
prev sibling parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Andrei Alexandrescu wrote:
 J=E9r=F4me M. Berger wrote:
     So, the correct way to define an inclusive range is with "+1"=20
 except when it's with "nextUp", unless you're talking about the right =
 end of the range where it is inclusive by default and the right way to=
=20
 make it exclusive is with "+1" except when it's with "nextUp"?

     That's what I call consistent!
=20 I completely disagree with your assessment. First, you didn't mention what the range is supposed to do. For example, what primitives should the range have? Are you talking about a built-in type or a library-defined type? etc. =20 There are two places in the language where expression1..expression2 comes into play: when slicing an array, and when iterating with foreach=
=2E
 In both cases the range is discrete with step 1, and so it makes sense
 to discuss that when expression1..expression2 is being talked about. No=
w
 you can't just silently redefine what you mean by range and then claim
 inconsistency.
=20
 If you want to make a case, please state clearly what are you talking
 about. Nobody can be consistent with a definition that doesn't exist.
=20
Please don't remove relevant quotations from my message. *You* were=20 the one who said:
 b+1 is correct if the range is iterated by 1, as in foreach or as an
 array index. That's what Walter meant because that's what's in the
 language. If you want to define a floating-point range that is=20
closed to
 the right, you may want to use an open range from a to nextUp(b). The
 nextUp function (defined in std.math by Don I think) returns the very
 next floating point value. That's exactly what I do in std.random.
--=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 09 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 10:50:08 -0700, Walter Bright wrote:

 I like:
 
     a .. b+1
 
 to mean inclusive range.
LOL, now that *is* funny. And I like the Euphoria language's version ... case X to Y but so what, eh? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 8 Jul 2009 07:48:07 +1000, Derek Parnell wrote:

 On Tue, 07 Jul 2009 10:50:08 -0700, Walter Bright wrote:
 
 I like:
 
     a .. b+1
 
 to mean inclusive range.
LOL, now that *is* funny. And I like the Euphoria language's version ... case X to Y but so what, eh?
OMG! ... having read the rest of the posts I see that you were serious. Sorry, didn't mean to show disrespect; I really thought it was a joke. Are you honestly suggesting that the sequence of Expression ".." Expression "+1" be recognized by the tokenizer as meaning Inclusive-End-Range? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 08 Jul 2009 08:37:49 +1000, Derek Parnell wrote:

 
 Are you honestly suggesting that the sequence of
 
   Expression ".." Expression "+1"
 
 be recognized by the tokenizer as meaning Inclusive-End-Range?
I'm pretty sure he just meant for his brain. I happen to agree. I generally like the mathematical [1,7) syntax, but I think I'd have a hard time reading that in code. Then again, there was mention of needing int.max+1 to be a special case.
Jul 07 2009
prev sibling parent reply =?ISO-8859-1?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
Leandro Lucarella Wrote:

 Can you at least use:
 case X:
 ..
 case Y:
 
 in the examples/documentation/specs? I think most case X: .. case Y:
 haters found that format pretty acceptable
I like that syntax too, but not a good idea to use in the Digital Mars code samples, because another one with an extra dot is already being used to mean "omitted lines of code": case X: ... case Y: Ali
Jul 07 2009
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 07 Jul 2009 17:17:48 -0400, Ali Çehreli wrote:

 Leandro Lucarella Wrote:
 
 Can you at least use:
 case X:
 ..
 case Y:
 
 in the examples/documentation/specs? I think most case X: .. case Y:
 haters found that format pretty acceptable
I like that syntax too, but not a good idea to use in the Digital Mars code samples, because another one with an extra dot is already being used to mean "omitted lines of code": case X: ... case Y: Ali
:D That just gives reason not to use ... for a separator. I love it. I can definitely see this as a misguided step for a new user. "A case range can be used like: switch (i) { case 1: .. case 3: x = 4; break; }" And the resulting code by the new user: switch (i) { case 1: case 2: case 3: x = 4; break; }
Jul 07 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 I think the ... operator makes perfect sense because it's more general,
 yo could use array[X...Y] and case X..Y: where appropriate.
and
 doesn't look so bad though, but I think it could be easy to miss the ".."
 when reviewing the code
If it's easy to miss .., then it ought to be really easy to miss the distinction between .. and ... !
Jul 07 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  7 de julio a las 10:46 me escribiste:
 Leandro Lucarella wrote:
I think the ... operator makes perfect sense because it's more general,
yo could use array[X...Y] and case X..Y: where appropriate.
and
doesn't look so bad though, but I think it could be easy to miss the ".."
when reviewing the code
If it's easy to miss .., then it ought to be really easy to miss the distinction between .. and ... !
As another people said, use another way to write inclusive range, but keep things consistent =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- UNA ARTISTA HACE JABONES CON SU PROPIA GRASA LUEGO DE UNA LIPOSUCCION -- Crónica TV
Jul 07 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
And heeeeere we go again!

*sigh*

 switch( foo )
 {
     case 0:
     ..
     case 5:
         blah();
         break;

     default:
         bork();
 }
Doesn't look so bad, does it? For the record, I think the current syntax is ugly. But: * it WORKS, * it is reasonably distinct from all the other uses of ".." which have a DIFFERENT MEANING, * it has an easily-explained rationale: "the .. stands in for the case labels you would have written." Can we please, please stop the useless bike-shedding on this NG? Yes, it's a bit ugly, but all the alternatives proposed have SEMANTIC issues with them, which is much worse.
Jul 06 2009
next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Daniel Keep wrote:
would have written."
 
 Can we please, please stop the useless bike-shedding on this NG?
Rather than sift through replies to a release announcement (which I have done since first post and still have an answer) it deserves its own subject. The release announcement already has: switch case range limits case fall through unsigned signed conversion build deps bugs others and plain old thanks for release Sorry I must be really dumb for not understanding that subjects are a bad thing.
 all the alternatives proposed have SEMANTIC issues
 with them, which is much worse.
Currently we can: import foo.bar; or char[] fileData = cast(char[])import("file.txt"); Whats the semantic issues with this: case 1: case 2: case 3: replaced with case (1,3):
Jul 06 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Tim Matthews wrote:
 Daniel Keep wrote:
 would have written."
 Can we please, please stop the useless bike-shedding on this NG?
Rather than sift through replies to a release announcement (which I have done since first post and still have an answer) it deserves its own subject. The release announcement already has: switch case range limits case fall through unsigned signed conversion build deps bugs others and plain old thanks for release Sorry I must be really dumb for not understanding that subjects are a bad thing.
It's not that making a thread about a particular feature is bad. This *specific* feature has been discussed previously. The whole "this is ugly, why not X" has been done to death, with Walter and Andrei having already given the reasons for choosing this syntax. I don't especially like `case a: .. case b:` aesthetically, either. But I also haven't seen any workable alternatives, and it's not as bad as some people seem to think it is. This community has a horrible tendency to become focused on bike-shed issues and I really, really don't want to see this particular one start up all over again.
 all the alternatives proposed have SEMANTIC issues
 with them, which is much worse.
Currently we can: import foo.bar; or char[] fileData = cast(char[])import("file.txt");
How is this relevant? If you're arguing that D already re-uses syntax in places to mean slightly different things, that's because D isn't perfect and its primary developer is a pragmatist. If you're arguing that we have a keyword whose meaning changes based on the presence or absence of parentheses, I'd point out that the first form is semantically invalid if you add parentheses, whilst the second is semantically invalid if you remove them. Which brings me to...
 Whats the semantic issues with this:
 
 case 1:
 case 2:
 case 3:
 
 replaced with
 
 case (1,3):
(1,3) is already a valid expression. It evaluates to 3. This would introduce code which is valid in C and in D1, but which invisibly changes meaning in D2; something Walter is very, very against. To pre-empt the rest of this argument: [1,3] is also a valid expression. [1..3] already has a meaning in a different part of the syntax. (1..3) and 1..3 don't have any meaning but look like [1..3] which is an EXCLUSIVE range, not an INCLUSIVE range like a case range is. [1...3] looks like a typo of [1..3], as does 1...3 and (1...3). case 1 .. case 3: would probably work but at that point you're arguing to remove a single colon which is just petty.
Jul 07 2009
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:h2usvm$e9r$1 digitalmars.com...
 This community has a horrible tendency to become focused on bike-shed
 issues and I really, really don't want to see this particular one start
 up all over again.
If you have a problem with bikeshed discussions, wouldn't it make more sense not to participate in them instead of continually whining about them?
Jul 07 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tim Matthews wrote:
 Daniel Keep wrote:
 would have written."
 Can we please, please stop the useless bike-shedding on this NG?
Rather than sift through replies to a release announcement (which I have done since first post and still have an answer) it deserves its own subject. The release announcement already has: switch case range limits case fall through unsigned signed conversion build deps bugs others and plain old thanks for release Sorry I must be really dumb for not understanding that subjects are a bad thing.
 all the alternatives proposed have SEMANTIC issues
 with them, which is much worse.
Currently we can: import foo.bar; or char[] fileData = cast(char[])import("file.txt");
Existing actual or perceived inconsistencies are not an argument for adding more of them.
 Whats the semantic issues with this:
 
 case 1:
 case 2:
 case 3:
 
 replaced with
 
 case (1,3):
a) It is not arguably better and more suggestive than the syntax in place. b) "(1,3)" already means two things, neither of which has anything to do with "I want to write case labels from 1 through 3 here". Andrei
Jul 07 2009
parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Andrei Alexandrescu wrote:
 
 Existing actual or perceived inconsistencies are not an argument for 
 adding more of them.
 
Seriously?
 
 a) It is not arguably better and more suggestive than the syntax in place.
I can't guarantee that it's better but I do think an argument can prove a result. Thats what arguments for.
 
 b) "(1,3)" already means two things, neither of which has anything to do 
Could you kindly state those? I can see that just having "(1,3)" preceded with the "case" keyword makes most other meanings impossible.
Jul 07 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Tim Matthews" <tim.matthews7 gmail.com> wrote in message 
news:h2v0ng$ko8$1 digitalmars.com...
 b) "(1,3)" already means two things, neither of which has anything to do
Could you kindly state those? I can see that just having "(1,3)" preceded with the "case" keyword makes most other meanings impossible.
One is a function paramater list. Someone else said it's also an expression that evaluates to 3, but that seems beyond useless to me.
Jul 07 2009
next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Nick Sabalausky wrote:
 "Tim Matthews" <tim.matthews7 gmail.com> wrote in message 
 news:h2v0ng$ko8$1 digitalmars.com...
 b) "(1,3)" already means two things, neither of which has anything to do
Could you kindly state those? I can see that just having "(1,3)" preceded with the "case" keyword makes most other meanings impossible.
One is a function paramater list. Someone else said it's also an expression that evaluates to 3, but that seems beyond useless to me.
Neither. Functions can't be named case and expressions with no effect must be cast to void.
Jul 07 2009
parent "Nick Sabalausky" <a a.a> writes:
"Tim Matthews" <tim.matthews7 gmail.com> wrote in message 
news:h2v4pa$qde$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Tim Matthews" <tim.matthews7 gmail.com> wrote in message 
 news:h2v0ng$ko8$1 digitalmars.com...
 b) "(1,3)" already means two things, neither of which has anything to 
 do
Could you kindly state those? I can see that just having "(1,3)" preceded with the "case" keyword makes most other meanings impossible.
One is a function paramater list. Someone else said it's also an expression that evaluates to 3, but that seems beyond useless to me.
Neither. Functions can't be named case and expressions with no effect must be cast to void.
Huh? I think we got out-of-sync when I accidentially quoted more than I meant to. I was responding specifically to "(1,3) already means two things...Could you kindly state those?"
Jul 07 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
  Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me. 
It's handy when you want to prefix one expression to another, as in: (foo(), x + 3)
Jul 07 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1 digitalmars.com> w=
rote:
 Nick Sabalausky wrote:
 =A0Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me.
It's handy when you want to prefix one expression to another, as in: =A0 (foo(), x + 3)
Cause you want to do that so often, after all. *snort*
Jul 07 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1 digitalmars.com>
wrote:
 Nick Sabalausky wrote:
  Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me.
It's handy when you want to prefix one expression to another, as in: (foo(), x + 3)
Cause you want to do that so often, after all. *snort*
It happens less manually and more when you're generating code. The latter happens a lot.
Jul 07 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 7, 2009 at 3:49 PM, Jarrett
Billingsley<jarrett.billingsley gmail.com> wrote:
 On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1 digitalmars.com>=
wrote:
 Nick Sabalausky wrote:
 =A0Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me.
It's handy when you want to prefix one expression to another, as in: =A0 (foo(), x + 3)
Cause you want to do that so often, after all. *snort*
A more constructive reply: tuuuuples. TUPLES. Returning them! Using them as first-class values! Yes.
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 3:49 PM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:
 On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1 digitalmars.com>
wrote:
 Nick Sabalausky wrote:
  Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me.
It's handy when you want to prefix one expression to another, as in: (foo(), x + 3)
Cause you want to do that so often, after all. *snort*
A more constructive reply: tuuuuples. TUPLES. Returning them! Using them as first-class values! Yes.
Just prepend "tuple" and you're home at a low price. Andrei
Jul 07 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 7, 2009 at 4:15 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 3:49 PM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:
 On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1 digitalmars.co=
m>
 wrote:
 Nick Sabalausky wrote:
 =A0Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me.
It's handy when you want to prefix one expression to another, as in: =A0(foo(), x + 3)
Cause you want to do that so often, after all. *snort*
A more constructive reply: tuuuuples. =A0TUPLES. =A0Returning them! =A0U=
sing
 them as first-class values! =A0Yes.
Just prepend "tuple" and you're home at a low price.
I can't return tuples. I have to wrap them in a struct. If I do that, then I can't index the struct as if it were a real tuple. Okay, then I use 'alias this', and I end up with this struct that exists for no purpose other than to get around a silly limitation in the type system. Well, geez! Why not just make tuples first-class?
Jul 07 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 4:15 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 3:49 PM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:
 On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1 digitalmars.com>
 wrote:
 Nick Sabalausky wrote:
  Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me.
It's handy when you want to prefix one expression to another, as in: (foo(), x + 3)
Cause you want to do that so often, after all. *snort*
A more constructive reply: tuuuuples. TUPLES. Returning them! Using them as first-class values! Yes.
Just prepend "tuple" and you're home at a low price.
I can't return tuples. I have to wrap them in a struct. If I do that, then I can't index the struct as if it were a real tuple. Okay, then I use 'alias this', and I end up with this struct that exists for no purpose other than to get around a silly limitation in the type system. Well, geez! Why not just make tuples first-class?
Yeah, really. The TupleType already exists in the compiler, but just can't be expressed and passed around in the language. I had trouble with this in Descent, for example: auto x = Foo.tupleof; Now you hover over "auto" and it should show you the type, but... the type is magical! That was when I found out about tuples. Now I show that as "Tuple!(...)", which is incorrect because it's not a template, but the language can't represent tuples. So there should be a syntax to represent tuples also...
Jul 07 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 4:15 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 3:49 PM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:
 On Tue, Jul 7, 2009 at 3:38 PM, Walter 
 Bright<newshound1 digitalmars.com>
 wrote:
 Nick Sabalausky wrote:
  Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me.
It's handy when you want to prefix one expression to another, as in: (foo(), x + 3)
Cause you want to do that so often, after all. *snort*
A more constructive reply: tuuuuples. TUPLES. Returning them! Using them as first-class values! Yes.
Just prepend "tuple" and you're home at a low price.
I can't return tuples. I have to wrap them in a struct. If I do that, then I can't index the struct as if it were a real tuple. Okay, then I use 'alias this', and I end up with this struct that exists for no purpose other than to get around a silly limitation in the type system. Well, geez! Why not just make tuples first-class?
Yeah, really. The TupleType already exists in the compiler, but just can't be expressed and passed around in the language.
It can be expressed, just not as a literal. Use TypeTuple. (By the way there's some confusion in this discussion about Tuple vs. TypeTuple.) Andrei
Jul 07 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 4:15 PM, Andrei 
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Tue, Jul 7, 2009 at 3:49 PM, Jarrett 
 Billingsley<jarrett.billingsley gmail.com> wrote:
 On Tue, Jul 7, 2009 at 3:38 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Nick Sabalausky wrote:
 Someone else said it's also an expression that evaluates to
 3, but that seems beyond useless to me.
It's handy when you want to prefix one expression to another, as in: (foo(), x + 3)
Cause you want to do that so often, after all. *snort*
A more constructive reply: tuuuuples. TUPLES. Returning them! Using them as first-class values! Yes.
Just prepend "tuple" and you're home at a low price.
I can't return tuples. I have to wrap them in a struct.
Yes, the struct is called Tuple and is present in std.typecons. There's also a function called tuple() that returns a Tuple with deduced parameters. Try it!
 If I do that, then I can't index the struct as if it were a real
 tuple.  Okay, then I use 'alias this', and I end up with this struct
 that exists for no purpose other than to get around a silly
 limitation in the type system.
Alias this has vastly more applications. Tuple has alias this commented out because there are related bugs in the compiler that I didn't get to.
 Well, geez!  Why not just make tuples first-class?
That would be a fish. We want to learn fishing. Andrei
Jul 07 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Per: NG D
Soggetto: Re: Case Range Statement ..

Andrei Alexandrescu Wrote:
 That would be a fish. We want to learn fishing.
Tuples (as the tuples of Python, but represented with a different literal syntax, please) can be useful in really many situations, so hard-coding them in a language can be acceptable (that's why D has built-in dynamic arrays and associative arrays, for example). Currently the tuples (the Record/record of my dlibs) of Phobos doesn't support "necessary" usages like: for x,y in [(1,2), (3,4)]: ... x, y, z = (1, 2, 3) Or even, from Python 3+: x, y, *z = (1, 2, 3, 4) So it's a matter of balance, sometimes you need the flexibility (to learn fishing) and sometimes a handy and hard-coded solution is fine (because you need to eat a bowl of rice every day). You can add some built-in "defaults" too, with a nice short syntax for the programmer and a semantic that allows the compiler to digest them well (because very general features are often more hard for the compiler to compile them well, and require a more complex compiler. If you want a simple example, in D even foreach() is slower than for() when compiled with DMD, so I usually avoid foreach in the inner loops). Regarding the "learn fishing", for example recently I have discussed about adding an OpBool to structs and classes, to allow to use if(x) when x is a define both true() and false(), I don't know why). There are other similar things that can be done in such regard. Too much hard-coding leads to languages like Java, and too much flexibility leads to languages like Lisp where you can do anything, and where essentially every programmer does thigns in a different way, and this leads to the mess that's now Lisp. Python is less flexible than Lisp, you can't metaprogram it much, and both the semantic, the syntax and even the way people write source code is hard-coded and standard, the result is that today you can find a Python module to do anything, because re-using modules written by other people is easy, and it's easy to understand what's inside such modules. Here too you can see that's it's better to find a compromise between having a fish and learning fishing. Bye, bearophile
Jul 07 2009
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 12:38:49 -0700, Walter Bright wrote:

 Nick Sabalausky wrote:
  Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me. 
It's handy when you want to prefix one expression to another, as in: (foo(), x + 3)
I took what Nick said to mean that expressions in the form ( integerA , integerB ) were useless as they always evaluate to integerB, so why bother to code them as expressions. Whereas such an expression *in* the context of a case clause could be made to mean that an inclusive range was being requested by the coder. Walter's example, using a function call, could be useful as the function can have side-effects that influence the next sub-expression "x + 3". -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:h3088a$2kla$3 digitalmars.com...
 Nick Sabalausky wrote:
  Someone else said it's also an expression
 that evaluates to 3, but that seems beyond useless to me.
It's handy when you want to prefix one expression to another, as in: (foo(), x + 3)
I guess I'm not familiar with that syntax. What does that do and for what purpose?
Jul 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 It's handy when you want to prefix one expression to another, as in:

    (foo(), x + 3)
I guess I'm not familiar with that syntax. What does that do and for what purpose?
They're called Comma Expressions, and the left operand is evaluated first, its result discarded, then the right operand is evaluated and forms the type and result of the Comma Expression. It's handy for things like rewriting ++e so it can be used more than once but is only evaluated once: (tmp = ++e, tmp)
Jul 07 2009
parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Walter Bright wrote:
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 It's handy when you want to prefix one expression to another, as in:

    (foo(), x + 3)
I guess I'm not familiar with that syntax. What does that do and for=20 what purpose?=20
=20 They're called Comma Expressions, and the left operand is evaluated=20 first, its result discarded, then the right operand is evaluated and=20 forms the type and result of the Comma Expression. =20
I've always felt they were useless and confusing. What's the=20 advantage of "y =3D (foo(), x + 3);" over "foo(); y =3D x+3;"?
 It's handy for things like rewriting ++e so it can be used more than=20
 once but is only evaluated once:
=20
    (tmp =3D ++e, tmp)
Uh? How is that different from "++e" Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 09 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jérôme M. Berger wrote:
 Walter Bright wrote:
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 It's handy when you want to prefix one expression to another, as in:

    (foo(), x + 3)
I guess I'm not familiar with that syntax. What does that do and for what purpose?
They're called Comma Expressions, and the left operand is evaluated first, its result discarded, then the right operand is evaluated and forms the type and result of the Comma Expression.
I've always felt they were useless and confusing. What's the advantage of "y = (foo(), x + 3);" over "foo(); y = x+3;"?
When you only see the x+3 because you're recursively walking the tree generating code.
 It's handy for things like rewriting ++e so it can be used more than 
 once but is only evaluated once:

    (tmp = ++e, tmp)
Uh? How is that different from "++e"
You can then use tmp more than once with only one increment of e.
Jul 09 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Walter,

 It's handy for things like rewriting ++e so it can be used more than
 once but is only evaluated once:
 
(tmp = ++e, tmp)
 Uh? How is that different from "++e"
 
You can then use tmp more than once with only one increment of e.
how does that differ from using ++e the first time and then e for the other times?
Jul 09 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 Hello Walter,
 
 It's handy for things like rewriting ++e so it can be used more than
 once but is only evaluated once:
(tmp = ++e, tmp)
 Uh? How is that different from "++e"
You can then use tmp more than once with only one increment of e.
how does that differ from using ++e the first time and then e for the other times?
1. e may be a global 2. ++e may be a more complicated expression with side effects
Jul 09 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jul 9, 2009 at 7:08 PM, Walter Bright<newshound1 digitalmars.com> w=
rote:
 J=E9r=F4me M. Berger wrote:
 Walter Bright wrote:
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 It's handy when you want to prefix one expression to another, as in:

 =A0 (foo(), x + 3)
I guess I'm not familiar with that syntax. What does that do and for what purpose?
They're called Comma Expressions, and the left operand is evaluated first, its result discarded, then the right operand is evaluated and fo=
rms
 the type and result of the Comma Expression.
=A0 =A0I've always felt they were useless and confusing. What's the adva=
ntage
 of "y =3D (foo(), x + 3);" over "foo(); y =3D x+3;"?
When you only see the x+3 because you're recursively walking the tree generating code.
If it's internal to the parse tree can't you make the syntax whatever you w= ant? Something like (expr1 __exprSequencer expr2) should do just fine, right? No reason it has to be a precious one-character symbol syntax. --bb
Jul 09 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 If it's internal to the parse tree can't you make the syntax whatever you want?
 Something like (expr1 __exprSequencer expr2) should do just fine, right?
 No reason it has to be a precious one-character symbol syntax.
What if you're writing a program that generates D code?
Jul 09 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Jul 10, 2009 at 12:09 AM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 If it's internal to the parse tree can't you make the syntax whatever you
 want?
 Something like (expr1 __exprSequencer expr2) should do just fine, right?
 No reason it has to be a precious one-character symbol syntax.
What if you're writing a program that generates D code?
..then you'd have it generate multiple statements? Really, I'm not seeing the justification here!
Jul 09 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Fri, Jul 10, 2009 at 12:09 AM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 If it's internal to the parse tree can't you make the syntax whatever you
 want?
 Something like (expr1 __exprSequencer expr2) should do just fine, right?
 No reason it has to be a precious one-character symbol syntax.
What if you're writing a program that generates D code?
..then you'd have it generate multiple statements?
Your recursive function may not have any access to the parents of the expression node it is working on.
 Really, I'm not seeing the justification here!
You should come to my compiler seminar, then! http:www.astoriaseminar.com Without any way to sequence expressions in place, a lot of manipulation becomes much more complicated. Comma expressions have been around a long time, they work well, and are often used.
Jul 09 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Jul 10, 2009 at 1:50 AM, Walter
Bright<newshound1 digitalmars.com> wrote:

 Without any way to sequence expressions in place, a lot of manipulation
 becomes much more complicated. Comma expressions have been around a long
 time, they work well, and are often used.
Then why not, as someone else has suggested, use some kind of internal sequence node, maybe with an obscure keyword as the separator? It's just that the syntactic possibilities of the comma operator are too wonderful to ignore. It seems like such a waste of an operator for something that most people won't use in _human-generated_ code outside of for loop headers.
Jul 10 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Fri, Jul 10, 2009 at 1:50 AM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 
 Without any way to sequence expressions in place, a lot of manipulation
 becomes much more complicated. Comma expressions have been around a long
 time, they work well, and are often used.
Then why not, as someone else has suggested, use some kind of internal sequence node, maybe with an obscure keyword as the separator? It's just that the syntactic possibilities of the comma operator are too wonderful to ignore. It seems like such a waste of an operator for something that most people won't use in _human-generated_ code outside of for loop headers.
Because an *internal* sequence node will not be available to anyone writing D code that generates D code. The sequence operator is very valuable to anyone writing code that generates code, pulling it out of D would make D fairly unusable for advanced metaprogramming.
Jul 10 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jul 9, 2009 at 9:09 PM, Walter Bright<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 If it's internal to the parse tree can't you make the syntax whatever you
 want?
 Something like (expr1 __exprSequencer expr2) should do just fine, right?
 No reason it has to be a precious one-character symbol syntax.
What if you're writing a program that generates D code?
If you're generating code which is so tricky that it needs to rely on comma expressions, then I doubt it will be something that users will be expected to read and/or edit. In which case, again, it doesn't matter how ugly the syntax is. "__exprSequencer" would do just fine. --bb
Jul 10 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 On Thu, Jul 9, 2009 at 9:09 PM, Walter Bright<newshound1 digitalmars.com>
wrote:
 Bill Baxter wrote:
 If it's internal to the parse tree can't you make the syntax whatever you
 want?
 Something like (expr1 __exprSequencer expr2) should do just fine, right?
 No reason it has to be a precious one-character symbol syntax.
What if you're writing a program that generates D code?
If you're generating code which is so tricky that it needs to rely on comma expressions,
Writing code that requires that "A" be executed before "B" is not tricky or unusual.
 then I doubt it will be something that users will
 be expected to read and/or edit.  In which case, again, it doesn't
 matter how ugly the syntax is.  "__exprSequencer" would do just fine.
Making D metaprogramming spectacularly ugly will not help bring metaprogramming to the mainstream and will drive away the kind of people who can create fantastic metaprogramming applications.
Jul 10 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 On Thu, Jul 9, 2009 at 9:09 PM, Walter 
 Bright<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 If it's internal to the parse tree can't you make the syntax 
 whatever you
 want?
 Something like (expr1 __exprSequencer expr2) should do just fine, 
 right?
 No reason it has to be a precious one-character symbol syntax.
What if you're writing a program that generates D code?
If you're generating code which is so tricky that it needs to rely on comma expressions,
Writing code that requires that "A" be executed before "B" is not tricky or unusual.
 then I doubt it will be something that users will
 be expected to read and/or edit.  In which case, again, it doesn't
 matter how ugly the syntax is.  "__exprSequencer" would do just fine.
Making D metaprogramming spectacularly ugly will not help bring metaprogramming to the mainstream and will drive away the kind of people who can create fantastic metaprogramming applications.
Is the comma operator used in any of the metaprogramming of phobos? Or Tango? Or anywhere else?
Jul 10 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jul 10, 2009 at 12:24 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 On Thu, Jul 9, 2009 at 9:09 PM, Walter Bright<newshound1 digitalmars.com=
 wrote:
 Bill Baxter wrote:
 If it's internal to the parse tree can't you make the syntax whatever
 you
 want?
 Something like (expr1 __exprSequencer expr2) should do just fine, righ=
t?
 No reason it has to be a precious one-character symbol syntax.
What if you're writing a program that generates D code?
If you're generating code which is so tricky that it needs to rely on comma expressions,
Writing code that requires that "A" be executed before "B" is not tricky =
or
 unusual.
Right. And usually that's written A; B Writing code that requires A to be executed before B *and* requires that the whole thing act like a single expression is much more rare.
 then I doubt it will be something that users will
 be expected to read and/or edit. =A0In which case, again, it doesn't
 matter how ugly the syntax is. =A0"__exprSequencer" would do just fine.
Making D metaprogramming spectacularly ugly will not help bring metaprogramming to the mainstream and will drive away the kind of people =
who
 can create fantastic metaprogramming applications.
Then pick something less ugly! Double colon is still free in D isn't it? My point of arguing this is just that I'm still hoping commas could be used to make a tuple literal syntax. And now Andrei is going to jump in and say "why do we need that? We want to fish not eat fish, lookee I've made a fish hook for you, it's spelled: "Tuple!()"" or somthing like that. P.S. making compile-time reflection spectacularly ugly is also not a good way to bring metaprogramming to the mainstream. (Looking at you, __traits). P.P.S. on the other hand, Python uses double underscores all over the place and people call it a beautiful language. Go figure. I guess it's only ugly till you have a few dozen of them. Then it's a "pattern". --bb
Jul 10 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 P.P.S. on the other hand,  Python uses double underscores all over the
 place and people call it a beautiful language.  Go figure.  I guess
 it's only ugly till you have a few dozen of them.  Then it's a
 "pattern".
Maybe Python has a community that knows better what to worry about :o). Andrei
Jul 10 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jul 10, 2009 at 6:08 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 P.P.S. on the other hand, =A0Python uses double underscores all over the
 place and people call it a beautiful language. =A0Go figure. =A0I guess
 it's only ugly till you have a few dozen of them. =A0Then it's a
 "pattern".
Maybe Python has a community that knows better what to worry about :o).
I think it's more that it has a strong leadership. --bb
Jul 11 2009
prev sibling parent reply Valery <free_on mail.ru> writes:
I think that inclusive ranges more intuitive for beginner programmers because
statements:

  case 1..10,
  array [1..10],
  foreach (int item; 1..10),
  foreach_reverse (int item; 1..10) (now foreach_reverse range is too dificult
to understand it: item begins with 10 or 9, ends 1 or 2?)

will not require an explanation of their actions. Thanks.
Jul 11 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Valery wrote:
 I think that inclusive ranges more intuitive for beginner programmers because
statements:
 
   case 1..10,
   array [1..10],
   foreach (int item; 1..10),
   foreach_reverse (int item; 1..10) (now foreach_reverse range is too dificult
to understand it: item begins with 10 or 9, ends 1 or 2?)
 
 will not require an explanation of their actions. Thanks.
I can say from personal experience that this is true. 1-based indexing is also easier for beginners. So are BASIC and LOGO. You may notice a trend here... :P Inclusive ranges are easier for naive programmers to grok, but are fundamentally mismatched to programming. It's harder to split an inclusive range, and it complicates the math. Just try writing anything which involves manipulating ranges in Lua; it's considerably harder than with exclusive ranges. The question is which you would rather: help naive programmers work inefficiently or prevent competent programmers from working efficiently? I say screw the beginners; learning will do them good.
Jul 11 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Daniel Keep wrote:

 
 Valery wrote:
 I think that inclusive ranges more intuitive for beginner programmers
 because statements:
 
   case 1..10,
   array [1..10],
   foreach (int item; 1..10),
   foreach_reverse (int item; 1..10) (now foreach_reverse range is too
   dificult to understand it: item begins with 10 or 9, ends 1 or 2?)
 
 will not require an explanation of their actions. Thanks.
I can say from personal experience that this is true. 1-based indexing is also easier for beginners. So are BASIC and LOGO. You may notice a trend here... :P Inclusive ranges are easier for naive programmers to grok, but are fundamentally mismatched to programming. It's harder to split an inclusive range, and it complicates the math. Just try writing anything which involves manipulating ranges in Lua; it's considerably harder than with exclusive ranges. The question is which you would rather: help naive programmers work inefficiently or prevent competent programmers from working efficiently? I say screw the beginners; learning will do them good.
Besides, when learning programming the concept of zero-based indexing and exclusive ranges is amongst the most trivial of concerns you need worry about these days.
Jul 11 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lutger wrote:
 Daniel Keep wrote:
 
 Valery wrote:
 I think that inclusive ranges more intuitive for beginner programmers
 because statements:

   case 1..10,
   array [1..10],
   foreach (int item; 1..10),
   foreach_reverse (int item; 1..10) (now foreach_reverse range is too
   dificult to understand it: item begins with 10 or 9, ends 1 or 2?)

 will not require an explanation of their actions. Thanks.
I can say from personal experience that this is true. 1-based indexing is also easier for beginners. So are BASIC and LOGO. You may notice a trend here... :P Inclusive ranges are easier for naive programmers to grok, but are fundamentally mismatched to programming. It's harder to split an inclusive range, and it complicates the math. Just try writing anything which involves manipulating ranges in Lua; it's considerably harder than with exclusive ranges. The question is which you would rather: help naive programmers work inefficiently or prevent competent programmers from working efficiently? I say screw the beginners; learning will do them good.
Besides, when learning programming the concept of zero-based indexing and exclusive ranges is amongst the most trivial of concerns you need worry about these days.
On the other hand indeed foreach_reverse is tricky and I bet it does the wrong thing with floats. Actually let's see: import std.stdio; void main() { foreach_reverse (i; 0.7 .. 100.7) { write(i, " "); } } The last number printed is -0.3. I think this has been discussed, but I can't find a bugzilla about it. Andrei
Jul 11 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Andrei Alexandrescu wrote:

 void main()
 {
      foreach_reverse (i; 0.7 .. 100.7)
      {
          write(i, " ");
      }
 }
 
 The last number printed is -0.3.
A question if I may. Why does D allow iteration over an interval of floats? A floating point number has no direct successor or predecessor. Any such interval would contain zero, one or infinite elements. Given the -0.3, I'm assuming you increase/decrease by 1.0 each iteration. Is this useful enough to be the standard behavior? -- Michiel Helvensteijn
Jul 11 2009
parent reply Don <nospam nospam.com> writes:
Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:
 
 void main()
 {
      foreach_reverse (i; 0.7 .. 100.7)
      {
          write(i, " ");
      }
 }

 The last number printed is -0.3.
A question if I may. Why does D allow iteration over an interval of floats? A floating point number has no direct successor or predecessor. Any such interval would contain zero, one or infinite elements. Given the -0.3, I'm assuming you increase/decrease by 1.0 each iteration. Is this useful enough to be the standard behavior?
It's a petri dish. Perfect breeding ground for bugs. real BIG = 2.0 /(real.epsilon); foreach(i; BIG .. BIG + 2) { ... } Infinite loop, since BIG + 1 == BIG.
Jul 13 2009
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:
 Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 void main()
 {
      foreach_reverse (i; 0.7 .. 100.7)
      {
          write(i, " ");
      }
 }

 The last number printed is -0.3.
A question if I may. Why does D allow iteration over an interval of floats? A floating point number has no direct successor or predecessor. Any such interval would contain zero, one or infinite elements. Given the -0.3, I'm assuming you increase/decrease by 1.0 each iteration. Is this useful enough to be the standard behavior?
It's a petri dish. Perfect breeding ground for bugs. real BIG = 2.0 /(real.epsilon); foreach(i; BIG .. BIG + 2) { ... } Infinite loop, since BIG + 1 == BIG.
It's also inconsistent: foreach (e; range) // Iterate over *all* elements in range foreach (i; 0..10) // Iterate over *all* integers from 0 to 9 foreach (f; 0.0..10.0) // Iterate over a small subset of floating-point numbers between 0 and 10 -Lars
Jul 13 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 13, 2009 at 2:59 AM, Don<nospam nospam.com> wrote:
 Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 void main()
 {
 =A0 =A0 foreach_reverse (i; 0.7 .. 100.7)
 =A0 =A0 {
 =A0 =A0 =A0 =A0 write(i, " ");
 =A0 =A0 }
 }

 The last number printed is -0.3.
A question if I may. Why does D allow iteration over an interval of floats? A floating point number has no direct successor or predecessor. Any such interval would contain zero, one or infinite elements. Given the -0.3, I'm assuming you increase/decrease by 1.0 each iteration=
.
 Is
 this useful enough to be the standard behavior?
It's a petri dish. Perfect breeding ground for bugs. real BIG =3D 2.0 /(real.epsilon); foreach(i; BIG .. BIG + 2) { =A0... } Infinite loop, since BIG + 1 =3D=3D BIG.
So why do Matlab and NumPy both have such constructs (with optional stepsiz= e)? --bb
Jul 13 2009
prev sibling parent BCS <none anon.com> writes:
Hello Bill,


 P.P.S. on the other hand,  Python uses double underscores all over the
 place and people call it a beautiful language.  Go figure.  I guess
 it's only ugly till you have a few dozen of them.  Then it's a
 "pattern".
 
 --bb
 
"A single double underscore is a tragedy; a million double underscores is a statistic" -- Jo Stuff Stall'em
Jul 10 2009
prev sibling parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Walter Bright wrote:
 J=E9r=F4me M. Berger wrote:
     I've always felt they were useless and confusing. What's the=20
 advantage of "y =3D (foo(), x + 3);" over "foo(); y =3D x+3;"?
=20 When you only see the x+3 because you're recursively walking the tree=20 generating code. =20
 It's handy for things like rewriting ++e so it can be used more than =
 once but is only evaluated once:

    (tmp =3D ++e, tmp)
Uh? How is that different from "++e"
=20 You can then use tmp more than once with only one increment of e.
I guess I'll need a complete concrete example before I understand.=20 I mean: tmp =3D ++e; veryComplexExpressionThatUsesTmpSeveralTimesWithoutTouchingE; Or even: ++e; veryComplexExpressionThatUsesESeveralTimesWithoutIncrementingIt; Are both clearer, less error-prone and should produce equivalent=20 code to the coma expression. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 10 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 7, 2009 at 5:24 PM, Tim Matthews<tim.matthews7 gmail.com> wrote:
 Andrei Alexandrescu wrote:
 Existing actual or perceived inconsistencies are not an argument for
 adding more of them.
Seriously?
d00d. Does that really need explanation? Two wrongs don't make a right is all he's saying. Do you disagree?
 a) It is not arguably better and more suggestive than the syntax in place.
I can't guarantee that it's better but I do think an argument can prove a result. Thats what arguments for.
But the argument has already been had previously here on the NG. I guess you missed it.
 b) "(1,3)" already means two things, neither of which has anything to do
Could you kindly state those? I can see that just having "(1,3)" preceded with the "case" keyword makes most other meanings impossible.
Unless you have been told what it means, people seeing it for the first time will probably not guess that it means a range. It looks like a case list to me that would only stop on case 1 or case 3. We already have the syntax "case 1,3:" so just adding parentheses to that doesn't really scream out "range". --bb
Jul 07 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tim Matthews wrote:
 Andrei Alexandrescu wrote:
 Existing actual or perceived inconsistencies are not an argument for 
 adding more of them.
Seriously?
 a) It is not arguably better and more suggestive than the syntax in 
 place.
I can't guarantee that it's better but I do think an argument can prove a result. Thats what arguments for.
 b) "(1,3)" already means two things, neither of which has anything to do 
Could you kindly state those?
(1, 2) is an expression and the argument list for a function. Neither suggests in the least that it's supposed to mean a sequence of case labels.
 I can see that just having "(1,3)" preceded with the "case" keyword 
 makes most other meanings impossible.
Prepare to be surprised. Compile this: void main() { switch (2) { case (1, 2): break; default: break; } } Andrei
Jul 07 2009
parent Tim Matthews <tim.matthews7 gmail.com> writes:
Andrei Alexandrescu wrote:
 
 Prepare to be surprised. Compile this:
 
 void main()
 {
     switch (2)
     {
     case (1, 2): break;
     default: break;
     }
 }
 
 
I'm getting the message that it is impossible to override what is already and expression evaluating to the last in the comma sequence which is not the case as other meanings exist for function calls and templates etc. Not surprising that it currently picks the default of just the expression in anyway and it would probably be in error if it didn't currently do so.
Jul 07 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 7, 2009 at 9:07 AM, Bill Baxter<wbaxter gmail.com> wrote:
 On Tue, Jul 7, 2009 at 5:24 PM, Tim Matthews<tim.matthews7 gmail.com> wrote:
 Andrei Alexandrescu wrote:
 Existing actual or perceived inconsistencies are not an argument for
 adding more of them.
Seriously?
d00d.
Woah woah woah woah. Who *are* you; superdan? ;)
Jul 07 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:h2uoju$5f1$1 digitalmars.com...
 And heeeeere we go again!

 *sigh*

 switch( foo )
 {
     case 0:
     ..
     case 5:
         blah();
         break;

     default:
         bork();
 }
Doesn't look so bad, does it? For the record, I think the current syntax is ugly. But: * it WORKS, * it is reasonably distinct from all the other uses of ".." which have a DIFFERENT MEANING, * it has an easily-explained rationale: "the .. stands in for the case labels you would have written." Can we please, please stop the useless bike-shedding on this NG? Yes, it's a bit ugly, but all the alternatives proposed have SEMANTIC issues with them, which is much worse.
I like bike sheds.
Jul 07 2009
prev sibling next sibling parent reply Mike James <foo bar.com> writes:
Tim Matthews Wrote:

 The case range statement is currently this
 
 case FirstExp : .. case LastExp :
 
 Would it be ambiguous to the compiler if it was
 
 case FirstExp .. case LastExp :
 
 or even
 
 case FirstExp .. LastExp :
 
 
 Considering that we can correctly identify a slice rather than decimal 
 by just giving it a priority:
 
 a = b[3..6];
Or you introduce a new keyword :-) switch (var) { case 0: break; case 1 to 5: break; } -=mike=-
Jul 07 2009
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Mike James wrote:
 Tim Matthews Wrote:
 
 The case range statement is currently this

 case FirstExp : .. case LastExp :

 Would it be ambiguous to the compiler if it was

 case FirstExp .. case LastExp :

 or even

 case FirstExp .. LastExp :


 Considering that we can correctly identify a slice rather than decimal 
 by just giving it a priority:

 a = b[3..6];
Or you introduce a new keyword :-) switch (var) { case 0: break; case 1 to 5: break; } -=mike=-
Introducing "to" as a keyword would break the std.conv module, which would be a shame. It's a very nice module. -Lars
Jul 07 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 04:35:56 -0400, Mike James wrote:

 
 Or you introduce a new keyword :-)
Ooooh .... you said the 'k' word, naughty boy. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
parent Mike James <foo bar.com> writes:
Derek Parnell Wrote:

 On Tue, 07 Jul 2009 04:35:56 -0400, Mike James wrote:
 
 
 Or you introduce a new keyword :-)
Ooooh .... you said the 'k' word, naughty boy. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
It's my Pascal background - why use a hieroglyphic when an English word will do :-) -=mike=-
Jul 07 2009
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 07 Jul 2009 04:35:56 -0400, Mike James wrote:

 Tim Matthews Wrote:
 
 The case range statement is currently this
 
 case FirstExp : .. case LastExp :
 
 Would it be ambiguous to the compiler if it was
 
 case FirstExp .. case LastExp :
 
 or even
 
 case FirstExp .. LastExp :
 
 
 Considering that we can correctly identify a slice rather than decimal
 by just giving it a priority:
 
 a = b[3..6];
Or you introduce a new keyword :-) switch (var) { case 0: break; case 1 to 5: break; } -=mike=-
to? really, no, it needs to be - switch (var) { case 0: break; case 1 - 5: break; }
Jul 07 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jesse Phillips wrote:
 On Tue, 07 Jul 2009 04:35:56 -0400, Mike James wrote:
 
 Tim Matthews Wrote:

 The case range statement is currently this

 case FirstExp : .. case LastExp :

 Would it be ambiguous to the compiler if it was

 case FirstExp .. case LastExp :

 or even

 case FirstExp .. LastExp :


 Considering that we can correctly identify a slice rather than decimal
 by just giving it a priority:

 a = b[3..6];
Or you introduce a new keyword :-) switch (var) { case 0: break; case 1 to 5: break; } -=mike=-
to? really, no, it needs to be - switch (var) { case 0: break; case 1 - 5: break; }
Is that a joke?
Jul 07 2009
parent Jesse Phillips <jessekphillips+d gmail.com> writes:
Ary Borenszweig Wrote:

 
 to? really, no, it needs to be -
 
 switch (var) {
     case 0:
         break;
 
     case 1 - 5:
         break;
 }
Is that a joke?
No, I just hope it won't be taken seriously. :)
Jul 07 2009
prev sibling parent Ali Cehreli <acehreli yahoo.com> writes:
Mike James Wrote:

     case 1 to 5:
Can't resist... :) case foreach (n; 1..6): Ali
Jul 08 2009