• DemmeGod (4/4) May 24 2004 From the specs:
• Walter (3/7) May 24 2004 Yes.
• Stephan Wienczny (8/13) May 24 2004 An octal looks like this
• DemmeGod (6/24) May 24 2004 From Specs:
• Roberto Mariottini (9/15) May 25 2004 BTW, what about deprecating octals starting with 0?
• Andy Friesen (7/29) May 25 2004 Octal numbers still have their uses here and there. (like Unix file
• Juan C (2/5) May 25 2004 I like that, but don't you nean 0o10 == 8 (decimal)? And then mightn't ...
• Stephan Wienczny (7/16) May 25 2004 The leading 0 makes it easier to lex.
• Hauke Duden (7/13) May 25 2004 I like that.
• Walter (7/15) May 25 2004 That's why I don't want to change it - the subtle break in semantics.
• davepermen (10/27) May 25 2004 i'd prefer to break it. i had more subtle breaks of my code because i fo...
• Stephan Wienczny (2/12) May 25 2004
• Matthew (11/23) May 25 2004 depends whether unprefixed numbers still represent decimal, or are now e...
• Juan C (2/26) May 25 2004
• Andrew Edwards (3/43) May 25 2004 What about:
• Matthew (5/25) May 25 2004 errors.
• David L. Davis (2/26) May 25 2004 I'm for it too! (+1)
• Arcane Jill (23/40) May 26 2004 Adding my support to this one.
• Hauke Duden (9/28) May 26 2004 Any mine! I think introducing consistent prefixes is definitely the
• Matthew (12/51) May 26 2004 following
• at0mic (4/63) May 26 2004 If the form of numbers change, I also suggest that hex be prefixed with ...
• Juan C (3/4) May 26 2004 Don't allow uppercase, it is less easily distinguishable.
• Walter (4/6) May 26 2004 Makes it harder and slower to lex - numeric literals would need to be
• Kevin Bealer (4/28) May 26 2004 Er... "0O" is octal? I think this would be as error prone as leading ze...
• Walter (13/20) May 26 2004 does, it
• Arcane Jill (18/26) May 26 2004 Yes, I was wrong. It happens. I guess I was just trying to keep everyone...
• Walter (12/18) May 27 2004 happy
• Stewart Gordon (8/22) May 26 2004
• Matthew (5/23) May 26 2004 errors.
• Kevin Bealer (4/29) May 26 2004 I'd like to ask for an exception for an octal number I use all the time:...
• Andy Friesen (4/14) May 26 2004 Better to be explicit and say that you want 0 octal. (as opposed to hex
• Matthew (5/36) May 26 2004 it's
• Sean Kelly (4/13) May 26 2004 I agree. The standard leading zero notation for octal is misleading. I...
• Walter (6/8) May 26 2004 much
• Juan C (2/5) May 26 2004 I have a couple of Microsoft books around here which use things like 0F...
• davepermen (19/27) May 26 2004 its only standart as you defined so.
• Matthew (3/34) May 26 2004 A bit strongly expressed, but I think you've hit the nail on the head. :...
• davepermen (13/58) May 26 2004 he just dropped support for old style casts, and still wants support for
• Juan C (3/8) May 26 2004 Exactly! If you're creating a _new_language that fixes the flaws in C/C+...
• David L. Davis (26/26) May 26 2004 davepermen: You're really not helping this debate with all the bad langu...
• Matthew (5/10) May 26 2004 I've just been watching some Sopranos on DVD, so davepermen's S&F seems ...
• Roberto Mariottini (29/47) May 27 2004 Well, apart from the standard in C (inherited in C++ and Java), I've nev...
• Matthew (6/14) May 26 2004 But it's comparatively rare - I'd suspect it would be the rarest used in...
• davepermen (7/31) May 26 2004 thats why i put (==NUMBER) behind 0xNUMBER..
• Matthew (2/5) May 26 2004 Sorry, mate. It's early.
• davepermen (5/12) May 26 2004 NUMBER == any number (do a string replace with 12345.. :D
• Mike Swieton (9/14) May 24 2004 Why not try it?
• Stewart Gordon (13/18) May 25 2004 Depends on whether D compiler and Internet connection are in the same

DemmeGod <me demmegod.com> writes:

From the specs:
" Octal integers are a sequence of octal digits preceded by a '0'."

I wanted to verify that octal is represented by digits preceded by a zero,
as the spec says.  Is this true?

"Walter" <newshound digitalmars.com> writes:

"DemmeGod" <me demmegod.com> wrote in message
news:pan.2004.05.25.01.03.32.701233 demmegod.com...
 From the specs:
 " Octal integers are a sequence of octal digits preceded by a '0'."

 I wanted to verify that octal is represented by digits preceded by a zero,
 as the spec says.  Is this true?

Yes.

Stephan Wienczny <wienczny web.de> writes:

An octal looks like this

01
07
0123

or this

\1 \7 \123

By the way you don't believe Walter?

DemmeGod wrote:
 From the specs:
 " Octal integers are a sequence of octal digits preceded by a '0'."
 
 I wanted to verify that octal is represented by digits preceded by a zero,
 as the spec says.  Is this true?

DemmeGod <me demmegod.com> writes:

From Specs:
"	Octal:
		0 OctalDigits"

That zero looked like an uppercase 'o' in my browser.  Just wanted to make
sure.

On Tue, 25 May 2004 03:11:50 +0200, Stephan Wienczny wrote:

 An octal looks like this
 
 01
 07
 0123
 
 or this
 
 \1 \7 \123
 
 By the way you don't believe Walter?
 
 DemmeGod wrote:
 From the specs:
 " Octal integers are a sequence of octal digits preceded by a '0'."
 
 I wanted to verify that octal is represented by digits preceded by a
 zero, as the spec says.  Is this true?

Roberto Mariottini <Roberto_member pathlink.com> writes:

An octal looks like this

01
07
0123

or this

\1 \7 \123

BTW, what about deprecating octals starting with 0?

I keep winning bets with C and C++ programmers about 010 == 8 (some old C
compilers accepted 010 == 08), but it's a bit annoying.
Many beginners start aligning numbers with leading 0s just to discover that it
doesn't work for historical reasons unknown to the most.

Moreover I don't see any practical use for octal numbers nowadays, and I don't
think it's worth supporting them for very old legacy C code (that has to be
rewritten anyway IMHO).

Ciao

Andy Friesen <andy ikagames.com> writes:

Roberto Mariottini wrote:

An octal looks like this

01
07
0123

or this

\1 \7 \123

 
 
 BTW, what about deprecating octals starting with 0?
 
 I keep winning bets with C and C++ programmers about 010 == 8 (some old C
 compilers accepted 010 == 08), but it's a bit annoying.
 Many beginners start aligning numbers with leading 0s just to discover that it
 doesn't work for historical reasons unknown to the most.
 
 Moreover I don't see any practical use for octal numbers nowadays, and I don't
 think it's worth supporting them for very old legacy C code (that has to be
 rewritten anyway IMHO).

Octal numbers still have their uses here and there. (like Unix file 
permission attributes)

I wouldn't be against changing the syntax, though.  How about 0o10 == 
10?  It's somewhat symmetrical with the 0x hex notation, and is clearly 
not a decimal integer.

  -- andy

Juan C <Juan_member pathlink.com> writes:

I wouldn't be against changing the syntax, though.  How about 0o10 == 
10?  It's somewhat symmetrical with the 0x hex notation, and is clearly 
not a decimal integer.

I like that, but don't you nean  0o10 == 8 (decimal)? And then mightn't it be
possible to remove that leading zero from these and hexes as redundant?

Stephan Wienczny <wienczny web.de> writes:

The leading 0 makes it easier to lex.
If you find a 0 you know it will be a number. If you only had o what 
would you do in this case:

o123

This is an valid identifier and if we drop the 0 a valid number ;-(

Stephan

Juan C wrote:

I wouldn't be against changing the syntax, though.  How about 0o10 == 
10?  It's somewhat symmetrical with the 0x hex notation, and is clearly 
not a decimal integer.

 
 
 I like that, but don't you nean  0o10 == 8 (decimal)? And then mightn't it be
 possible to remove that leading zero from these and hexes as redundant?
 
 

Hauke Duden <H.NS.Duden gmx.net> writes:

Andy Friesen wrote:
 Octal numbers still have their uses here and there. (like Unix file 
 permission attributes)
 
 I wouldn't be against changing the syntax, though.  How about 0o10 == 
 10?  It's somewhat symmetrical with the 0x hex notation, and is clearly 
 not a decimal integer.

I like that.

Never quite warmed up to the idea that two ways to write the same number 
(mathematically speaking) produce a different result in D (e.g. 0042 is 
octal and 42 is decimal). 0o solves that. The consistency with 0x is a 
also a nice property.

Hauke

"Walter" <newshound digitalmars.com> writes:

"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:c8utl4$2u71$1 digitaldaemon.com...
 BTW, what about deprecating octals starting with 0?

 I keep winning bets with C and C++ programmers about 010 == 8 (some old C
 compilers accepted 010 == 08), but it's a bit annoying.

That's why I don't want to change it - the subtle break in semantics.

 Many beginners start aligning numbers with leading 0s just to discover

that it
 doesn't work for historical reasons unknown to the most.

 Moreover I don't see any practical use for octal numbers nowadays, and I

don't
 think it's worth supporting them for very old legacy C code (that has to

be
 rewritten anyway IMHO).

I run into it just often enough.

"davepermen" <davepermen hotmail.com> writes:

i'd prefer to break it. i had more subtle breaks of my code because i forgot
to remember that 0 in front fucks up my numbers.

0xNUMBER == hex
0dNUMBER == dec (==NUMBER)
0oNUMBER == oct
0bNUMBER == binary

others?

"Walter" <newshound digitalmars.com> schrieb im Newsbeitrag
news:c90127$1mi3$2 digitaldaemon.com...
 "Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
 news:c8utl4$2u71$1 digitaldaemon.com...
 BTW, what about deprecating octals starting with 0?

 I keep winning bets with C and C++ programmers about 010 == 8 (some old


C
 compilers accepted 010 == 08), but it's a bit annoying.

 That's why I don't want to change it - the subtle break in semantics.

 Many beginners start aligning numbers with leading 0s just to discover

 that it
 doesn't work for historical reasons unknown to the most.

 Moreover I don't see any practical use for octal numbers nowadays, and I

 don't
 think it's worth supporting them for very old legacy C code (that has to

 be
 rewritten anyway IMHO).

 I run into it just often enough.

Stephan Wienczny <wienczny web.de> writes:

That shouldn't be a problem to implement. Do we want that?

davepermen wrote:
 i'd prefer to break it. i had more subtle breaks of my code because i forgot
 to remember that 0 in front fucks up my numbers.
 
 0xNUMBER == hex
 0dNUMBER == dec (==NUMBER)
 0oNUMBER == oct
 0bNUMBER == binary
 
 others?
 

"Matthew" <matthew.hat stlsoft.dot.org> writes:

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

"Stephan Wienczny" <wienczny web.de> wrote in message
news:c90ckl$28pr$1 digitaldaemon.com...
 That shouldn't be a problem to implement. Do we want that?

 davepermen wrote:
 i'd prefer to break it. i had more subtle breaks of my code because i forgot
 to remember that 0 in front fucks up my numbers.

 0xNUMBER == hex
 0dNUMBER == dec (==NUMBER)
 0oNUMBER == oct
 0bNUMBER == binary

 others?

Juan C <Juan_member pathlink.com> writes:

Works fer me.


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

"Stephan Wienczny" <wienczny web.de> wrote in message
news:c90ckl$28pr$1 digitaldaemon.com...
 That shouldn't be a problem to implement. Do we want that?

 davepermen wrote:
 i'd prefer to break it. i had more subtle breaks of my code because i forgot
 to remember that 0 in front fucks up my numbers.

 0xNUMBER == hex
 0dNUMBER == dec (==NUMBER)
 0oNUMBER == oct
 0bNUMBER == binary

 others?

Andrew Edwards <ridimz_at yahoo.dot.com> writes:

Juan C wrote:
 Works fer me.
 
 
 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


What about:

      0u3091    -    unicode

With 06701 for octal being invalid

"Stephan Wienczny" <wienczny web.de> wrote in message
news:c90ckl$28pr$1 digitaldaemon.com...

That shouldn't be a problem to implement. Do we want that?

davepermen wrote:

i'd prefer to break it. i had more subtle breaks of my code because i forgot
to remember that 0 in front fucks up my numbers.

0xNUMBER == hex
0dNUMBER == dec (==NUMBER)
0oNUMBER == oct
0bNUMBER == binary

others?



 
 

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Andrew Edwards" <ridimz_at yahoo.dot.com> wrote in message
news:c90po8$2soc$1 digitaldaemon.com...
 Juan C wrote:
 Works fer me.


 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


 What about:

       0u3091    -    unicode

Not sure what that would do? Is it a character? What base is it in?

I'm not saying I don't like it. Just need to understand it more. :)

David L. Davis <David_member pathlink.com> writes:

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

"Stephan Wienczny" <wienczny web.de> wrote in message
news:c90ckl$28pr$1 digitaldaemon.com...
 That shouldn't be a problem to implement. Do we want that?

 davepermen wrote:
 i'd prefer to break it. i had more subtle breaks of my code because i forgot
 to remember that 0 in front fucks up my numbers.

 0xNUMBER == hex
 0dNUMBER == dec (==NUMBER)
 0oNUMBER == oct
 0bNUMBER == binary

 others?



I'm for it too! (+1)

Arcane Jill <Arcane_member pathlink.com> writes:

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

Hauke Duden <H.NS.Duden gmx.net> writes:

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

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"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

at0mic <at0mic_member pathlink.com> writes:

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

Juan C <Juan_member pathlink.com> writes:

    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?

"Walter" <newshound digitalmars.com> writes:

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

Kevin Bealer <Kevin_member pathlink.com> writes:

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

"Walter" <newshound digitalmars.com> writes:

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

Arcane Jill <Arcane_member pathlink.com> writes:

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

"Walter" <newshound digitalmars.com> writes:

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

Stewart Gordon <smjg_1998 yahoo.com> writes:

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.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.

"Matthew" <matthew.hat stlsoft.dot.org> writes:

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

Kevin Bealer <Kevin_member pathlink.com> writes:

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

Andy Friesen <andy ikagames.com> writes:

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

"Matthew" <matthew.hat stlsoft.dot.org> writes:

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

Sean Kelly <sean f4.ca> writes:

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

"Walter" <newshound digitalmars.com> writes:

"Sean Kelly" <sean f4.ca> wrote in message
news:c92blc$23vu$1 digitaldaemon.com...
 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.

But, as you say, it's "standard". This common notation for octal numbers
goes beyond C; it's used in other languages and in assembly language, system
manuals, data sheets, etc.

Juan C <Juan_member pathlink.com> writes:

But, as you say, it's "standard". This common notation for octal numbers
goes beyond C; it's used in other languages and in assembly language, system
manuals, data sheets, etc.

I have a couple of Microsoft books around here which use things like  0Fh  --
which apparently is 15 in hex. But that's Microsoft for ya.

"davepermen" <davepermen hotmail.com> writes:

its only standart as you defined so.

heck, reimplement the ; after struct X {} and class X {}, thats how c++ does
it!

and drop the gc!

and all the other stuff you changed!

this is minor, but its a bad design that should finally got rid of!

i mean really, who invented that shit? its the worst design style ever 0100
!= 100. NEVER..

make it an error, and you're done.. so you have to write 0d0100 == 100 ==
_100..

nothing is standart in D. its your choise. be wise, don't follow useless old
habbits. you kill your language with such things. newbies hate such flaws (i
did in c++), and people who know the languages with the bug, will be glad to
get rid of.

believe me.

"Walter" <newshound digitalmars.com> schrieb im Newsbeitrag
news:c92vs3$2i9$3 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message
 news:c92blc$23vu$1 digitaldaemon.com...
 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.

 But, as you say, it's "standard". This common notation for octal numbers
 goes beyond C; it's used in other languages and in assembly language,

system
 manuals, data sheets, etc.

"Matthew" <matthew.hat stlsoft.dot.org> writes:

A bit strongly expressed, but I think you've hit the nail on the head. :-)

"davepermen" <davepermen hotmail.com> wrote in message
news:c93249$6cm$1 digitaldaemon.com...
 its only standart as you defined so.

 heck, reimplement the ; after struct X {} and class X {}, thats how c++ does
 it!

 and drop the gc!

 and all the other stuff you changed!

 this is minor, but its a bad design that should finally got rid of!

 i mean really, who invented that shit? its the worst design style ever 0100
 != 100. NEVER..

 make it an error, and you're done.. so you have to write 0d0100 == 100 ==
 _100..

 nothing is standart in D. its your choise. be wise, don't follow useless old
 habbits. you kill your language with such things. newbies hate such flaws (i
 did in c++), and people who know the languages with the bug, will be glad to
 get rid of.

 believe me.

 "Walter" <newshound digitalmars.com> schrieb im Newsbeitrag
 news:c92vs3$2i9$3 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message
 news:c92blc$23vu$1 digitaldaemon.com...
 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.

 But, as you say, it's "standard". This common notation for octal numbers
 goes beyond C; it's used in other languages and in assembly language,

 system
 manuals, data sheets, etc.

"davepermen" <davepermen hotmail.com> writes:

he just dropped support for old style casts, and still wants support for
that piece of shit-relict. i mean, what USE does it have?

casts at least gave something that was useful...


"Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag
news:c932t5$7gk$2 digitaldaemon.com...
 A bit strongly expressed, but I think you've hit the nail on the head. :-)

 "davepermen" <davepermen hotmail.com> wrote in message
 news:c93249$6cm$1 digitaldaemon.com...
 its only standart as you defined so.

 heck, reimplement the ; after struct X {} and class X {}, thats how c++


does
 it!

 and drop the gc!

 and all the other stuff you changed!

 this is minor, but its a bad design that should finally got rid of!

 i mean really, who invented that shit? its the worst design style ever


0100
 != 100. NEVER..

 make it an error, and you're done.. so you have to write 0d0100 == 100


==
 _100..

 nothing is standart in D. its your choise. be wise, don't follow useless


old
 habbits. you kill your language with such things. newbies hate such


flaws (i
 did in c++), and people who know the languages with the bug, will be


glad to
 get rid of.

 believe me.

 "Walter" <newshound digitalmars.com> schrieb im Newsbeitrag
 news:c92vs3$2i9$3 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message
 news:c92blc$23vu$1 digitaldaemon.com...
 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.

 But, as you say, it's "standard". This common notation for octal



numbers
 goes beyond C; it's used in other languages and in assembly language,

 system
 manuals, data sheets, etc.

Juan C <Juan_member pathlink.com> writes:

this is minor, but its a bad design that should finally got rid of!

nothing is standart in D. its your choise. be wise, don't follow useless old
habbits. you kill your language with such things. newbies hate such flaws (i
did in c++), and people who know the languages with the bug, will be glad to
get rid of.


Exactly! If you're creating a _new_language that fixes the flaws in C/C++, then
just _do_ it (place swoosh here)! And not just half way or someone else will
come along and trump you next year, rather than ten years from now.

David L. Davis <David_member pathlink.com> writes:

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

"Matthew" <matthew.hat stlsoft.dot.org> writes:

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

Roberto Mariottini <Roberto_member pathlink.com> writes:

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

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:c92vs3$2i9$3 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message
 news:c92blc$23vu$1 digitaldaemon.com...
 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.

 But, as you say, it's "standard". This common notation for octal numbers
 goes beyond C; it's used in other languages and in assembly language, system
 manuals, data sheets, etc.

But it's comparatively rare - I'd suspect it would be the rarest used in D. And
an overt breaking change is pretty easy to cope with.

I really think D should step out of the closet here and declare that everyone
else is wrong, and lead the way to the right path.

"davepermen" <davepermen hotmail.com> writes:

thats why i put (==NUMBER) behind 0xNUMBER..

means without prefix works as well..

and 0NUMBER == NUMBER, too.. unlike c-shit

"Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag
news:c90oc6$2r0n$1 digitaldaemon.com...
 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

 "Stephan Wienczny" <wienczny web.de> wrote in message
 news:c90ckl$28pr$1 digitaldaemon.com...
 That shouldn't be a problem to implement. Do we want that?

 davepermen wrote:
 i'd prefer to break it. i had more subtle breaks of my code because i



forgot
 to remember that 0 in front fucks up my numbers.

 0xNUMBER == hex
 0dNUMBER == dec (==NUMBER)
 0oNUMBER == oct
 0bNUMBER == binary

 others?

"Matthew" <matthew.hat stlsoft.dot.org> writes:

 thats why i put (==NUMBER) behind 0xNUMBER..

 means without prefix works as well..

 and 0NUMBER == NUMBER, too.. unlike c-shit

Sorry, mate. It's early.

Can you explain that one again?

"davepermen" <davepermen hotmail.com> writes:

NUMBER == any number (do a string replace with 12345.. :D

i've written decimal: 0d12345 (==12345)

here, its fucking late.. need sleep now

"Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag
news:c932t4$7gk$1 digitaldaemon.com...
 thats why i put (==NUMBER) behind 0xNUMBER..

 means without prefix works as well..

 and 0NUMBER == NUMBER, too.. unlike c-shit

 Sorry, mate. It's early.

 Can you explain that one again?

Mike Swieton <mike swieton.net> writes:

On Mon, 24 May 2004 21:03:33 -0400, DemmeGod wrote:

 From the specs:
 " Octal integers are a sequence of octal digits preceded by a '0'."
 
 I wanted to verify that octal is represented by digits preceded by a zero,
 as the spec says.  Is this true?

Why not try it?

int main(char[][] args) { int x = 0777; return 0; }

It'll take a lot less time than posting.

Mike Swieton
__
You can have peace. Or you can have freedom. Don't ever count on having
both at once.
	- Lazarus Long (Robert A. Heinlein)

Stewart Gordon <smjg_1998 yahoo.com> writes:

Mike Swieton wrote:
<snip>
 Why not try it?
 
 int main(char[][] args) { int x = 0777; return 0; }
 
 It'll take a lot less time than posting.

Depends on whether D compiler and Internet connection are in the same 
place, as mine aren't for instance.

But it's also quite simple to c&p stuff from a typical browser into 
something that lets you see it in a font that clearly distinguishes O 
and 0.  (Of course, messing with browser settings also tends to work, 
though not always.)

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.