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.

>> Or just drop octal altogether.  Outside 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.

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.

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)

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 ) 

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.

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.

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.

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.

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

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