>In article <c90oc6$2r0n$1@digitaldaemon.com>, Matthew says...
>>I would be in favour of the following valid forms
>>
>>    0x90AB    -    hex
>>    0d7890    -    decimal
>>    0o6701    -    octal
>>    0b1010    -    binary
>>
>>_and_
>>
>>    7890        -    decimal
>>
In article <c90sos$30pc$1@digitaldaemon.com>, David L. Davis says...
>I'm for it too! (+1)

Adding my support to this one.

I wrote my big integer constructors before I read this thread. They can be initialized from a string (with, for example, "123" constructing 123, because integer literals aren't always big enough). I hadn't read this thread when I decided, independently, that such initializing strings would allow the following prefixes:

>    0x or 0X    -    hex
>    0d or 0D    -    decimal
>    0o or 0O    -    octal
>    0b or 0B    -    binary

Leading zeroes don't mean octal in my scheme. I worried about this for a while - being inconsistent with the general rule of C, C++, D, etc., but in the end I just though "Hell - precedent is wrong. Do it right".

On this planet, most programmers are humans, and mostly use base ten. The default should therefore be base ten.

Might I suggest a serious solution for D? Since changing the current default MIGHT break some code - I don't know - but it might, so just in case it does, it would be unwise to change things too drastically. *BUT* ... this is a good case for a pragma. Like this:

pragma(leading_zero_radix, 0);    // THE DEFAULT. Makes leading zeroes illegal.
pragma(leading_zero_radix, 8);    // Compatibility with C etc
pragma(leading_zero_radix, 10);   // The way I would want it

This way, those of us who prefer not to use octal could simply stick that pragma in our source code and not have to worry about it. Old code would fail to compile until the author explicitly specified the radix of leading zeroes.

Arcane Jill

Arcane Jill wrote:
>>>I would be in favour of the following valid forms
>>>
>>>   0x90AB    -    hex
>>>   0d7890    -    decimal
>>>   0o6701    -    octal
>>>   0b1010    -    binary
>>>
>>>_and_
>>>
>>>   7890        -    decimal
>>>
>>I'm for it too! (+1)
> 
> 
> Adding my support to this one.

Any mine! I think introducing consistent prefixes is definitely the right thing to do.

> Might I suggest a serious solution for D? Since changing the current default
> MIGHT break some code - I don't know - but it might, so just in case it does, it
> would be unwise to change things too drastically. *BUT* ... this is a good case
> for a pragma. Like this:

Well, if literals starting with 0 are an error then this would be the best kind of code-breaking. There will be no hard-to-find mistakes or compiler-programmer misunderstandings. You simply compile the file, see that the compiler complains about 0123 literals and then fix them to 0o123.

No real need for a pragma.

Hauke

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

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c91veq$1i5q$1@digitaldaemon.com...
> >In article <c90oc6$2r0n$1@digitaldaemon.com>, Matthew says...
> >>I would be in favour of the following valid forms
> >>
> >>    0x90AB    -    hex
> >>    0d7890    -    decimal
> >>    0o6701    -    octal
> >>    0b1010    -    binary
> >>
> >>_and_
> >>
> >>    7890        -    decimal
> >>
> In article <c90sos$30pc$1@digitaldaemon.com>, David L. Davis says...
> >I'm for it too! (+1)
>
> Adding my support to this one.
>
> I wrote my big integer constructors before I read this thread. They can be initialized from a string (with, for example, "123" constructing 123, because integer literals aren't always big enough). I hadn't read this thread when I decided, independently, that such initializing strings would allow the
following
> prefixes:
>
> >    0x or 0X    -    hex
> >    0d or 0D    -    decimal
> >    0o or 0O    -    octal
> >    0b or 0B    -    binary
>
> Leading zeroes don't mean octal in my scheme. I worried about this for a
while -
> being inconsistent with the general rule of C, C++, D, etc., but in the end I just though "Hell - precedent is wrong. Do it right".
>
> On this planet, most programmers are humans, and mostly use base ten. The default should therefore be base ten.
>
> Might I suggest a serious solution for D? Since changing the current default MIGHT break some code - I don't know - but it might, so just in case it does,
it
> would be unwise to change things too drastically. *BUT* ... this is a good case for a pragma. Like this:
>
> pragma(leading_zero_radix, 0);    // THE DEFAULT. Makes leading zeroes illegal.
> pragma(leading_zero_radix, 8);    // Compatibility with C etc
> pragma(leading_zero_radix, 10);   // The way I would want it
>
> This way, those of us who prefer not to use octal could simply stick that
pragma
> in our source code and not have to worry about it. Old code would fail to compile until the author explicitly specified the radix of leading zeroes.

Absolutely not. This helps the D cause for robustness and simplicity not one whit.

The only way forward on this is to render 0XYZ invalid. Otherwise, we must just live with what we have.

Sorry.

Matthew

If the form of numbers change, I also suggest that hex be prefixed with 0h rather than 0x.

'h' for hex, 'd' for decimal, 'o' for octal, 'b' for binary

In article <c925k0$1qs6$3@digitaldaemon.com>, Matthew says...
>
>
>"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c91veq$1i5q$1@digitaldaemon.com...
>> >In article <c90oc6$2r0n$1@digitaldaemon.com>, Matthew says...
>> >>I would be in favour of the following valid forms
>> >>
>> >>    0x90AB    -    hex
>> >>    0d7890    -    decimal
>> >>    0o6701    -    octal
>> >>    0b1010    -    binary
>> >>
>> >>_and_
>> >>
>> >>    7890        -    decimal
>> >>
>> In article <c90sos$30pc$1@digitaldaemon.com>, David L. Davis says...
>> >I'm for it too! (+1)
>>
>> Adding my support to this one.
>>
>> I wrote my big integer constructors before I read this thread. They can be initialized from a string (with, for example, "123" constructing 123, because integer literals aren't always big enough). I hadn't read this thread when I decided, independently, that such initializing strings would allow the
>following
>> prefixes:
>>
>> >    0x or 0X    -    hex
>> >    0d or 0D    -    decimal
>> >    0o or 0O    -    octal
>> >    0b or 0B    -    binary
>>
>> Leading zeroes don't mean octal in my scheme. I worried about this for a
>while -
>> being inconsistent with the general rule of C, C++, D, etc., but in the end I just though "Hell - precedent is wrong. Do it right".
>>
>> On this planet, most programmers are humans, and mostly use base ten. The default should therefore be base ten.
>>
>> Might I suggest a serious solution for D? Since changing the current default MIGHT break some code - I don't know - but it might, so just in case it does,
>it
>> would be unwise to change things too drastically. *BUT* ... this is a good case for a pragma. Like this:
>>
>> pragma(leading_zero_radix, 0);    // THE DEFAULT. Makes leading zeroes illegal.
>> pragma(leading_zero_radix, 8);    // Compatibility with C etc
>> pragma(leading_zero_radix, 10);   // The way I would want it
>>
>> This way, those of us who prefer not to use octal could simply stick that
>pragma
>> in our source code and not have to worry about it. Old code would fail to compile until the author explicitly specified the radix of leading zeroes.
>
>Absolutely not. This helps the D cause for robustness and simplicity not one whit.
>
>The only way forward on this is to render 0XYZ invalid. Otherwise, we must just live with what we have.
>
>Sorry.
>
>Matthew
>
>

In article <c90oc6$2r0n$1@digitaldaemon.com>, Matthew says...
>
>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

I agree.  The standard leading zero notation for octal is misleading.  I'd much prefer an obvious and consistent scheme like the one you describe.


Sean

>>> >    0o or 0O    -    octal

Don't allow uppercase, it is less easily distinguishable.

Also, why not have it be a suffix? Have it match the printf directives? That would add to consistency, yes?

In article <c91veq$1i5q$1@digitaldaemon.com>, Arcane Jill says...
>
>>In article <c90oc6$2r0n$1@digitaldaemon.com>, Matthew says...
>>>I would be in favour of the following valid forms
>>>
>>>    0x90AB    -    hex
>>>    0d7890    -    decimal
>>>    0o6701    -    octal
>>>    0b1010    -    binary
>>>
>>>_and_
>>>
>>>    7890        -    decimal
>>>
>In article <c90sos$30pc$1@digitaldaemon.com>, David L. Davis says...
>>I'm for it too! (+1)
>
>Adding my support to this one.
>
>I wrote my big integer constructors before I read this thread. They can be initialized from a string (with, for example, "123" constructing 123, because integer literals aren't always big enough). I hadn't read this thread when I decided, independently, that such initializing strings would allow the following prefixes:
>
>>    0x or 0X    -    hex
>>    0d or 0D    -    decimal
>>    0o or 0O    -    octal
>>    0b or 0B    -    binary
>

Er... "0O" is octal?  I think this would be as error prone as leading zero.

May I suggest "0c" (zero-cee)?

Kevin

"Arcane Jill" <Arcane_member@pathlink.com> wrote
> Might I suggest a serious solution for D? Since changing the current
default
> MIGHT break some code - I don't know - but it might, so just in case it
does, it
> would be unwise to change things too drastically. *BUT* ... this is a good
case
> for a pragma. Like this:
>
> pragma(leading_zero_radix, 0);    // THE DEFAULT. Makes leading zeroes
illegal.
> pragma(leading_zero_radix, 8);    // Compatibility with C etc
> pragma(leading_zero_radix, 10);   // The way I would want it


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

"Juan C" <Juan_member@pathlink.com> wrote in message news:c92eb1$282a$1@digitaldaemon.com...
> >>> >    0o or 0O    -    octal
> Also, why not have it be a suffix?

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