www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Octals

reply 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?
May 24 2004
next sibling parent "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.
May 24 2004
prev sibling next sibling parent reply 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?

May 24 2004
next sibling parent 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?


May 24 2004
prev sibling parent reply 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
May 25 2004
next sibling parent reply 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
May 25 2004
next sibling parent reply 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?
May 25 2004
parent 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?

May 25 2004
prev sibling parent 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
May 25 2004
prev sibling parent reply "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

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

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

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

 rewritten anyway IMHO).

I run into it just often enough.
May 25 2004
parent reply "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


 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

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

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

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

 rewritten anyway IMHO).

I run into it just often enough.

May 25 2004
parent reply 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?
 

May 25 2004
parent reply "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?


May 25 2004
next sibling parent reply 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?



May 25 2004
parent reply 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?




May 25 2004
parent "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



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. :)
May 25 2004
prev sibling next sibling parent reply 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?



May 25 2004
parent reply 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


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
May 26 2004
next sibling parent 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


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
May 26 2004
prev sibling next sibling parent reply "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


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

 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

 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,

 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

 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
May 26 2004
parent reply 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


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

 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

 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,

 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

 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

May 26 2004
parent reply 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?
May 26 2004
parent "Walter" <newshound digitalmars.com> writes:
"Juan C" <Juan_member pathlink.com> wrote in message
news:c92eb1$282a$1 digitaldaemon.com...
    0o or 0O    -    octal





Makes it harder and slower to lex - numeric literals would need to be scanned twice.
May 26 2004
prev sibling next sibling parent 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


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
May 26 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote
 Might I suggest a serious solution for D? Since changing the current

 MIGHT break some code - I don't know - but it might, so just in case it

 would be unwise to change things too drastically. *BUT* ... this is a good

 for a pragma. Like this:

 pragma(leading_zero_radix, 0);    // THE DEFAULT. Makes leading zeroes

 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>.
May 26 2004
parent reply 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
May 26 2004
parent "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

 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 wouldn't work - how could you tell whether FFFFh (or FFFFx) was a

 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

Even if I don't agree with them, your posts are well written, interesting, and welcome.
May 27 2004
prev sibling next sibling parent reply 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

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.
May 26 2004
parent reply "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


 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

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.
May 26 2004
parent reply 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


 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

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
May 26 2004
next sibling parent 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
May 26 2004
prev sibling parent "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


 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

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


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!
May 26 2004
prev sibling next sibling parent reply 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
May 26 2004
parent reply "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

 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.
May 26 2004
next sibling parent 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.
May 26 2004
prev sibling next sibling parent reply "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.


 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,

 manuals, data sheets, etc.

May 26 2004
next sibling parent reply "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.


 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,

 manuals, data sheets, etc.


May 26 2004
parent "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++


 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


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


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


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


 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




 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



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

 manuals, data sheets, etc.



May 26 2004
prev sibling parent reply 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.
May 26 2004
parent reply 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. ;)
May 26 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 davepermen: You're really not helping this debate with all the bad language

 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. ;)
May 26 2004
prev sibling parent 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
May 27 2004
prev sibling parent "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

 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.
May 26 2004
prev sibling parent reply "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

 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



 to remember that 0 in front fucks up my numbers.

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

 others?



May 26 2004
parent reply "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?
May 26 2004
parent "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?

May 26 2004
prev sibling parent reply 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)
May 24 2004
parent 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.
May 25 2004