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.

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.

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

Andrei Alexandrescu wrote:
> 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. At the moment I don't give a rat's ass what it actually is, '...', '..#', '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.
> 
	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!

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

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

On Wed, Jul 8, 2009 at 4:12 PM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
> 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.

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

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

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

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.

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).