davepermen: You're really not helping this debate with all the bad language ("S" this, and "F" that). How about keeping a cool head on your shoulders, and stick to the facts on how it would make your coding better / solve problems. I'm pretty sure Walter will listen to level-headed reasons as why it would be better, plus use some coding logic and examples to solidifying your points.

everybody: Now for a recap of this thread's (finer) points, and Walter's reply
to each:

1) representing octals with the preceding a zero.

Walter:>"This common notation for octal numbers goes beyond C; it's used in other languages and in assembly language, system manuals, data sheets, etc."

2) 0x, 0d, 0o, 0c, and 0b / or some like of suffix

Walter:>"Makes it harder and slower to lex - numeric literals would need to be scanned twice."

3) pragma(leading_zero_radix," 0 or 8 or 10 ");"

Walter:>"It's awfully tempting to create pragmas that change the grammar of the language, but doing so would render all source code tools that do simple lexing and parsing, such as syntax highlighters and pretty-printers, much, much harder to create.

A major design goal of D is to be able to lex without parsing, and to be able to
parse without maintaining a symbol table or doing any semantic
processing. This also makes things like templates and mixins far easier to deal
with <g>."

---------
Now, if only we developers could start talking about how making any of these changes we've been rebating, will solve real-world problems? Walter might reconsider...you never know. ;)

> davepermen: You're really not helping this debate with all the bad language
("S"
> this, and "F" that). How about keeping a cool head on your shoulders, and stick to the facts on how it would make your coding better / solve problems. I'm pretty sure Walter will listen to level-headed reasons as why it would be better, plus use some coding logic and examples to solidifying your points.

I've just been watching some Sopranos on DVD, so davepermen's S&F seems quite tame. Nonetheless, I think David's right, and we should keep the language down, or at leave save it for when someone's next being disrespectful to Walter or Dr Stroustrup. ;)

In article <c925jv$1qs6$2@digitaldaemon.com>, Matthew says...
>
>
>"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:c91qid$1bdd$1@digitaldaemon.com...
>> Matthew wrote:
>>
>> > depends whether unprefixed numbers still represent decimal, or are now
>errors.
>> >
>> > I would be in favour of the following valid forms
>> >
>> >     0x90AB    -    hex
>> >     0d7890    -    decimal
>> >     0o6701    -    octal
>> >     0b1010    -    binary
>> >
>> > _and_
>> >
>> >     7890        -    decimal
>> >
>> > With 06701 for octal being invalid
>> <snip>
>>
>> Do you mean it would be an illegal token?  This is indeed the only way we can sensibly change this.
>
>Any literal integral beginning with 0 would be invalid (not illegal, since it's not against the law <g>), yes.

I'd like to ask for an exception for an octal number I use all the time: 0.

(Ducking rapidly.)
Kevin

Kevin Bealer wrote:
> In article <c925jv$1qs6$2@digitaldaemon.com>, Matthew says...
> 
>>
>>"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
>>news:c91qid$1bdd$1@digitaldaemon.com...
>>
>>Any literal integral beginning with 0 would be invalid (not illegal, since it's
>>not against the law <g>), yes.
> 
> I'd like to ask for an exception for an octal number I use all the time: 0.

Better to be explicit and say that you want 0 octal. (as opposed to hex or binary)

 -- andy

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c93u33$1eou$1@digitaldaemon.com...
> In article <c925jv$1qs6$2@digitaldaemon.com>, Matthew says...
> >
> >
> >"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:c91qid$1bdd$1@digitaldaemon.com...
> >> Matthew wrote:
> >>
> >> > depends whether unprefixed numbers still represent decimal, or are now
> >errors.
> >> >
> >> > I would be in favour of the following valid forms
> >> >
> >> >     0x90AB    -    hex
> >> >     0d7890    -    decimal
> >> >     0o6701    -    octal
> >> >     0b1010    -    binary
> >> >
> >> > _and_
> >> >
> >> >     7890        -    decimal
> >> >
> >> > With 06701 for octal being invalid
> >> <snip>
> >>
> >> Do you mean it would be an illegal token?  This is indeed the only way we can sensibly change this.
> >
> >Any literal integral beginning with 0 would be invalid (not illegal, since
it's
> >not against the law <g>), yes.
>
> I'd like to ask for an exception for an octal number I use all the time: 0.

LOL!

> (Ducking rapidly.)

Yeah, you'd bloody better!

In article <c92vs1$2i9$1@digitaldaemon.com>, Walter says...
>
>It's awfully tempting to create pragmas that change the grammar of the language, but doing so would render all source code tools that do simple lexing and parsing, such as syntax highlighters and pretty-printers, much, much harder to create.
>
>A major design goal of D is to be able to lex without parsing, and to be able to parse without maintaining a symbol table or doing any semantic processing. This also makes things like templates and mixins far easier to deal with <g>.


Yes, I was wrong. It happens. I guess I was just trying to keep everyone happy at the same time.

But I *would* still go with outlawing numeric literals which have a leading zero, in order to avoid the decimal/octal confusion. That wouldn't be a big deal, since anyone doing it deliberately would simply have to insert an "o" (or a "d") to disambiguate.

I also agree with those who said that the identifying letter should always be lower case (especially for octal since uppercase O looks remarkably like a zero).

As a matter of style, I like to see hex literals in uppercase. (That is, 0xFFFF, rather than 0xffff or 0XFFFF or 0Xffff). Probably not a good idea to mandate that, but might I suggest mentioning it in the style guide?

Someone else suggested a suffix instead of a prefix. But I humbly suggest that that wouldn't work - how could you tell whether FFFFh (or FFFFx) was a numeric literal or an identifier?

Just my thoughts, and if they turn out to be dumb ideas, I'm happy to drop them.

Arcane Jill

In article <c93kj7$10e4$1@digitaldaemon.com>, David L. Davis says...
>
>davepermen: You're really not helping this debate with all the bad language ("S" this, and "F" that). How about keeping a cool head on your shoulders, and stick to the facts on how it would make your coding better / solve problems. I'm pretty sure Walter will listen to level-headed reasons as why it would be better, plus use some coding logic and examples to solidifying your points.

I agree.

>everybody: Now for a recap of this thread's (finer) points, and Walter's reply
>to each:
>
>1) representing octals with the preceding a zero.
>
>Walter:>"This common notation for octal numbers goes beyond C; it's used in other languages and in assembly language, system manuals, data sheets, etc."

Well, apart from the standard in C (inherited in C++ and Java), I've never seen octals represented like this in any other "languages and in assembly language, system manuals, data sheets, etc.". I've found some incompatibilities also: in JavaScript/EcmaScript (0222 == 222) is true.

I read many documentation, data sheets, I know many languages, but only C and
family use this bad practice for octal numbers.
Moreover, like I alrady said, I've not found an octal in a manual/data sheet for
15 years. Ant I suspect that also before I started to read manuals/data sheet,
octals were very rare (or weren't at all).

>2) 0x, 0d, 0o, 0c, and 0b / or some like of suffix
>
>Walter:>"Makes it harder and slower to lex - numeric literals would need to be scanned twice."

Walter was referring to "suffixes" not "prefixes". Prefixes doesn't affect scanning (as long as they start with 0 or another digit).

>3) pragma(leading_zero_radix," 0 or 8 or 10 ");"
>
[...]

Walter is against language pragmas, compiler switches and compiler warnings. I start to agree with him in that order, so for now I'm less convinced only about the warnings.

>---------
>Now, if only we developers could start talking about how making any of these changes we've been rebating, will solve real-world problems? Walter might reconsider...you never know. ;)

I think Walter considers octal syntax something to keep for compatibility's
sake.
I disagree with him: I think it was an error from the beginning and, no matter
what it breaks, it should be removed.
Not that I use octals, or have seen anyone use it around here in the last
decade, but I sometimes teach programming: it's very difficult to explain to a
newby that 0123 != 123, simlpy because he/she replies "but this is a stupid
thing!" (in italian sounds much ruder), and he/she's right!
Once I found also a problem: one man, coming from VB/VBScript/JScript, inserted
som tens of constants in a Java program, all prefectly aligned with leading 0s.
What do you think he told me when I explained the whole thing? :-(

Ciao

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c94266$1k4l$1@digitaldaemon.com...
> Yes, I was wrong. It happens. I guess I was just trying to keep everyone
happy
> at the same time.

Probably the hardest thing about designing a new language is saying "no". Trying to make everyone happy on every point cannot work.

> Someone else suggested a suffix instead of a prefix. But I humbly suggest
that
> that wouldn't work - how could you tell whether FFFFh (or FFFFx) was a
numeric
> literal or an identifier?

How it normally is done is that you need to add a leading 0 if the leading character is not a decimal digit. (No, D isn't going to implement that.)

> Just my thoughts, and if they turn out to be dumb ideas, I'm happy to drop
them.

Even if I don't agree with them, your posts are well written, interesting, and welcome.