www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is the world coming to an end?

reply Andrej Mitrovic <none none.none> writes:
https://github.com/D-Programming-Language/phobos/commit/83f99df573c089cc186ef370cb691c2f8a25c873
https://github.com/D-Programming-Language/phobos/commit/88904f7795a94b23e750e10a2addc90783089de7

If I didn't know it better I would think it's still April 1st. :D
Apr 02 2011
next sibling parent =?UTF-8?B?QWxla3NhbmRhciBSdcW+acSNacSH?= <ruzicic.aleksandar gmail.com> writes:
Nice to see awkward octal literal syntax being removed from Phobos! :)

On Sat, Apr 2, 2011 at 10:16 PM, Andrej Mitrovic <none none.none> wrote:

 https://github.com/D-Programming-Language/phobos/commit/83f99df573c089cc186ef370cb691c2f8a25c873
 https://github.com/D-Programming-Language/phobos/commit/88904f7795a94b23e750e10a2addc90783089de7

 If I didn't know it better I would think it's still April 1st. :D
Apr 02 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 If I didn't know it better I would think it's still April 1st. :D


I don't like the "octal!" a lot, I prefer a syntax like the Python3 one, but
Walter never stops moving himself forward :-)

Bye,
bearophile
Apr 02 2011
next sibling parent Mafi <mafi example.org> writes:
Am 02.04.2011 23:38, schrieb bearophile:

 Andrej Mitrovic:


 If I didn't know it better I would think it's still April 1st. :D


 I don't like the "octal!" a lot, I prefer a syntax like the Python3 one, but
Walter never stops moving himself forward :-)

 Bye,
 bearophile


No ofence, but I sometimes get the opinion that you think something is 
better just because there's "Python" written on it.
But sure, syntaxes are a matter of taste and people shouldn't dispute 
about tastes.

Mafi

PS I don't want to say every of Python's decisions is wrong. Many of 
them are great (but defenitely not significant intendation).
Apr 02 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 02.04.2011 23:38, schrieb bearophile:

 Andrej Mitrovic:
 

 If I didn't know it better I would think it's still April 1st. :D


 
 I don't like the "octal!" a lot, I prefer a syntax like the Python3 one, 


Come on: the C-style octal syntax is bad (see [1]) and can lead to strange bugs,
so it's a huge win that it's finally killed, even if you don't like the new
syntax :-)
In general octal numbers are rarely needed (I guess), so the somehow clumsy
octal!123 syntax doesn't matter. Also it's more readable (self-documenting) for
someone not used to octal numbers than Python3's 0o123.

Also congratulations to spir, I guess his "0nnn octal notation considered
harmful" thread[1] was a good argument for this step :-)


Cheers,
- Daniel

[1]
http://www.digitalmars.com/d/archives/digitalmars/D/0nnn_octal_notation_considered_harmful_129416.html
Apr 02 2011
next sibling parent reply ulrik.mikaelsson gmail.com writes:
About time someone dropped the 0777-nonsense. The least common digit-base  
should not easily be invoked "by accident".

However:



 I don't like the "octal!" a lot, I prefer a syntax like the Python3 one,  
 but Walter never stops moving himself forward :-)


I too was just about to ask why on earth "octal!" instead of 0o (and I  
didn't know about Python3).

Sure, I think it's nice and clean language-wise to implement it as a  
template-function, but if so the same should go for 0b and 0x? Are they too  
deprecated in D2?
Apr 02 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 00:00, schrieb ulrik.mikaelsson gmail.com:

 About time someone dropped the 0777-nonsense. The least common digit-base
should
 not easily be invoked "by accident".
 
 However:
 
 

 I don't like the "octal!" a lot, I prefer a syntax like the Python3 one, but
 Walter never stops moving himself forward :-)


 
 I too was just about to ask why on earth "octal!" instead of 0o (and I didn't
 know about Python3).
 
 Sure, I think it's nice and clean language-wise to implement it as a
 template-function, but if so the same should go for 0b and 0x? Are they too
 deprecated in D2?
 


0b and 0x are not "dangerous" so there's no need to remove/deprecate them and
thus cause breakage of code using them.
At least 0x is quite common (certainly more common than octal numbers) so it
makes sense to have this short syntax (IMHO).

Cheers,
- Daniel
Apr 02 2011
next sibling parent reply ulrik.mikaelsson gmail.com writes:
 0b and 0x are not "dangerous" so there's no need to remove/deprecate them  
 and



 thus cause breakage of code using them.



 At least 0x is quite common (certainly more common than octal numbers) so  
 it



 makes sense to have this short syntax (IMHO).



As I wrote, I think it's great that 010 != 8 anymore.

I just think that 0o10 would be more consistent with 0x and 0b. Obviously  
the framework is there for parsing the literals, and AFAIK, 0o isn't  
accepted today so no code would be broken.

011 = 11
0b11 = 3
0x11 = 17
0o11 = 9

is much more consistent than

011 = 11
0b11 = 3
0x11 = 17
octal!11 = 9

A D-newbie would probably be able to guess 0o for octal, but hardly octal!.  
octal! breaks the rule of least surprise.

In any case, everything is better than 011 = 9
Apr 02 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Apr 3, 11 06:27, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


Except a big error

     octal literals 011 are deprecated, use std.conv.octal!11 instead

will be emitted when the said newbie tries to compile with 011 :). See 
commit 
https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932
Apr 02 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
On Apr 3, 11 06:49, KennyTM~ wrote:

 On Apr 3, 11 06:27, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 Except a big error

 octal literals 011 are deprecated, use std.conv.octal!11 instead

 will be emitted when the said newbie tries to compile with 011 :). See
 commit
 https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932


But of course

  1. this message is specific to the dmd front-end. Other lexers might
     not show this message
  2. this assumes std.conv.octal exists, though it may not be the case
     (e.g. using Tango without Phobos (well Tango devs could add just
     std.conv.octal)).
Apr 02 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 00:58, schrieb KennyTM~:

 On Apr 3, 11 06:49, KennyTM~ wrote:

 On Apr 3, 11 06:27, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 Except a big error

 octal literals 011 are deprecated, use std.conv.octal!11 instead

 will be emitted when the said newbie tries to compile with 011 :). See
 commit
 https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932


 
 But of course
 
  1. this message is specific to the dmd front-end. Other lexers might
     not show this message
  2. this assumes std.conv.octal exists, though it may not be the case
     (e.g. using Tango without Phobos (well Tango devs could add just
     std.conv.octal)).


If Tango is ever ported to D2 it should be possible to use Phobos and Tango at
the same time (thanks to druntime), so that shouldn't be an issue, right?
Apr 02 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2011 3:58 PM, KennyTM~ wrote:

 1. this message is specific to the dmd front-end. Other lexers might
 not show this message


Appropriate and informative error messages are properly 
quality-of-implementation issues. As the dmd source shows, doing this message
is 
trivial.


 2. this assumes std.conv.octal exists, though it may not be the case
 (e.g. using Tango without Phobos (well Tango devs could add just
 std.conv.octal)).


This change will not migrate to D1.
Apr 02 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
On Apr 3, 11 07:52, Walter Bright wrote:

 On 4/2/2011 3:58 PM, KennyTM~ wrote:

 1. this message is specific to the dmd front-end. Other lexers might
 not show this message


 Appropriate and informative error messages are properly
 quality-of-implementation issues. As the dmd source shows, doing this
 message is trivial.


DMD recognizes the octal literal then rejects it later. Ideally the 
lexer should not accept 0\d{2,} at all.


 2. this assumes std.conv.octal exists, though it may not be the case
 (e.g. using Tango without Phobos (well Tango devs could add just
 std.conv.octal)).


 This change will not migrate to D1.


Yes. I mean Tango for D2 (if it will be finished?)

Anyway the above aren't really big problems. I don't expect newbies know 
octal literals :).
Apr 02 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2011 5:34 PM, KennyTM~ wrote:

 On Apr 3, 11 07:52, Walter Bright wrote:

 On 4/2/2011 3:58 PM, KennyTM~ wrote:

 1. this message is specific to the dmd front-end. Other lexers might
 not show this message


 Appropriate and informative error messages are properly
 quality-of-implementation issues. As the dmd source shows, doing this
 message is trivial.


 DMD recognizes the octal literal then rejects it later. Ideally the lexer
should
 not accept 0\d{2,} at all.


That's for backwards compatibility.


 Yes. I mean Tango for D2 (if it will be finished?)


I hope that Tango for D2 will not have gratuitous incompatibilities.
Apr 02 2011
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-02 18:27:12 -0400, ulrik.mikaelsson gmail.com said:


 011 = 11
 0b11 = 3
 0x11 = 17
 0o11 = 9
 
 is much more consistent than
 
 011 = 11
 0b11 = 3
 0x11 = 17
 octal!11 = 9


I too would prefer 0o11 for consistency.

It's funny that D (the language) has binary notation built-in (which C 
doesn't have) but no octal notation anymore (which C has). You now have 
to resort to a library template for that, and it doesn't work for big 
numbers: try assert(octal!1777777777777777777777 == 
0xFFFF_FFFF_FFFF_FFFF). Not that I expect anyone to want to write big 
64-bit numbers in octal, but it makes the new "official" octal notation 
more like a hack.

But it's a good thing that the old error-prone octal notation is 
deprecated. So overall I think the change is positive, I just find the 
replacement a little too hackish.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 02 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2011 4:11 PM, Michel Fortin wrote:

 It's funny that D (the language) has binary notation built-in (which C doesn't
 have) but no octal notation anymore (which C has).


The problem with the octal literals is, as has been often complained about, 
people getting surprised by it. I've never heard of anyone being surprised by 
the binary or hex literals.


 You now have to resort to a
 library template for that,


I think it's a feature, not a "resort", that library templates can do this
well. 
I think it's far better than C++0x's user defined literals, for example.


 and it doesn't work for big numbers: try
 assert(octal!1777777777777777777777 == 0xFFFF_FFFF_FFFF_FFFF). Not that I
expect
 anyone to want to write big 64-bit numbers in octal, but it makes the new
 "official" octal notation more like a hack.


If you use octal!"1777777777777777777777" it will work correctly. You're right 
in that the decimal literal being "converted" to octal is a bit of a hack.

The octal!1777777777777777777777 will fail at compile time with an integer 
overflow, it never gets to the runtime assert.
Apr 02 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Walter Bright wrote:

 You're right in that the decimal literal being "converted"
 to octal is a bit of a hack.


Yeah, but it's a no-win scenario.

Without it, people would bitch and moan that they have to put
quotes around little numbers like permission masks.

With it, people bitch and moan that its a hack, probably without
ever actually using it.
Apr 02 2011
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-02 19:58:25 -0400, Walter Bright <newshound2 digitalmars.com> said:


 On 4/2/2011 4:11 PM, Michel Fortin wrote:

 It's funny that D (the language) has binary notation built-in (which C doesn't
 have) but no octal notation anymore (which C has).


 
 The problem with the octal literals is, as has been often complained 
 about, people getting surprised by it. I've never heard of anyone being 
 surprised by the binary or hex literals.


Indeed. Isn't that a good argument for implementing octal literals the 
same way as binary and hex literals?



 You now have to resort to a
 library template for that,


 
 I think it's a feature, not a "resort", that library templates can do 
 this well. I think it's far better than C++0x's user defined literals, 
 for example.


I disagree that it's better. With C++ user defined literals the user 
doesn't have to find by himself whether the number fits within the 
range of a regular integer literal and if not fall back to using a 
string as the template argument instead.

I don't think it's much worse, but I fail to see how it could be better.



 and it doesn't work for big numbers: try
 assert(octal!1777777777777777777777 == 0xFFFF_FFFF_FFFF_FFFF). Not that 
 I expect
 anyone to want to write big 64-bit numbers in octal, but it makes the new
 "official" octal notation more like a hack.


 
 If you use octal!"1777777777777777777777" it will work correctly. 
 You're right in that the decimal literal being "converted" to octal is 
 a bit of a hack.
 
 The octal!1777777777777777777777 will fail at compile time with an 
 integer overflow, it never gets to the runtime assert.


Which makes me wonder, what does the compiler suggests in the error 
message when it encounters 01777777777777777777777 ? I suspect it 
doesn't add the necessary quotes, does it?

The new syntax is certainly usable, it's just inelegant and hackish. 
Its your language, it's your choice, and I'll admit it won't affect me 
much.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 02 2011
next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Apr 3, 11 08:30, Michel Fortin wrote:

 On 2011-04-02 19:58:25 -0400, Walter Bright <newshound2 digitalmars.com>
 said:


 On 4/2/2011 4:11 PM, Michel Fortin wrote:

 It's funny that D (the language) has binary notation built-in (which
 C doesn't
 have) but no octal notation anymore (which C has).


 The problem with the octal literals is, as has been often complained
 about, people getting surprised by it. I've never heard of anyone
 being surprised by the binary or hex literals.


 Indeed. Isn't that a good argument for implementing octal literals the
 same way as binary and hex literals?



 You now have to resort to a
 library template for that,


 I think it's a feature, not a "resort", that library templates can do
 this well. I think it's far better than C++0x's user defined literals,
 for example.


 I disagree that it's better. With C++ user defined literals the user
 doesn't have to find by himself whether the number fits within the range
 of a regular integer literal and if not fall back to using a string as
 the template argument instead.


This is a problem but as I'd test it's a non-issue. Running a Google 
code search on   [^.'"-]\b0[0-7]{7,}[ulUL]*\b -0{8,}   shows only two 
instances of real (i.e. not used for testing the format function) usage 
of long (> 7 digits) octal literals in the first few pages:

     037777600000l  in Android's OpenSSL (this is 0xffff_0000L)
     077777777777L  in Apache's ASF (this is 0x1_ffff_ffffL)

Both of them fit inside 2^^63 as decimal digits for octal!(), and both 
of them could better be represented as hex if ported.


 I don't think it's much worse, but I fail to see how it could be better.


Avoiding needing to create another kind of literal?


 and it doesn't work for big numbers: try
 assert(octal!1777777777777777777777 == 0xFFFF_FFFF_FFFF_FFFF). Not
 that I expect
 anyone to want to write big 64-bit numbers in octal, but it makes the
 new
 "official" octal notation more like a hack.


 If you use octal!"1777777777777777777777" it will work correctly.
 You're right in that the decimal literal being "converted" to octal is
 a bit of a hack.

 The octal!1777777777777777777777 will fail at compile time with an
 integer overflow, it never gets to the runtime assert.


 Which makes me wonder, what does the compiler suggests in the error
 message when it encounters 01777777777777777777777 ? I suspect it
 doesn't add the necessary quotes, does it?


There's no quotes, and there should be, but the extra cost for this 
branch may not worth it (the lower limit of quotes depends on whether it 
is a long/unsigned literal).


 The new syntax is certainly usable, it's just inelegant and hackish. Its
 your language, it's your choice, and I'll admit it won't affect me much.
Apr 02 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2011 5:30 PM, Michel Fortin wrote:

 On 2011-04-02 19:58:25 -0400, Walter Bright <newshound2 digitalmars.com> said:

 The problem with the octal literals is, as has been often complained about,
 people getting surprised by it. I've never heard of anyone being surprised by
 the binary or hex literals.


 Indeed. Isn't that a good argument for implementing octal literals the same way
 as binary and hex literals?


Yes, except for something else - the rarity of need for octal literals. The
only 
modern usage I've seen of it is for file permissions.



 I think it's a feature, not a "resort", that library templates can do this
 well. I think it's far better than C++0x's user defined literals, for example.


 I disagree that it's better. With C++ user defined literals the user doesn't
 have to find by himself whether the number fits within the range of a regular
 integer literal and if not fall back to using a string as the template argument
 instead.


I believe that if you attempted to do octal literals using C++0x user defined 
literals, you'd run into exactly the same issue (overflow). See:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf

C++0x user defined literals call a global function, which fails when you have 
more than one definition of the same literal. I.e. you cannot qualify the 
function to resolve ambiguity.

Other complaints about them:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3250.html



 I don't think it's much worse, but I fail to see how it could be better.


Reasons:

1. It is not a language extension
2. Conflicting names are easily resolved
3. More than one argument is possible
4. The full power of CTFE is available to compute it, rather than the very 
limited C++0x constexpr
5. If you read N2765, it's pretty darned hackish. I.e. there's the "raw" and 
"cooked" mode.



 Which makes me wonder, what does the compiler suggests in the error message
when
 it encounters 01777777777777777777777 ? I suspect it doesn't add the necessary
 quotes, does it?


No, it doesn't. The lexer knows nothing about higher level semantics.
Apr 02 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-04-02 at 18:36 -0700, Walter Bright wrote:


 Yes, except for something else - the rarity of need for octal literals. T=


he only=20

 modern usage I've seen of it is for file permissions.


What is the use for binary literals or hexadecimal literals, I can't
think of one.

Except perhaps specification of register save masks and control status
work literals -- which is of course where the octal stuff came from in
the first place in C and when the VAX replaced PDP, hexadecimal was
rapidly introduced. (*)

I would suggest that rather than discriminating against people who like
octal instead of decimal or hexadecimal, the solution of introducing
0o... in harmony with 0b... and 0x... -- and of course removing the
leading 0 octal literal convention -- is obviously the right solution.
It ticks all the boxes.


(*)  For anyone not immediately in the know here PDP had 8 registers and
VAX 16 so octal and hexadecimal were the natural bases for specifying
masks.  The 68000 also played a part.  The use of octal on the PDP
actually goes a lot deeper than this, cf. Unibus,  but it is all ancient
history now.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 03 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/3/2011 12:12 AM, Russel Winder wrote:

 On Sat, 2011-04-02 at 18:36 -0700, Walter Bright wrote:


 Yes, except for something else - the rarity of need for octal literals. The
only
 modern usage I've seen of it is for file permissions.


 What is the use for binary literals or hexadecimal literals, I can't
 think of one.

 Except perhaps specification of register save masks and control status
 work literals -- which is of course where the octal stuff came from in
 the first place in C and when the VAX replaced PDP, hexadecimal was
 rapidly introduced. (*)


I still prefer binary for that. It takes me a senior moment or two to remember 
what bit pattern 0xB is, for example.



 I would suggest that rather than discriminating against people who like
 octal


The phrase "discriminating against people" has a lot of emotional baggage 
associated with it that is irrelevant to this.



 instead of decimal or hexadecimal, the solution of introducing
 0o... in harmony with 0b... and 0x... -- and of course removing the
 leading 0 octal literal convention -- is obviously the right solution.
 It ticks all the boxes.


Except the box of a kitchen sink of features of marginal utility. A feature
that 
can be handled adequately by the library should not be part of the core
language.

And yes, you can make a reasonable case that 0b should be ditched for the same 
reason.
Apr 03 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:in9c9h$134t$1 digitalmars.com...

 On 4/3/2011 12:12 AM, Russel Winder wrote:

 On Sat, 2011-04-02 at 18:36 -0700, Walter Bright wrote:


 Yes, except for something else - the rarity of need for octal literals. 
 The only
 modern usage I've seen of it is for file permissions.


 What is the use for binary literals or hexadecimal literals, I can't
 think of one.

 Except perhaps specification of register save masks and control status
 work literals -- which is of course where the octal stuff came from in
 the first place in C and when the VAX replaced PDP, hexadecimal was
 rapidly introduced. (*)


 I still prefer binary for that. It takes me a senior moment or two to 
 remember what bit pattern 0xB is, for example.


Somtimes I have to wonder if I'm much older than I think I am. I'm exactly 
the same way as you with "moment or two to remember what bit pattern 0xB is, 
for example", and if I'm getting senior moments in my late 20's then 
something is very very wrong ;)
Apr 03 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/3/2011 1:54 AM, Nick Sabalausky wrote:

 Somtimes I have to wonder if I'm much older than I think I am. I'm exactly
 the same way as you with "moment or two to remember what bit pattern 0xB is,
 for example", and if I'm getting senior moments in my late 20's then
 something is very very wrong ;)


You should be fine as long as you're not tying an onion to your belt!
Apr 03 2011
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Walter Bright wrote:

 And yes, you can make a reasonable case that 0b should be ditched
 for the same reason.


I know people already think of the isIntegral versions of octal
as a hack, but I see that as one reason why binary wouldn't work
as well as a template:

binary!1111_1111_0000_0000

Overflow city! Such long numbers aren't terribly common in octal,
but they /are/ in binary.

Of course, you can just use the string version, so it isn't a
big deal, but nevertheless, it is a difference.


btw, it might be worth considering a change to overflow. Suppose
there was a way to get arbitrary size ints passed to a template.
Then, the library could do its own overflow checks, or not, enabling
things like bigint literals in this same fashion.

Though, I don't think it's a big benefit. It'd be really weird
to use (a new compile time only datatype?)

And if you actually need that, the string version works just fine.

So all in all I don't think it's worth it.
Apr 03 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-03 12:04:42 -0400, Adam D. Ruppe <destructionator gmail.com> said:


 btw, it might be worth considering a change to overflow. Suppose
 there was a way to get arbitrary size ints passed to a template.
 Then, the library could do its own overflow checks, or not, enabling
 things like bigint literals in this same fashion.
 
 Though, I don't think it's a big benefit. It'd be really weird
 to use (a new compile time only datatype?)


I've been thinking about the same thing, except instead of having a 
special data type the template would simply take a string:

	template binary(string digits) {
		...
	}

	binary!1111_1111_0000_0000;
	// no error, number "1111_1111_0000_0000" passed as a string to the template.

But the bigger problem is that it doesn't scale beyond base 10:

	template hex(string digits) {
		...
	}

	hex!ABCDEF00;
	// isn't ABCDEF00 an identifier?

So it wouldn't bring us much when it comes to parsing different bases, 
even though it could be used for other things.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 03 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/3/2011 9:28 AM, Michel Fortin wrote:

 So it wouldn't bring us much when it comes to parsing different bases, even
 though it could be used for other things.


That would also get us into the C++0x territory of having "raw" and "cooked" 
tokens, something I really wish to avoid.
Apr 03 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:ina7e9$2kdh$1 digitalmars.com...

 On 2011-04-03 12:04:42 -0400, Adam D. Ruppe <destructionator gmail.com> 
 said:


 btw, it might be worth considering a change to overflow. Suppose
 there was a way to get arbitrary size ints passed to a template.
 Then, the library could do its own overflow checks, or not, enabling
 things like bigint literals in this same fashion.

 Though, I don't think it's a big benefit. It'd be really weird
 to use (a new compile time only datatype?)


 I've been thinking about the same thing, except instead of having a 
 special data type the template would simply take a string:

 template binary(string digits) {
 ...
 }

 binary!1111_1111_0000_0000;
 // no error, number "1111_1111_0000_0000" passed as a string to the 
 template.


I've always thought that we should be able to do something like this:

template foo(int val)
{
    enum foo = val.meta.argString;
}
static assert(foo!(2+3) == "2+3");
Apr 03 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/03/2011 07:57 PM, Nick Sabalausky wrote:

 "Michel Fortin"<michel.fortin michelf.com>  wrote in message
 news:ina7e9$2kdh$1 digitalmars.com...

 On 2011-04-03 12:04:42 -0400, Adam D. Ruppe<destructionator gmail.com>
 said:


 btw, it might be worth considering a change to overflow. Suppose
 there was a way to get arbitrary size ints passed to a template.
 Then, the library could do its own overflow checks, or not, enabling
 things like bigint literals in this same fashion.

 Though, I don't think it's a big benefit. It'd be really weird
 to use (a new compile time only datatype?)


 I've been thinking about the same thing, except instead of having a
 special data type the template would simply take a string:

 template binary(string digits) {
 ...
 }

 binary!1111_1111_0000_0000;
 // no error, number "1111_1111_0000_0000" passed as a string to the
 template.


 I've always thought that we should be able to do something like this:

 template foo(int val)
 {
      enum foo = val.meta.argString;
 }
 static assert(foo!(2+3) == "2+3");


That's Lisp (or Io): non-evaluated arguments (messages). Next century in 
compiled languages ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 03 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/3/11 1:37 PM, spir wrote:

 On 04/03/2011 07:57 PM, Nick Sabalausky wrote:

 "Michel Fortin"<michel.fortin michelf.com> wrote in message
 news:ina7e9$2kdh$1 digitalmars.com...

 On 2011-04-03 12:04:42 -0400, Adam D. Ruppe<destructionator gmail.com>
 said:


 btw, it might be worth considering a change to overflow. Suppose
 there was a way to get arbitrary size ints passed to a template.
 Then, the library could do its own overflow checks, or not, enabling
 things like bigint literals in this same fashion.

 Though, I don't think it's a big benefit. It'd be really weird
 to use (a new compile time only datatype?)


 I've been thinking about the same thing, except instead of having a
 special data type the template would simply take a string:

 template binary(string digits) {
 ...
 }

 binary!1111_1111_0000_0000;
 // no error, number "1111_1111_0000_0000" passed as a string to the
 template.


 I've always thought that we should be able to do something like this:

 template foo(int val)
 {
 enum foo = val.meta.argString;
 }
 static assert(foo!(2+3) == "2+3");


 That's Lisp (or Io): non-evaluated arguments (messages). Next century in
 compiled languages ;-)





Andrei
Apr 03 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/3/11, Nick Sabalausky <a a.a> wrote:

 I've always thought that we should be able to do something like this:

 template foo(int val)
 {
     enum foo = val.meta.argString;
 }
 static assert(foo!(2+3) == "2+3");


I wish we had some introspection to get the lines of code inside of a
function. But it's still pretty cool that you can pass expressions to
functions and automatically construct delegates. See here:

import std.stdio;

void main()
{
    int x;
	
    foo(false, x = 5);
    assert(x != 5);

    foo(true, x = 5);
    assert(x == 5);
}

void foo(bool doit, int delegate()[] dgs ...)
{
    if (doit)
        dgs[0]();
}

I wonder how many people know about this feature. I just bumped into
it a few days ago while looking through the docs.
Apr 03 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.3093.1301858962.4748.digitalmars-d puremagic.com...

 On 4/3/11, Nick Sabalausky <a a.a> wrote:

 I've always thought that we should be able to do something like this:

 template foo(int val)
 {
     enum foo = val.meta.argString;
 }
 static assert(foo!(2+3) == "2+3");


 I wish we had some introspection to get the lines of code inside of a
 function. But it's still pretty cool that you can pass expressions to
 functions and automatically construct delegates. See here:

 import std.stdio;

 void main()
 {
    int x;

    foo(false, x = 5);
    assert(x != 5);

    foo(true, x = 5);
    assert(x == 5);
 }

 void foo(bool doit, int delegate()[] dgs ...)
 {
    if (doit)
        dgs[0]();
 }

 I wonder how many people know about this feature. I just bumped into
 it a few days ago while looking through the docs.


I didn't know that. I think I remember the idea of it being discussed, but I 
didn't know it was in.
Apr 03 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Apr 2011 15:40:18 -0400, Nick Sabalausky <a a.a> wrote:


 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.3093.1301858962.4748.digitalmars-d puremagic.com...

 On 4/3/11, Nick Sabalausky <a a.a> wrote:

 I've always thought that we should be able to do something like this:

 template foo(int val)
 {
     enum foo = val.meta.argString;
 }
 static assert(foo!(2+3) == "2+3");


 I wish we had some introspection to get the lines of code inside of a
 function. But it's still pretty cool that you can pass expressions to
 functions and automatically construct delegates. See here:

 import std.stdio;

 void main()
 {
    int x;

    foo(false, x = 5);
    assert(x != 5);

    foo(true, x = 5);
    assert(x == 5);
 }

 void foo(bool doit, int delegate()[] dgs ...)
 {
    if (doit)
        dgs[0]();
 }

 I wonder how many people know about this feature. I just bumped into
 it a few days ago while looking through the docs.


 I didn't know that. I think I remember the idea of it being discussed,  
 but I
 didn't know it was in.


It's been there forever (at least since I first learned D).  It's even in  
D1:

http://www.digitalmars.com/d/1.0/function.html

Look for "Lazy variadic functions"

I think what you were thinking of is the replacement of lazy with simply a  
delegate (which this example is not).

-Steve
Apr 04 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:in8f9e$1h45$1 digitalmars.com...

 On 2011-04-02 19:58:25 -0400, Walter Bright <newshound2 digitalmars.com> 
 said:


 On 4/2/2011 4:11 PM, Michel Fortin wrote:

 It's funny that D (the language) has binary notation built-in (which C 
 doesn't
 have) but no octal notation anymore (which C has).


 The problem with the octal literals is, as has been often complained 
 about, people getting surprised by it. I've never heard of anyone being 
 surprised by the binary or hex literals.


 Indeed. Isn't that a good argument for implementing octal literals the 
 same way as binary and hex literals?


Octal is never really needed or used for anything but unix file permissions, 
so I really don't think it matters at all if it happens to be inconsistent.


 I think it's a feature, not a "resort", that library templates can do 
 this well. I think it's far better than C++0x's user defined literals, 
 for example.


 I disagree that it's better. With C++ user defined literals the user 
 doesn't have to find by himself whether the number fits within the range 
 of a regular integer literal and if not fall back to using a string as the 
 template argument instead.


C++'s user defined literals sound like a lexing nightmare to me.
Apr 03 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


I fail to infer how using the word "octal" for an octal literal is 
surprising at all.

This thread is a good example that it's impossible to please everyone. 
Although past discussions made it clear that most everyone found leading 
0 a poor convention for octal numbers, now not only the consensus is 
weaker, but some actually claim a different solution is superior. If 
that were chosen, then all of a sudden octal!777 would have become 
suddenly sexy and so on.

The grass is always greener on the other side...


Andrei
Apr 02 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:

 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 
 I fail to infer how using the word "octal" for an octal literal is surprising
at
 all.
 
 This thread is a good example that it's impossible to please everyone. Although
 past discussions made it clear that most everyone found leading 0 a poor
 convention for octal numbers, now not only the consensus is weaker, but some
 actually claim a different solution is superior. If that were chosen, then all
 of a sudden octal!777 would have become suddenly sexy and so on.
 
 The grass is always greener on the other side...
 
 
 Andrei


I don't think the consensus that a leading 0 is a poor convention for octal
numbers is weaker now - so far nobody wants the old syntax back :)
Apr 02 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/2/11 6:36 PM, Daniel Gibson wrote:

 Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:

 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is surprising
at
 all.

 This thread is a good example that it's impossible to please everyone. Although
 past discussions made it clear that most everyone found leading 0 a poor
 convention for octal numbers, now not only the consensus is weaker, but some
 actually claim a different solution is superior. If that were chosen, then all
 of a sudden octal!777 would have become suddenly sexy and so on.

 The grass is always greener on the other side...


 Andrei


 I don't think the consensus that a leading 0 is a poor convention for octal
 numbers is weaker now - so far nobody wants the old syntax back :)


Some discussions on IRC suggest otherwise.

Andrei
Apr 02 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 04:00, schrieb Andrei Alexandrescu:

 On 4/2/11 6:36 PM, Daniel Gibson wrote:

 Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:

 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is surprising
at
 all.

 This thread is a good example that it's impossible to please everyone. Although
 past discussions made it clear that most everyone found leading 0 a poor
 convention for octal numbers, now not only the consensus is weaker, but some
 actually claim a different solution is superior. If that were chosen, then all
 of a sudden octal!777 would have become suddenly sexy and so on.

 The grass is always greener on the other side...


 Andrei


 I don't think the consensus that a leading 0 is a poor convention for octal
 numbers is weaker now - so far nobody wants the old syntax back :)


 
 Some discussions on IRC suggest otherwise.
 
 Andrei


Ok. I don't hang out in the D IRC chan because the NG is time-consuming enough
already ;)
Apr 02 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 02 Apr 2011 22:14:47 -0400, Daniel Gibson <metalcaedes gmail.com>  
wrote:


 Am 03.04.2011 04:00, schrieb Andrei Alexandrescu:

 On 4/2/11 6:36 PM, Daniel Gibson wrote:

 Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:

 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is  
 surprising at
 all.

 This thread is a good example that it's impossible to please  
 everyone. Although
 past discussions made it clear that most everyone found leading 0 a  
 poor
 convention for octal numbers, now not only the consensus is weaker,  
 but some
 actually claim a different solution is superior. If that were chosen,  
 then all
 of a sudden octal!777 would have become suddenly sexy and so on.

 The grass is always greener on the other side...


 Andrei


 I don't think the consensus that a leading 0 is a poor convention for  
 octal
 numbers is weaker now - so far nobody wants the old syntax back :)


 Some discussions on IRC suggest otherwise.

 Andrei


 Ok. I don't hang out in the D IRC chan because the NG is time-consuming  
 enough
 already ;)


Oh how true this is :)

-Steve
Apr 04 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 Although past discussions made it clear that most everyone found leading 
 0 a poor convention for octal numbers, now not only the consensus is 
 weaker,


The consensus was as much strong as now that the leading zero to denote octals
is bad. But even in past some people (like me) have suggested more than one
replacement syntax (see Bugzilla). So I am seeing nothing new in the
discussions of today.



 If that were chosen, then all of a sudden octal!777 would have become 
 suddenly sexy and so on.


You have no proof of this.

By the way, I am happy of this (unannounced) change.

Bye,
bearophile
Apr 02 2011
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:

 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


=20
 I fail to infer how using the word "octal" for an octal literal is=20
 surprising at all.


The problem is not that it is a poor solution in isolation, it is the
conflict between 0b... and 0x.. versus octal!...  Why is octal being
discriminated against compared to binary and hexadecimal?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 03 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Russel Winder" <russel russel.org.uk> wrote in message 
news:mailman.3055.1301814881.4748.digitalmars-d puremagic.com...

On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:

 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is
 surprising at all.


The problem is not that it is a poor solution in isolation, it is the
conflict between 0b... and 0x.. versus octal!...  Why is octal being
discriminated against compared to binary and hexadecimal?


To be perfectly blunt, it's because octal...well, sucks. It's useless 
compared to binary and hex and just isn't really deserving of a special 
notation anyway. Even more so since the rare uses of it are possible in D 
without it being part of the language. Binary and hex, OTOH, are useful (I 
use hex very frequently. And I would get a lot of use out of binary if I 
actually had time to do low-level work like I used to).

That said, I woudn't have a problem with 0o... being used instead (Although 
I'd actually prefer 0c...). But I have a hard time understanding why people 
are making such a big deal out of something that practically no one ever 
uses anyway. Consistency is nice, sure, but when it's such a trival 
corner-case as octal: Why even care? This isn't the color of the bikeshed, 
this is the *shade* of color on the underside of the trim on a window that's 
one foot off the ground and completely blocked by a big tree.
Apr 03 2011
parent reply spir <denis.spir gmail.com> writes:
On 04/03/2011 10:37 AM, Nick Sabalausky wrote:

 That said, I woudn't have a problem with 0o... being used instead (Although
 I'd actually prefer 0c...). But I have a hard time understanding why people
 are making such a big deal out of something that practically no one ever
 uses anyway. Consistency is nice, sure, but when it's such a trival
 corner-case as octal: Why even care? This isn't the color of the bikeshed,
 this is the *shade* of color on the underside of the trim on a window that's
 one foot off the ground and completely blocked by a big tree.


What I fail to see is the advantage of introducing an exception for octal. 
Either it is left out of the language (including stdlib, possibly having around 
a 3rd party hack for it), or the same pattern is used as for hex and bin.
A point is stating a threshold of usefulness. Seems nearly everyone agrees 
octal is not worth it: then just say bye. If it kept instead because of 
historical reasons (what I guess is the case), then just *fix* the syntax. 
Introducing a feature (an exception) for a nearly useless notion is weird.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 03 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/3/11 6:24 AM, spir wrote:

 On 04/03/2011 10:37 AM, Nick Sabalausky wrote:

 That said, I woudn't have a problem with 0o... being used instead
 (Although
 I'd actually prefer 0c...). But I have a hard time understanding why
 people
 are making such a big deal out of something that practically no one ever
 uses anyway. Consistency is nice, sure, but when it's such a trival
 corner-case as octal: Why even care? This isn't the color of the
 bikeshed,
 this is the *shade* of color on the underside of the trim on a window
 that's
 one foot off the ground and completely blocked by a big tree.


 What I fail to see is the advantage of introducing an exception for
 octal. Either it is left out of the language (including stdlib, possibly
 having around a 3rd party hack for it), or the same pattern is used as
 for hex and bin.


Right now octal constants are indeed out of the language.


 A point is stating a threshold of usefulness. Seems nearly everyone
 agrees octal is not worth it: then just say bye. If it kept instead
 because of historical reasons (what I guess is the case), then just
 *fix* the syntax. Introducing a feature (an exception) for a nearly
 useless notion is weird.


This is not a feature. It is effectively "bye".


Thanks,

Andrei
Apr 03 2011
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
spir wrote:

 What I fail to see is the advantage of introducing an exception for
 octal.


Octal isn't the exception. Of all the infinite number bases out there,
octal is the one done in the most generic way. (In fact, it'd
probably be a reasonably simple change to make it alias base!8 octal;
or something like that)

The exceptions are decimal, hex, and binary. Each one has reasoning:

decimal: that's the way we normally talk and think. We need a
         starting point somewhere, so this is the natural choice.

hex:     commonly used and cannot be easily written as a decimal
         literal. Piles upon piles of existing code depend on it.

binary:  Incredibly useful, not easily written as a decimal. The
         case for giving it special treatment isn't as strong as
         hex, but it follows the same reasoning. (Actually, in
         code that I write freshly, I use binary literals more
         often than hex. Like Walter, my brain is slow at making
         masks out of hex.)



Anything can follow the same pattern as octal. Not anything can
be shoved into the language.
Apr 03 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/3/2011 4:24 AM, spir wrote:

 Introducing a
 feature (an exception) for a nearly useless notion is weird.


The whole point of this is it is not introducing a feature. It's using existing 
features to emulate a feature that is being removed.
Apr 03 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/3/11 2:14 AM, Russel Winder wrote:

 On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:

 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but
 hardly octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is
 surprising at all.


 The problem is not that it is a poor solution in isolation, it is
 the conflict between 0b... and 0x.. versus octal!...  Why is octal
 being discriminated against compared to binary and hexadecimal?


It's very simple. You are making a number of fallacious assumptions
which logically lead to a wrong conclusion.

First fallacy is:


 What is the use for binary literals or hexadecimal literals, I can't
 think of one.


Just looking through std/ yields 1849 lines with 0x in them, of which 
many have several instances on the same line.

The second fallacy is assigning equal weight to every feature or 
potential feature. A language should not be a democracy.

The third fallacy is a unidimensional view of consistency. It's very 
easy to first limit the notion of consistency to only one possible 
dimension, to then show that a lot of stuff is inconsistent. In reality 
there are many dimensions of consistency, and choosing their right 
relative importance is much of the difficulty of language design.

Keeping 0x in the language is consistent with the general similarity of 
D with C, C++, Java, and many others.

Eliminating 0777 from the language is consistent with the notion that 
leading zeros are insignificant in regular decimal notation in math. It 
is also consistent with the desire of preventing subtle mistakes made by 
people who make the math-based assumption.

Adding octal!777 to std.conv is consistent with the notion that there 
still are a few uses for octal constants that are worth a presence in 
the standard library. It is also consistent with the desire to foster 
other user-defined literals defined from the same mold.


Andrei
Apr 03 2011
parent reply spir <denis.spir gmail.com> writes:
On 04/03/2011 06:14 PM, Andrei Alexandrescu wrote:

 Adding octal!777 to std.conv is consistent with the notion that there still are
 a few uses for octal constants that are worth a presence in the standard
 library. It is also consistent with the desire to foster other user-defined
 literals defined from the same mold.


What about a general baseNumber template instead?
...which would also be trivially "alias-able":
     alias baseNumber!3 base3;

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 03 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/3/11 1:40 PM, spir wrote:

 On 04/03/2011 06:14 PM, Andrei Alexandrescu wrote:

 Adding octal!777 to std.conv is consistent with the notion that there
 still are
 a few uses for octal constants that are worth a presence in the standard
 library. It is also consistent with the desire to foster other
 user-defined
 literals defined from the same mold.


 What about a general baseNumber template instead?
 ....which would also be trivially "alias-able":
 alias baseNumber!3 base3;


When was last time you've been in a place in life when you could have 
used a base 3 literal?

Andrei
Apr 03 2011
parent spir <denis.spir gmail.com> writes:
On 04/03/2011 08:49 PM, Andrei Alexandrescu wrote:

 On 4/3/11 1:40 PM, spir wrote:

 On 04/03/2011 06:14 PM, Andrei Alexandrescu wrote:

 Adding octal!777 to std.conv is consistent with the notion that there
 still are
 a few uses for octal constants that are worth a presence in the standard
 library. It is also consistent with the desire to foster other
 user-defined
 literals defined from the same mold.


 What about a general baseNumber template instead?
 ....which would also be trivially "alias-able":
 alias baseNumber!3 base3;


 When was last time you've been in a place in life when you could have used a
 base 3 literal?


I'm not stating this point (implicitely); I mean that it would be useful. 
Rather you and others let me think at this by saying the template solution 
(octal!) is more general (than 0o).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 03 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Apr 2011 03:14:31 -0400, Russel Winder <russel russel.org.uk>  
wrote:


 On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:

 On 4/2/11 5:27 PM, ulrik.mikaelsson gmail.com wrote:

 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.


 I fail to infer how using the word "octal" for an octal literal is
 surprising at all.


 The problem is not that it is a poor solution in isolation, it is the
 conflict between 0b... and 0x.. versus octal!...  Why is octal being
 discriminated against compared to binary and hexadecimal?


This currently works in D:

auto hexvalue = 0XABCD;
auto binvalue = 0B1011; // BTW, walter, this is 0xB, I always remember it,  
because A is 10, and in binary that's 1010, add 1 for B ;)

So if you have the 0o syntax, wouldn't you need the 0O syntax to be  
'non-discriminatory'?  And if we have that, I think your argument loses  
all credibility.  You can't argue discrimination unless you are arguing  
for the 0O syntax, which is non-defensible.

I agree with everyone who says octal!x is good enough -- nobody uses octal  
except for unix permissions, so anyone who's arguing against the syntax is  
doing it from a theoretical position, since it probably doesn't affect  
them.

-Steve
Apr 04 2011
parent Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-04-04 at 08:50 -0400, Steven Schveighoffer wrote:
[ . . . ]

 I agree with everyone who says octal!x is good enough -- nobody uses octa=


l =20

 except for unix permissions, so anyone who's arguing against the syntax i=


s =20

 doing it from a theoretical position, since it probably doesn't affect =


=20

 them.


Not entirely true, but views have been aired, decisions ratified, so it
is time to move on with the status quo -- probably "Whatever You Want",
but maybe "What You're Proposing" -- mostly thought this is now a
non-issue, is there anything else to be said?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 04 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


010, etc., will now be errors. They will not be 10 decimal.

Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08, 
09, etc. will of course be errors.
Apr 02 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 01:50, schrieb Walter Bright:

 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


 
 010, etc., will now be errors. They will not be 10 decimal.
 
 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08,
 09, etc. will of course be errors.


That feels pretty inconsistent.

Cheers,
- Daniel
Apr 02 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2011 4:52 PM, Daniel Gibson wrote:

 Am 03.04.2011 01:50, schrieb Walter Bright:

 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08,
 09, etc. will of course be errors.


 That feels pretty inconsistent.


It is inconsistent. One of the interesting things about "good" user interface 
design is it is awfully inconsistent.

The thing is, I ran into a bunch of D code that used 01, 03, etc. They weren't 
octal, and it seemed a pity to break it.
Apr 02 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 03:39, schrieb Walter Bright:

 On 4/2/2011 4:52 PM, Daniel Gibson wrote:

 Am 03.04.2011 01:50, schrieb Walter Bright:

 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08,
 09, etc. will of course be errors.


 That feels pretty inconsistent.


 
 It is inconsistent. One of the interesting things about "good" user interface
 design is it is awfully inconsistent.
 
 The thing is, I ran into a bunch of D code that used 01, 03, etc. They weren't
 octal, and it seemed a pity to break it.


They were octal, it just didn't make a difference. I don't see a reason to use
them (if not as octals) anyway.

Time will tell but I wouldn't be surprised if sooner or later somebody wonders
why 00, 01..07 work, but 08 etc don't and complains about weird corner cases ;)

Cheers,
- Daniel
Apr 02 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2011 6:44 PM, Daniel Gibson wrote:

 Time will tell but I wouldn't be surprised if sooner or later somebody wonders
 why 00, 01..07 work, but 08 etc don't and complains about weird corner cases ;)


They might. We'll see.
Apr 02 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:in8jko$knb$7 digitalmars.com...

 Am 03.04.2011 03:39, schrieb Walter Bright:

 On 4/2/2011 4:52 PM, Daniel Gibson wrote:

 Am 03.04.2011 01:50, schrieb Walter Bright:

 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without 
 complaint. 08,
 09, etc. will of course be errors.


 That feels pretty inconsistent.


 It is inconsistent. One of the interesting things about "good" user 
 interface
 design is it is awfully inconsistent.

 The thing is, I ran into a bunch of D code that used 01, 03, etc. They 
 weren't
 octal, and it seemed a pity to break it.


 They were octal, it just didn't make a difference. I don't see a reason to 
 use
 them (if not as octals) anyway.

 Time will tell but I wouldn't be surprised if sooner or later somebody 
 wonders
 why 00, 01..07 work, but 08 etc don't and complains about weird corner 
 cases ;)


Yea, but I bet people would also complain if it were disallowed. "There's no 
ambiguity here! Why's it whining about something that's obviously guaranteed 
to work?!"
Apr 03 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Apr 3, 11 09:44, Daniel Gibson wrote:

 Am 03.04.2011 03:39, schrieb Walter Bright:

 On 4/2/2011 4:52 PM, Daniel Gibson wrote:

 Am 03.04.2011 01:50, schrieb Walter Bright:

 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08,
 09, etc. will of course be errors.


 That feels pretty inconsistent.


 It is inconsistent. One of the interesting things about "good" user interface
 design is it is awfully inconsistent.

 The thing is, I ran into a bunch of D code that used 01, 03, etc. They weren't
 octal, and it seemed a pity to break it.


 They were octal, it just didn't make a difference. I don't see a reason to use
 them (if not as octals) anyway.

 Time will tell but I wouldn't be surprised if sooner or later somebody wonders
 why 00, 01..07 work, but 08 etc don't and complains about weird corner cases ;)

 Cheers,
 - Daniel


No need to be surprised, people are already complaining languages 
supporting the 0nnn notation that why 08, 09 does not compile. :)

e.g.

08 in Python 2: 
http://stackoverflow.com/questions/336181/python-invalid-token
09 in Java: 
http://stackoverflow.com/questions/970039/09-is-not-recognized-where-as-9-is-recognized
Apr 03 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/3/2011 2:31 AM, KennyTM~ wrote:

 No need to be surprised, people are already complaining languages supporting
the
 0nnn notation that why 08, 09 does not compile. :)

 e.g.

 08 in Python 2: http://stackoverflow.com/questions/336181/python-invalid-token
 09 in Java:
 http://stackoverflow.com/questions/970039/09-is-not-recognized-where-as-9-is-recognized



I love the answer given: "There is no 9 in octal"
Apr 03 2011
parent spir <denis.spir gmail.com> writes:
On 04/03/2011 11:39 AM, Walter Bright wrote:

 On 4/3/2011 2:31 AM, KennyTM~ wrote:

 No need to be surprised, people are already complaining languages supporting
the
 0nnn notation that why 08, 09 does not compile. :)

 e.g.

 08 in Python 2: http://stackoverflow.com/questions/336181/python-invalid-token
 09 in Java:
 http://stackoverflow.com/questions/970039/09-is-not-recognized-where-as-9-is-recognized



 I love the answer given: "There is no 9 in octal"


I love that one: "10 is how many digits you have, whereas 010 is is what you 
get if you don't count your thumbs."

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 03 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08, 
 09, etc. will of course be errors.


Isn't this a corner case of the general rule? (corner cases are bad).

Bye,
bearophile
Apr 02 2011
parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:in8dfe$1e32$1 digitalmars.com...

 Walter:


 Also, the literals 00, 01, ..., 07 will still be accepted without 
 complaint. 08,
 09, etc. will of course be errors.


 Isn't this a corner case of the general rule? (corner cases are bad).


"(corner cases are bad)"

So is stealing, but no one ever bitches if you pick up a penny off the 
ground. Yea, it's a corner case, but it's trivial enough not to actually 
matter. Guaranteed, people would bitch the other way too, so it's "dammed if 
we do, dammed if we don't" anyway.
Apr 03 2011
prev sibling next sibling parent reply Francisco Almeida <francisco.m.almeida gmail.com> writes:
Walter Bright Wrote:


 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


 
 010, etc., will now be errors. They will not be 10 decimal.
 
 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08, 
 09, etc. will of course be errors.


This doesn't feel right, though. Either you permit leading numbers with leading
zeroes to be read as decimals, or you forbid them unless they are 0x... or
0b... .

I am concerned about the choice of relegating a kind of number literal to a
library template. Doesn't this needlessly impact performance?

Granted, the 0123 syntax was error prone and we're all glad it's gone, but
aren't there better alternatives such as 0o123 or 0q123, for example?
Apr 02 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 02:23, schrieb Francisco Almeida:

 Walter Bright Wrote:
 

 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
08, 
 09, etc. will of course be errors.


 
 This doesn't feel right, though. Either you permit leading numbers with
leading zeroes to be read as decimals, or you forbid them unless they are 0x...
or 0b... .


I agree.


 
 I am concerned about the choice of relegating a kind of number literal to a
library template. Doesn't this needlessly impact performance?


No, it's a template, so it's evaluated at compile-time and doesn't impact
(runtime) performance.


 
 Granted, the 0123 syntax was error prone and we're all glad it's gone, but
aren't there better alternatives such as 0o123 or 0q123, for example?
 


How often do you use octal numbers?
Apr 02 2011
parent Francisco Almeida <francisco.m.almeida gmail.com> writes:
== Quote from Daniel Gibson (metalcaedes gmail.com)'s article


 I am concerned about the choice of relegating a kind of number literal to a




library template. Doesn't this needlessly impact performance?

 No, it's a template, so it's evaluated at compile-time and doesn't impact
 (runtime) performance.


If there is no runtime performance penalty, then it's fine.


 Granted, the 0123 syntax was error prone and we're all glad it's gone, but




aren't there better alternatives such as 0o123 or 0q123, for example?


 How often do you use octal numbers?


Good point.



 Apr 02 2011



prev sibling  parent reply KennyTM~ <kennytm gmail.com>  writes:


On Apr 3, 11 07:50, Walter Bright wrote:

 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without
 complaint. 08, 09, etc. will of course be errors.


Will it be part of the spec that 0+[0-7] will work, and the rest of 0\d+ 
won't? Or is this considered just a DMD extension?



 Apr 03 2011



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 4/3/2011 2:33 AM, KennyTM~ wrote:

 On Apr 3, 11 07:50, Walter Bright wrote:

 On 4/2/2011 3:27 PM, ulrik.mikaelsson gmail.com wrote:

 As I wrote, I think it's great that 010 != 8 anymore.


 010, etc., will now be errors. They will not be 10 decimal.

 Also, the literals 00, 01, ..., 07 will still be accepted without
 complaint. 08, 09, etc. will of course be errors.


 Will it be part of the spec that 0+[0-7] will work, and the rest of 0\d+ won't?
 Or is this considered just a DMD extension?


It should be part of the spec.



 Apr 03 2011



prev sibling  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


Guessing is a bad game. A newbie should take a look in the manuals,
which is where octal should be described.



 Apr 02 2011



prev sibling  parent  Adam D. Ruppe <destructionator gmail.com>  writes:


ulrik.mikaelsson

 I too was just about to ask why on earth "octal!" instead of 0o
 (and I didn't know about Python3).


octal! was written early last year IIRC, when changes to the language
weren't yet on the table.



 Apr 02 2011



prev sibling  parent  bearophile <bearophileHUGS lycos.com>  writes:


Daniel Gibson:


 In general octal numbers are rarely needed (I guess), so the somehow clumsy
 octal!123 syntax doesn't matter. Also it's more readable (self-documenting) for
 someone not used to octal numbers than Python3's 0o123.


I agree.

Bye,
bearophile



 Apr 02 2011



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 4/2/2011 2:38 PM, bearophile wrote:

 Andrej Mitrovic:


 If I didn't know it better I would think it's still April 1st. :D


 I don't like the "octal!" a lot, I prefer a syntax like the Python3 one



The point is that "octal!" is not a syntax. It's completely a library
construction.



 Apr 02 2011



 next sibling parent  bearophile <bearophileHUGS lycos.com>  writes:


Walter:


 The point is that "octal!" is not a syntax. It's completely a library
construction.


It seems I use the word "syntax" in a different way, for me it means any way to
express a semantics. I will be more careful with my wording.

Bye,
bearophile



 Apr 02 2011



prev sibling  parent reply Russel Winder <russel russel.org.uk>  writes:


On Sat, 2011-04-02 at 16:47 -0700, Walter Bright wrote:


 The point is that "octal!" is not a syntax. It's completely a library con=


struction.

So remove 0b... and 0x... as well such that the compiler only knows
about decimal.  The point here is not the removal of the C-style octal
notation, everyone agrees that it was and remains a bad idea, the
problem is the inconsistency of treatment of binary and hexadecimal
compared to octal.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Apr 03 2011



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 4/3/2011 12:00 AM, Russel Winder wrote:

 On Sat, 2011-04-02 at 16:47 -0700, Walter Bright wrote:


 The point is that "octal!" is not a syntax. It's completely a library
construction.


 So remove 0b... and 0x... as well such that the compiler only knows
 about decimal.  The point here is not the removal of the C-style octal
 notation, everyone agrees that it was and remains a bad idea, the
 problem is the inconsistency of treatment of binary and hexadecimal
 compared to octal.



The 0x notation is heavily used, and so justifies a custom syntax for it. Octal 
is pretty much never used outside of setting file permission masks.

Much as I like PDP-10's and PDP-11's, they are dead and gone. <sob>



 Apr 03 2011



  parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com>  writes:


2011/4/3 Walter Bright <newshound2 digitalmars.com>:

 The 0x notation is heavily used, and so justifies a custom syntax for it.
 Octal is pretty much never used outside of setting file permission masks.


The thing is, since you already have 0x and 0b, 0o would not be much
of a "custom syntax". It would simply be an "extrapolation of the
rule". It follows the already set pattern for non 10-base literals.

Regarding the "but it's so uncommon"-argument, there are 23 characters
left for the "0<base-char>"-notation, there isn't exactly an
allocation-problem.


 A feature that can be handled adequately by the library should not be part of
the core language.


If you're looking for uncommonly used language-features that could
easily be otherwise solved, go ahead and remove asm instead. I'll
guess it's about as uncommon as octal literals (or maybe even more),
have simple other solution (just compile it separately and link), and
has much greater impact on the language and the compiler.

I simply don't buy the "uncommon" argument, when it's such a minuscule
thing in the language, following an already established
framework/pattern.


 The phrase "discriminating against people" has a lot of emotional baggage
associated with it that is irrelevant to this.


Walter, you can make the decisions you see fit, you are the BDFL, but
please don't dismiss peoples feelings like this. It will only hinder D
longevity and growth.

I realize the discussion is over, and the feature has been
implemented. Bitching and moaning now won't change anybodys mind, but
for the record, I think this is a bad design-move, breaking
established patterns. I agree it minuscule and seldom used, so I'm not
going to continue the discussion.



 Apr 03 2011



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/3/11 4:39 AM, Ulrik Mikaelsson wrote:

 2011/4/3 Walter Bright<newshound2 digitalmars.com>:

 The 0x notation is heavily used, and so justifies a custom syntax for it.
 Octal is pretty much never used outside of setting file permission masks.


 The thing is, since you already have 0x and 0b, 0o would not be much
 of a "custom syntax". It would simply be an "extrapolation of the
 rule". It follows the already set pattern for non 10-base literals.


It is a custom syntax nevertheless. Worse, that custom syntax does 
nothing for other cases of literals (e.g. lat/long, degrees and minutes 
etc). The best thing about std.conv.octal is that is serves as a 
template (in the general sense of the word) for any custom literals. It 
offers the proverbial fishing rod as opposed to '0o' being the 
proverbial fish.


 Regarding the "but it's so uncommon"-argument, there are 23 characters
 left for the "0<base-char>"-notation, there isn't exactly an
 allocation-problem.


 A feature that can be handled adequately by the library should not be part of
the core language.


 If you're looking for uncommonly used language-features that could
 easily be otherwise solved, go ahead and remove asm instead. I'll
 guess it's about as uncommon as octal literals (or maybe even more),
 have simple other solution (just compile it separately and link), and
 has much greater impact on the language and the compiler.

 I simply don't buy the "uncommon" argument, when it's such a minuscule
 thing in the language, following an already established
 framework/pattern.


 The phrase "discriminating against people" has a lot of emotional baggage
associated with it that is irrelevant to this.


 Walter, you can make the decisions you see fit, you are the BDFL, but
 please don't dismiss peoples feelings like this. It will only hinder D
 longevity and growth.

 I realize the discussion is over, and the feature has been
 implemented. Bitching and moaning now won't change anybodys mind, but
 for the record, I think this is a bad design-move, breaking
 established patterns. I agree it minuscule and seldom used, so I'm not
 going to continue the discussion.


On the contrary, I think it's a very good and significant move in the 
right direction. If it breaks anything, it breaks an inferior approach 
to literals.


Andrei



 Apr 03 2011



prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Ulrik Mikaelsson wrote:

 If you're looking for uncommonly used language-features that could
 easily be otherwise solved, go ahead and remove asm instead. I'll
 guess it's about as uncommon as octal literals (or maybe even more),
 have simple other solution (just compile it separately and link),
 and has much greater impact on the language and the compiler.


Actually, inline asm can't be replaced. If you link it separately,
it won't be inlined...

There's also a huge difficulty change. 010 -> octal!10 is a simple
change. It'd be enormous effort to de-inline assembly, even if
it were actually possible in the first place! Consider asm
in version statements....

Also, unlike octal literals, it couldn't be replaced by templates
either; inline asm enables things that are otherwise impossible.
There's simply no way for the language to express many of the
instructions available to you in asm. It's a foundational building
block.

This leads into the commonness too. I don't think I've *ever*
wanted an octal literal. But, assembly is useful in 3/5 of
my programs. Heck, even more, if you count library functions
that use it. (though lib functions could in theory be linked
separately)



 Apr 03 2011



  parent reply KennyTM~ <kennytm gmail.com>  writes:


On Apr 4, 11 00:49, Adam D. Ruppe wrote:

 Ulrik Mikaelsson wrote:

 If you're looking for uncommonly used language-features that could
 easily be otherwise solved, go ahead and remove asm instead. I'll
 guess it's about as uncommon as octal literals (or maybe even more),
 have simple other solution (just compile it separately and link),
 and has much greater impact on the language and the compiler.


 Actually, inline asm can't be replaced. If you link it separately,
 it won't be inlined...


Talking of asm, would the following be expected to work?

-------
import std.conv;
void main() {
     asm {
         di octal!777;
         mov EAX, octal!777;
     }
}
-------



 Apr 03 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


KennyTM~ wrote:

 Talking of asm, would the following be expected to work?


Maybe. Part of me says "yes, it should be the same as a literal*"
but part of me says no because it's weird to drop a template in
an asm block.

* For example:

enum a = octal!777;
asm {
   mov EAX, a;
}

does indeed work.


But, all in all, I don't think octal! itself in asm should work.
It's not literally a literal.



 Apr 03 2011



  parent  spir <denis.spir gmail.com>  writes:


On 04/03/2011 07:19 PM, Adam D. Ruppe wrote:

 KennyTM~ wrote:

 Talking of asm, would the following be expected to work?


 Maybe. Part of me says "yes, it should be the same as a literal*"
 but part of me says no because it's weird to drop a template in
 an asm block.

 * For example:

 enum a = octal!777;
 asm {
     mov EAX, a;
 }

 does indeed work.


 But, all in all, I don't think octal! itself in asm should work.
 It's not literally a literal.


The whole is that, precisely, it is not (no more) a literal. Octals have no 
more syntactic existence ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 03 2011



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 4/3/2011 2:39 AM, Ulrik Mikaelsson wrote:

 If you're looking for uncommonly used language-features that could
 easily be otherwise solved, go ahead and remove asm instead. I'll
 guess it's about as uncommon as octal literals (or maybe even more),
 have simple other solution (just compile it separately and link), and
 has much greater impact on the language and the compiler.


I've done assembler the old fashioned way - a separate .asm file assembled with 
masm and linked in - for years. Having the inline assembler is an ENORMOUS 
productivity improvement. Just a few off the top of my head:

1. MASM's syntax changes unpredictably from version to version. I'd get a lot
of 
grief from customers with "this doesn't assemble with *my* version of MASM", or 
"I don't have MASM".

2. Different assemblers have utterly different syntax - see MASM and GAS.

3. MASM can't read struct declarations, meaning you now have parallel 
declarations that manually must be synced.

4. MASM doesn't understand C++ or D name mangling.

5. Can't mix MASM files and D code in the same function.

6. Can't access D manifest constants from MASM.

7. D takes care of local variable stack addressing modes for you.

8. I can't fix MASM bugs.

9. And Adam's comments.



 Apr 03 2011



prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com>  writes:


Michel Fortin:


 The new syntax is certainly usable, it's just inelegant and hackish. 
 Its your language, it's your choice, and I'll admit it won't affect me 
 much.


My suggestions for Walter are:
- To turn 01 .. 07 too into errors;
- to deprecate the octal! Phobos template.
- To introduce the 0o leading that works from 0o0 to the uint.max;
- To change the new error message, so it suggests to use 0o.
- To ask opinions to the community here next time before changing things in
D2/D3 :-)

Bye,
bearophile



 Apr 02 2011



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/2/11 7:52 PM, bearophile wrote:

 Michel Fortin:


 The new syntax is certainly usable, it's just inelegant and hackish.
 Its your language, it's your choice, and I'll admit it won't affect me
 much.


 My suggestions for Walter are:
 - To turn 01 .. 07 too into errors;
 - to deprecate the octal! Phobos template.
 - To introduce the 0o leading that works from 0o0 to the uint.max;
 - To change the new error message, so it suggests to use 0o.
 - To ask opinions to the community here next time before changing things in
D2/D3 :-)

 Bye,
 bearophile


I think a point the size of China is being missed here.

"octal" is not only an alternative notation, it is an example, a model 
for defining other user-defined literals. Adding 0o or whatever would 
solve the issue of defining an obscure literal, whereas octal opens the 
door to a host of possibilities to define user-defined literals.

std.conv.octal _is_ the work of the community, written by myself and 
others (could you please identify yourselves)?


Andrei



 Apr 02 2011



 next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Andrei Alexandrescu wrote:

 std.conv.octal _is_ the work of the community, written by myself and
 others (could you please identify yourselves)?


I wrote the first version, interestingly, almost exactly a year
ago now. (The timestamp on my local file is 2010-03-26)

It looks like the current version is mostly the same as my
original one, although with significantly improved documentation
and some style cleanup.



 Apr 02 2011



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/2/11 9:28 PM, Adam D. Ruppe wrote:

 Andrei Alexandrescu wrote:

 std.conv.octal _is_ the work of the community, written by myself and
 others (could you please identify yourselves)?


 I wrote the first version, interestingly, almost exactly a year
 ago now. (The timestamp on my local file is 2010-03-26)

 It looks like the current version is mostly the same as my
 original one, although with significantly improved documentation
 and some style cleanup.


Did that include the string parsing and all? I didn't write that code.

Andrei



 Apr 02 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Andrei Alexandrescu wrote:

 Did that include the string parsing and all?


Yeah. You can see my original version here:
http://arsdnet.net/dcode/octal.d

The meat of the code is pretty well unchanged in Phobos.



 Apr 02 2011



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/2/11 9:38 PM, Adam D. Ruppe wrote:

 Andrei Alexandrescu wrote:

 Did that include the string parsing and all?


 Yeah. You can see my original version here:
 http://arsdnet.net/dcode/octal.d

 The meat of the code is pretty well unchanged in Phobos.


Oh indeed, and you're credited in std.conv as an author, too. Thanks!

Andrei



 Apr 02 2011



prev sibling  parent reply Russel Winder <russel russel.org.uk>  writes:


On Sat, 2011-04-02 at 21:16 -0500, Andrei Alexandrescu wrote:
[ . . . ]

 I think a point the size of China is being missed here.
=20
 "octal" is not only an alternative notation, it is an example, a model=


=20

 for defining other user-defined literals. Adding 0o or whatever would=20
 solve the issue of defining an obscure literal, whereas octal opens the=


=20

 door to a host of possibilities to define user-defined literals.


The same goes for 0b... 0x... so why aren't they being removed in favour
of library based solution?

Despite Walters claim that inconsistency is not a bad thing, evidence
indicates that from the psychology community that consistency and
affordance is a very good thing for usability. =20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Apr 03 2011



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


On Sat, 2011-04-02 at 21:16 -0500, Andrei Alexandrescu wrote:
[ . . . ]

 I think a point the size of China is being missed here.

 "octal" is not only an alternative notation, it is an example, a model
 for defining other user-defined literals. Adding 0o or whatever would
 solve the issue of defining an obscure literal, whereas octal opens the
 door to a host of possibilities to define user-defined literals.


The same goes for 0b... 0x... so why aren't they being removed in favour
of library based solution?


Because unlike the octal syntax, those are neither error-prone nor 
barely-useful. I agree that consistency is good, but I think it's far 
outweighed in this case by those other concerns.



 Apr 03 2011



  parent reply Russel Winder <russel russel.org.uk>  writes:


On Sun, 2011-04-03 at 04:05 -0400, Nick Sabalausky wrote:
[ . . . ]

The same goes for 0b... 0x... so why aren't they being removed in favour
of library based solution?


=20
 Because unlike the octal syntax, those are neither error-prone nor=20
 barely-useful. I agree that consistency is good, but I think it's far=20
 outweighed in this case by those other concerns.


Your argument rests on the octal representation being like 0777, a
notation that everyone has already agreed needs removing.  The
introduction of 0o777 for octal increases consistency without
introducing error proneness.  This is just win--win.

There is no consistent language design argument that supports have 0b...
and 0x... but not 0o... -- requiring the use of octal! from the library
when hex! and binary! are not the standard forms.

In the end this is Walter's decision, I'd just prefer him not to get it
wrong.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Apr 03 2011



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 4/3/2011 1:46 AM, Russel Winder wrote:

 In the end this is Walter's decision, I'd just prefer him not to get it
 wrong.


At some point, one has to take a leap of faith. Only time will tell if it was 
the right decision or not.

Or if (in this particular case) it's just a bikeshed color and simply does not 
matter.



 Apr 03 2011



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/3/11 3:46 AM, Russel Winder wrote:

 On Sun, 2011-04-03 at 04:05 -0400, Nick Sabalausky wrote:
 [ . . . ]

 The same goes for 0b... 0x... so why aren't they being removed in favour
 of library based solution?


 Because unlike the octal syntax, those are neither error-prone nor
 barely-useful. I agree that consistency is good, but I think it's far
 outweighed in this case by those other concerns.


 Your argument rests on the octal representation being like 0777, a
 notation that everyone has already agreed needs removing.  The
 introduction of 0o777 for octal increases consistency without
 introducing error proneness.  This is just win--win.


It wins consistency with two other hardwired conventions for 
representing numbers. It is a total loss in helping anything but octal 
constants.


 There is no consistent language design argument that supports have 0b...
 and 0x... but not 0o... -- requiring the use of octal! from the library
 when hex! and binary! are not the standard forms.


0x is too widespread and too often used in C and C++ to gratuitously 
eliminate it. It does not have significant disadvantages. Besides it is 
used fairly often. I agree that 0b could and should be deprecated.


 In the end this is Walter's decision, I'd just prefer him not to get it
 wrong.


That is appreciated.


Andrei



 Apr 03 2011



 next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet>  writes:


On Sun, 03 Apr 2011 11:14:16 -0500, Andrei Alexandrescu wrote:


 I agree that 0b could and should be deprecated.


Ditto.

-Lars



 Apr 03 2011



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Lars T. Kyllingstad:


 I agree that 0b could and should be deprecated.


 
 Ditto.


No please :-)

Bye,
bearophile



 Apr 03 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:inacud$10b$1 digitalmars.com...

 Lars T. Kyllingstad:


 I agree that 0b could and should be deprecated.


 Ditto.


 No please :-)


Yea, I'm perfectly fine with omitting built-in octal literals, but I'll jump 
deep into the "bitch and moan" ship if the deprication-axe gets aimed at 
binary.



 Apr 03 2011



 next sibling parent  spir <denis.spir gmail.com>  writes:


On 04/03/2011 08:27 PM, Nick Sabalausky wrote:

 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:inacud$10b$1 digitalmars.com...

 Lars T. Kyllingstad:


 I agree that 0b could and should be deprecated.


 Ditto.


 No please :-)


 Yea, I'm perfectly fine with omitting built-in octal literals, but I'll jump
 deep into the "bitch and moan" ship if the deprication-axe gets aimed at
 binary.


;-) Same for me: sometimes I just want to write the exact bit sequence. I can't 
automagically figure it out in my head for eg D9 (aging... ).

denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 03 2011



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sun, 03 Apr 2011 14:27:09 -0400, Nick Sabalausky <a a.a> wrote:


 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:inacud$10b$1 digitalmars.com...

 Lars T. Kyllingstad:


 I agree that 0b could and should be deprecated.


 Ditto.


 No please :-)


 Yea, I'm perfectly fine with omitting built-in octal literals, but I'll  
 jump
 deep into the "bitch and moan" ship if the deprication-axe gets aimed at
 binary.


I think the idea is that 0b1111_1111 is replaced with binary!1111_1111

Note, someone earlier brought up that hexadecimal cannot really go this  
route because abcd is also a valid symbol name.  Plus hexadecimal is  
infinitely more useful.

BTW, I'd be on Nick's side if we drop 0b syntax, simply because it doesn't  
hurt to have it.  Yeah, it's inconsistent, so what?  Who cares?  We also  
don't have base 3, base 4, base 5, .. literals so why isn't anyone  
complaining about those?  I've used every one of those just as much as  
I've used octal in programming...

-Steve



 Apr 04 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vtezxnlweav7ka steve-laptop...

 On Sun, 03 Apr 2011 14:27:09 -0400, Nick Sabalausky <a a.a> wrote:


 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:inacud$10b$1 digitalmars.com...

 Lars T. Kyllingstad:


 I agree that 0b could and should be deprecated.


 Ditto.


 No please :-)


 Yea, I'm perfectly fine with omitting built-in octal literals, but I'll 
 jump
 deep into the "bitch and moan" ship if the deprication-axe gets aimed at
 binary.


 I think the idea is that 0b1111_1111 is replaced with binary!1111_1111


Yea, I know, but I think binary is useful enough to justify the built-in 
syntax. 'Course, app developers and web developers may not agree, but I come 
from a heavy low-level background and D is supposed to be a systems language 
(which has always been one of its killer features for me).


 Note, someone earlier brought up that hexadecimal cannot really go this 
 route because abcd is also a valid symbol name.  Plus hexadecimal is 
 infinitely more useful.

 BTW, I'd be on Nick's side if we drop 0b syntax, simply because it doesn't 
 hurt to have it.  Yeah, it's inconsistent, so what?  Who cares?  We also 
 don't have base 3, base 4, base 5, .. literals so why isn't anyone 
 complaining about those?  I've used every one of those just as much as 
 I've used octal in programming...


I've actually used base 4 *more* than I've used octal. I've never used octal 
(in code, at least), but Parallax's Propeller microcontroller has some 
video-out capabilities that involve some 2-bit stuff, and the built-in SPIN 
language has a base-4 syntax that suits those purposes perfectly. Of course, 
even given that, I *still* have no particular interest in D gaining any 
built-in 0q01230123 syntax for it.



 Apr 04 2011



prev sibling  parent reply Dan Olson <zans.is.for.cans yahoo.com>  writes:


Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:


 I agree that 0b could and should be deprecated.


One vote here for not losing 0b.  It may sound silly, but some of D
simple niceties like binary literals and underscores (e.g. 0b0111_0001)
are what made me say to myself "D could be an awesome embedded
language".  Someday I hope to use D instead of C in embedded work.  I
have grown fond of 0b added to some C cross-compilers for manipulating
bits in custom h/w registers.

-- 
Dan



 Apr 03 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Dan Olson" <zans.is.for.cans yahoo.com> wrote in message 
news:uzko7qgv2.fsf comcast.net...

 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:


 I agree that 0b could and should be deprecated.


 One vote here for not losing 0b.  It may sound silly, but some of D
 simple niceties like binary literals and underscores (e.g. 0b0111_0001)
 are what made me say to myself "D could be an awesome embedded
 language".  Someday I hope to use D instead of C in embedded work.  I
 have grown fond of 0b added to some C cross-compilers for manipulating
 bits in custom h/w registers.


That's exactly what drew me to D too. The prospect of something better than 
C for embedded (and other low-level) work.



 Apr 03 2011



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 4/3/2011 12:20 AM, Russel Winder wrote:

 Despite Walters claim that inconsistency is not a bad thing, evidence
 indicates that from the psychology community that consistency and
 affordance is a very good thing for usability.



I meant that inconsistency is not *necessarily* a bad thing.

Successful programming languages are remarkably inconsistent, because people 
like them that way. Completely consistent languages tend to be failures.

Obviously, there's a judgment call about what's a bad inconsistency and what's
a 
good inconsistency. A programming language is a mass of principles that pretty 
much all conflict with each other. The art is, for each conflict, deciding
which 
principle should matter for that particular case.

Ok, I won't drag out my hoary airplane design analogy this time, but have you 
ever designed a house? It's nothing but conflicting requirements. There is no 
consistency. In fact, as any architect will tell you, a consistent design 
actually looks wrong! Look no further than the Parthenon, which doesn't have a 
straight line anywhere in it, even though it looks straight.



 Apr 03 2011



prev sibling  parent reply spir <denis.spir gmail.com>  writes:


On 04/03/2011 02:52 AM, bearophile wrote:

 Michel Fortin:


 The new syntax is certainly usable, it's just inelegant and hackish.
 Its your language, it's your choice, and I'll admit it won't affect me
 much.


 My suggestions for Walter are:
 - To turn 01 .. 07 too into errors;
 - to deprecate the octal! Phobos template.
 - To introduce the 0o leading that works from 0o0 to the uint.max;
 - To change the new error message, so it suggests to use 0o.
 - To ask opinions to the community here next time before changing things in
D2/D3 :-)


I'm very surprised of this move -- aside the concrete details. What I point out 
here is how far sentiments about what is "obvious" or "correct" can be, for a 
given issue, that most of us considered wrong for the same reason.

When I introduced the topic of octal notation 0nnn beeing bad, I was 100% sure 
that (if a move was ever made) either octals would be thrown out of D all 
together for beeing nearly useless, or the syntax would be fixed -- the 
"obvious" "correct" solution if octals remain. While I new about octal!, this 
was so hackish and obviously wrong *for me*, that I did not even imagine one 
second it could become the "official" solution.
I'm certainly not the only one.
Questions of detail, sure, but we all know what the details hide ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 03 2011



 next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com>  writes:


spir wrote:


 On 04/03/2011 02:52 AM, bearophile wrote:

 Michel Fortin:


 The new syntax is certainly usable, it's just inelegant and hackish.
 Its your language, it's your choice, and I'll admit it won't affect me
 much.


 My suggestions for Walter are:
 - To turn 01 .. 07 too into errors;
 - to deprecate the octal! Phobos template.
 - To introduce the 0o leading that works from 0o0 to the uint.max;
 - To change the new error message, so it suggests to use 0o.
 - To ask opinions to the community here next time before changing things
 in D2/D3 :-)


 
 I'm very surprised of this move -- aside the concrete details. What I
 point out here is how far sentiments about what is "obvious" or "correct"
 can be, for a given issue, that most of us considered wrong for the same
 reason.
 
 When I introduced the topic of octal notation 0nnn beeing bad, I was 100%
 sure that (if a move was ever made) either octals would be thrown out of D
 all together for beeing nearly useless, or the syntax would be fixed --
 the "obvious" "correct" solution if octals remain. While I new about
 octal!, this was so hackish and obviously wrong *for me*, that I did not
 even imagine one second it could become the "official" solution.
 I'm certainly not the only one.
 Questions of detail, sure, but we all know what the details hide ;-)
 
 Denis


I don't understand why it is hackish if it's a pure library approach. (it is 
right?) I find it actually rather nice that D can do this. This is not a 
syntax change, octals are out of the language and the library now has an 
octal template. Where's the problem?



 Apr 03 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message 
news:in9t6a$21jb$1 digitalmars.com...

 I don't understand why it is hackish if it's a pure library approach. (it 
 is
 right?) I find it actually rather nice that D can do this. This is not a
 syntax change, octals are out of the language and the library now has an
 octal template. Where's the problem?


Apperently, people want to get a warm fuzzy feeling from the existence of 
features they'll never use.

Seriously, we don't have an 0t... for trinary. We don't have an 0q... for 
base-4 (quadrary?). We don't have any such syntax for any base other than 2, 
10, and 16 (and previously 8). And how many people are bitching about those 
omissions? Nobody. But those omissions are *EVERY BIT* as inconsistent with 
decimal/hex/binary syntax as omitting octal is.

But noooo, apperently we *need* 0o... for octal just simply for the sake of 
*it* existing, but not for any other base. So where the fuck is the 
consistency in the self-proclaimed "consistency" argument? And don't tell me 
"octal is more useful than trinary" because then you're implicitly admitting 
that the consistency argument is a load of crap, and you're jumping ship to 
the "usefulness" argument...which octal *still* looses.



 Apr 03 2011



  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 03/04/2011 19:22, Nick Sabalausky wrote:

 "Lutger Blijdestijn"<lutger.blijdestijn gmail.com>  wrote in message
 news:in9t6a$21jb$1 digitalmars.com...

 I don't understand why it is hackish if it's a pure library approach. (it
 is
 right?) I find it actually rather nice that D can do this. This is not a
 syntax change, octals are out of the language and the library now has an
 octal template. Where's the problem?


 Apperently, people want to get a warm fuzzy feeling from the existence of
 features they'll never use.

 Seriously, we don't have an 0t... for trinary. We don't have an 0q... for
 base-4 (quadrary?). We don't have any such syntax for any base other than 2,
 10, and 16 (and previously 8). And how many people are bitching about those
 omissions? Nobody. But those omissions are *EVERY BIT* as inconsistent with
 decimal/hex/binary syntax as omitting octal is.

 But noooo, apperently we *need* 0o... for octal just simply for the sake of
 *it* existing, but not for any other base. So where the fuck is the
 consistency in the self-proclaimed "consistency" argument? And don't tell me
 "octal is more useful than trinary" because then you're implicitly admitting
 that the consistency argument is a load of crap, and you're jumping ship to
 the "usefulness" argument...which octal *still* looses.


This is I think (possibly by far) the best argument with regards to this 
issue on this thread, *and well worth remembering for the future*, for 
similar arguments about consistency/orthogonality vs not.
It shows that the decision for the inclusion or not of this syntax 
should be made on terms of usefulness (as in, would it be common enough 
to be worthwhile including?), and not in terms of consistency, because 
this is not a case where true consistency applies to give value to the 
decision. Because indeed, the only truly, pedantically consistent 
behavior would be to have no 0? syntax at all, or have one for almost 
every possible base. (!)

-- 
Bruno Medeiros - Software Engineer



 Apr 07 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Bruno Medeiros" <brunodomedeiros+spam com.gmail> wrote in message 
news:inla56$2uoq$1 digitalmars.com...

 On 03/04/2011 19:22, Nick Sabalausky wrote:

 "Lutger Blijdestijn"<lutger.blijdestijn gmail.com>  wrote in message
 news:in9t6a$21jb$1 digitalmars.com...

 I don't understand why it is hackish if it's a pure library approach. 
 (it
 is
 right?) I find it actually rather nice that D can do this. This is not a
 syntax change, octals are out of the language and the library now has an
 octal template. Where's the problem?


 Apperently, people want to get a warm fuzzy feeling from the existence of
 features they'll never use.

 Seriously, we don't have an 0t... for trinary. We don't have an 0q... for
 base-4 (quadrary?). We don't have any such syntax for any base other than 
 2,
 10, and 16 (and previously 8). And how many people are bitching about 
 those
 omissions? Nobody. But those omissions are *EVERY BIT* as inconsistent 
 with
 decimal/hex/binary syntax as omitting octal is.

 But noooo, apperently we *need* 0o... for octal just simply for the sake 
 of
 *it* existing, but not for any other base. So where the fuck is the
 consistency in the self-proclaimed "consistency" argument? And don't tell 
 me
 "octal is more useful than trinary" because then you're implicitly 
 admitting
 that the consistency argument is a load of crap, and you're jumping ship 
 to
 the "usefulness" argument...which octal *still* looses.


 This is I think (possibly by far) the best argument with regards to this 
 issue on this thread, *and well worth remembering for the future*, for 
 similar arguments about consistency/orthogonality vs not.
 It shows that the decision for the inclusion or not of this syntax should 
 be made on terms of usefulness (as in, would it be common enough to be 
 worthwhile including?), and not in terms of consistency, because this is 
 not a case where true consistency applies to give value to the decision. 
 Because indeed, the only truly, pedantically consistent behavior would be 
 to have no 0? syntax at all, or have one for almost every possible base. 
 (!)


I want base PI literals :)

Yum.



 Apr 07 2011



  parent reply spir <denis.spir gmail.com>  writes:


On 04/08/2011 07:25 AM, Nick Sabalausky wrote:

 I want base PI literals :)

 Yum.


I want base 1 literals

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 08 2011



 next sibling parent  "Simen kjaeraas" <simen.kjaras gmail.com>  writes:


On Fri, 08 Apr 2011 13:03:23 +0200, spir <denis.spir gmail.com> wrote:


 On 04/08/2011 07:25 AM, Nick Sabalausky wrote:

 I want base PI literals :)

 Yum.


 I want base 1 literals

 Denis


I like the numeric systems described in Hacker's Delight[1], among them
complex numbers with integer parts, written as bit strings in base 1-i.

[1]: http://www.amazon.com/a/dp/0201914654

-- 
Simen



 Apr 08 2011



prev sibling next sibling parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 08/04/2011 12:03, spir wrote:

 On 04/08/2011 07:25 AM, Nick Sabalausky wrote:

 I want base PI literals :)

 Yum.


 I want base 1 literals

 Denis


hehe :D

-- 
Bruno Medeiros - Software Engineer



 Apr 08 2011



prev sibling  parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2011-04-08 07:03:23 -0400, spir <denis.spir gmail.com> said:


 On 04/08/2011 07:25 AM, Nick Sabalausky wrote:

 I want base PI literals :)
 
 Yum.


 
 I want base 1 literals
 
 Denis


Like this?

assert(0i == 0)
assert(0i0 == 1)
assert(0i00 == 2)
assert(0i000 == 3)
assert(0i0000000000_0000000000_0000000000_00 == 32)


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Apr 08 2011



 next sibling parent  spir <denis.spir gmail.com>  writes:


On 04/08/2011 03:55 PM, Michel Fortin wrote:

 On 2011-04-08 07:03:23 -0400, spir <denis.spir gmail.com> said:


 On 04/08/2011 07:25 AM, Nick Sabalausky wrote:

 I want base PI literals :)

 Yum.


 I want base 1 literals

 Denis


 Like this?

 assert(0i == 0)
 assert(0i0 == 1)
 assert(0i00 == 2)
 assert(0i000 == 3)
 assert(0i0000000000_0000000000_0000000000_00 == 32)


Yop! You just reinvented the definition of natural numbers via set theory ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 08 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:inn4bp$57s$1 digitalmars.com...

 On 2011-04-08 07:03:23 -0400, spir <denis.spir gmail.com> said:


 On 04/08/2011 07:25 AM, Nick Sabalausky wrote:

 I want base PI literals :)

 Yum.


 I want base 1 literals

 Denis


 Like this?

 assert(0i == 0)
 assert(0i0 == 1)
 assert(0i00 == 2)
 assert(0i000 == 3)
 assert(0i0000000000_0000000000_0000000000_00 == 32)


Pardon my geekdom, but it would probably have to be:

assert(0i == 0)
assert(0i1 == 1)
assert(0i11 == 2)
assert(0i111 == 3)
assert(0i1111111111_1111111111_1111111111_11 == 32)


In general, number bases work like this:

Assuming i=0 is the right-most digit:
(digits.length (SIGMA) i=0) digit[i] * (base^^i)

Or in less mathy notation:

uint[] digits = [...blah...]; // digits[0] is the right-most digit
auto finalValue = 0;
foreach(i; 0..digits.length)
    finalValue += digits[i] * (base^^i);

So using 0 as the only digit in base 1 would result in all numbers being 
equal to 0. But using 1 as the only digit would work.



 Apr 08 2011



 next sibling parent  spir <denis.spir gmail.com>  writes:


On 04/08/2011 10:01 PM, Nick Sabalausky wrote:

 "Michel Fortin"<michel.fortin michelf.com>  wrote in message
 news:inn4bp$57s$1 digitalmars.com...

 On 2011-04-08 07:03:23 -0400, spir<denis.spir gmail.com>  said:


 On 04/08/2011 07:25 AM, Nick Sabalausky wrote:

 I want base PI literals :)

 Yum.


 I want base 1 literals

 Denis


 Like this?

 assert(0i == 0)
 assert(0i0 == 1)
 assert(0i00 == 2)
 assert(0i000 == 3)
 assert(0i0000000000_0000000000_0000000000_00 == 32)


 Pardon my geekdom, but it would probably have to be:

 assert(0i == 0)
 assert(0i1 == 1)
 assert(0i11 == 2)
 assert(0i111 == 3)
 assert(0i1111111111_1111111111_1111111111_11 == 32)


 In general, number bases work like this:

 Assuming i=0 is the right-most digit:
 (digits.length (SIGMA) i=0) digit[i] * (base^^i)

 Or in less mathy notation:

 uint[] digits = [...blah...]; // digits[0] is the right-most digit
 auto finalValue = 0;
 foreach(i; 0..digits.length)
      finalValue += digits[i] * (base^^i);

 So using 0 as the only digit in base 1 would result in all numbers being
 equal to 0. But using 1 as the only digit would work.


True, for using the same algorithm to compute the numeric value. But you're 
missing the point in base 1 there cannot be '1' digits, as per definition ;-)
If I correctly understand Michel's meaning, he just provided a notation mapping 
natural numbers to sets (actually sequences): Number n maps to n 
whatever-symbol. Could have been:
     assert(0i$$$ == 3);
but since '0's are available in base 1...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 08 2011



prev sibling next sibling parent  Caligo <iteronvexor gmail.com>  writes:


There is no such thing as base 1 number system.  Stop wasting your time.



 Apr 09 2011



prev sibling  parent  spir <denis.spir gmail.com>  writes:


On 04/09/2011 11:07 AM, Caligo wrote:

 There is no such thing as base 1 number system.  Stop wasting your time.


lol!
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 09 2011



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 4/3/2011 4:48 AM, spir wrote:

 When I introduced the topic of octal notation 0nnn beeing bad, I was 100% sure
 that (if a move was ever made) either octals would be thrown out of D all
 together for beeing nearly useless, or the syntax would be fixed -- the
 "obvious" "correct" solution if octals remain. While I new about octal!, this
 was so hackish and obviously wrong *for me*, that I did not even imagine one
 second it could become the "official" solution.
 I'm certainly not the only one.
 Questions of detail, sure, but we all know what the details hide ;-)


I can see that the syntax octal!677 can be a bit off-putting at first, simply 
because it is not what we're used to. But give it a chance.



 Apr 03 2011



 next sibling parent reply spir <denis.spir gmail.com>  writes:


On 04/03/2011 08:17 PM, Walter Bright wrote:

 On 4/3/2011 4:48 AM, spir wrote:

 When I introduced the topic of octal notation 0nnn beeing bad, I was 100% sure
 that (if a move was ever made) either octals would be thrown out of D all
 together for beeing nearly useless, or the syntax would be fixed -- the
 "obvious" "correct" solution if octals remain. While I new about octal!, this
 was so hackish and obviously wrong *for me*, that I did not even imagine one
 second it could become the "official" solution.
 I'm certainly not the only one.
 Questions of detail, sure, but we all know what the details hide ;-)


 I can see that the syntax octal!677 can be a bit off-putting at first, simply
 because it is not what we're used to. But give it a chance.


Sorry, I expressed my thought wrongly: I meant this was my first impression. 
Then, I would rather go (see other post) for a general baseNumber! template, 
that could trivially be aliased as in
     alias baNumber!3 base3;
What do you think?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 03 2011



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 4/3/2011 12:03 PM, spir wrote:

 Then, I would rather go (see other post) for a general baseNumber! template,
 that could trivially be aliased as in
 alias baNumber!3 base3;
 What do you think?


I think it'd need some compelling use cases.



 Apr 03 2011



 next sibling parent reply spir <denis.spir gmail.com>  writes:


On 04/03/2011 09:21 PM, Walter Bright wrote:

 On 4/3/2011 12:03 PM, spir wrote:

 Then, I would rather go (see other post) for a general baseNumber! template,
 that could trivially be aliased as in
 alias baNumber!3 base3;
 What do you think?


 I think it'd need some compelling use cases.


Well, like octal!... it's just more general.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 03 2011



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/3/11 2:54 PM, spir wrote:

 On 04/03/2011 09:21 PM, Walter Bright wrote:

 On 4/3/2011 12:03 PM, spir wrote:

 Then, I would rather go (see other post) for a general baseNumber!
 template,
 that could trivially be aliased as in
 alias baNumber!3 base3;
 What do you think?


 I think it'd need some compelling use cases.


 Well, like octal!... it's just more general.


There definitely is such a thing as overly general. I ran into that 
quite often while designing and implementing std.algorithm. Some 
generalization are useful and sometimes pleasantly surprising (e.g. 
levenshtein distance on UTF strings) whereas others are just random. I 
try to foster the former kind and dedicate no specific effort to the latter.

Andrei



 Apr 03 2011



prev sibling next sibling parent reply Caligo <iteronvexor gmail.com>  writes:


I don't understand why so much time is spent on such a small issue as
octal syntax while there has been no discussion on how to recruit more
developers to work on GDC or LDC2.  You could have the perfect
language, but it wouldn't mean anything if you don't have a stable and
reliable compiler for it.  GDC has one active developer, and who knows
how long he'll stay active.  I don't want to see GDC die a second
time.  LDC2, same situation.



 Apr 03 2011



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/3/11 8:03 PM, Caligo wrote:

 I don't understand why so much time is spent on such a small issue as
 octal syntax while there has been no discussion on how to recruit more
 developers to work on GDC or LDC2.  You could have the perfect
 language, but it wouldn't mean anything if you don't have a stable and
 reliable compiler for it.  GDC has one active developer, and who knows
 how long he'll stay active.  I don't want to see GDC die a second
 time.  LDC2, same situation.


Might be great to add this to the GSoC ideas page.

Andrei



 Apr 03 2011



prev sibling next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Caligo" <iteronvexor gmail.com> wrote in message 
news:mailman.3127.1301879007.4748.digitalmars-d puremagic.com...

I don't understand why so much time is spent on such a small issue as
 octal syntax while there has been no discussion on how to recruit more
 developers to work on GDC or LDC2.  You could have the perfect
 language, but it wouldn't mean anything if you don't have a stable and
 reliable compiler for it.  GDC has one active developer, and who knows
 how long he'll stay active.  I don't want to see GDC die a second
 time.  LDC2, same situation.


As far as LDC2, LLVM's uselessness on windows is a bit of a showstopper for 
many people. And the LLVM project doesn't appear to be interested in doing 
much about it. (Note I didn't say they *aren't* interested in getting it 
working. That's not something I could even pretend to know. I'm just saying 
that, at the very least, it *looks* like they don't care. And, for better or 
worse, perception does count for a lot.)

As for GDC, I've dabbled a little with GCC in the past and found it a total 
nightmare.

Don't mean to make excuses, just pointing out what I see as being potential 
deterrents.



 Apr 03 2011



  parent reply spir <denis.spir gmail.com>  writes:


On 04/04/2011 07:26 AM, Nick Sabalausky wrote:

 As far as LDC2, LLVM's uselessness on windows is a bit of a showstopper for
 many people. And the LLVM project doesn't appear to be interested in doing
 much about it. (Note I didn't say they *aren't* interested in getting it
 working. That's not something I could even pretend to know. I'm just saying
 that, at the very least, it *looks* like they don't care. And, for better or
 worse, perception does count for a lot.)


Yop, too bad. Else, LLVM could be the one target of choice for many PL's 
"reference" implementation. I'd like to know rationales.


 As for GDC, I've dabbled a little with GCC in the past and found it a total
 nightmare.


You're not the only one. (I've played with the GCC implementation of Oberon-2.)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 04 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"spir" <denis.spir gmail.com> wrote in message 
news:mailman.3141.1301915290.4748.digitalmars-d puremagic.com...

 On 04/04/2011 07:26 AM, Nick Sabalausky wrote:

 As far as LDC2, LLVM's uselessness on windows is a bit of a showstopper 
 for
 many people. And the LLVM project doesn't appear to be interested in 
 doing
 much about it. (Note I didn't say they *aren't* interested in getting it
 working. That's not something I could even pretend to know. I'm just 
 saying
 that, at the very least, it *looks* like they don't care. And, for better 
 or
 worse, perception does count for a lot.)


 Yop, too bad. Else, LLVM could be the one target of choice for many PL's 
 "reference" implementation. I'd like to know rationales.


AIUI, the standard explanation is that exception support on Windows requires 
SEH which is covered by a patent owned by Borland/Microsoft. But I have a 
hard time buying that explanation because non-MS compilers like GCC and DMC 
support exceptions on windows just fine - so why not LLVM, too?

I hate to make accusations of impropriety without proper evidence, but Apple 
is known to be a major backer of LLVM. Obviously that doesn't prove anything 
at all, but it wouldn't surprise me if that at least had *something* to do 
with it (although specifically *what*, I could only speculate).



 Apr 04 2011



  parent reply Don <nospam nospam.com>  writes:


Nick Sabalausky wrote:

 "spir" <denis.spir gmail.com> wrote in message 
 news:mailman.3141.1301915290.4748.digitalmars-d puremagic.com...

 On 04/04/2011 07:26 AM, Nick Sabalausky wrote:

 As far as LDC2, LLVM's uselessness on windows is a bit of a showstopper 
 for
 many people. And the LLVM project doesn't appear to be interested in 
 doing
 much about it. (Note I didn't say they *aren't* interested in getting it
 working. That's not something I could even pretend to know. I'm just 
 saying
 that, at the very least, it *looks* like they don't care. And, for better 
 or
 worse, perception does count for a lot.)


 Yop, too bad. Else, LLVM could be the one target of choice for many PL's 
 "reference" implementation. I'd like to know rationales.


 
 AIUI, the standard explanation is that exception support on Windows requires 
 SEH which is covered by a patent owned by Borland/Microsoft. But I have a 
 hard time buying that explanation because non-MS compilers like GCC and DMC 
 support exceptions on windows just fine - so why not LLVM, too?


AFAICT, that explanation is absolute bollocks.

SEH is *not* covered by a patent. The Borland patent that people talk 
about refers to a particular implementation detail which is a workaround 
for an absolutely horrific Microsoft bug.
The idea is to use the exception handler pointer (which is in 
thread-local storage(TLS)) to track which exception table to use.
Instead of pointing to your exception handler, it points to a thunk (one 
for each try block) which sets a pointer to the try block table, then 
the exception handler.
The reason for doing this, is that you need a TLS slot to store which 
try block you're in.
Unfortunately, Windows' thread local storage is hopelessly broken for 
DLLs. The exception handler pointer is just about the only TLS slot 
guaranteed to be available, so it allows you to escape the bug.

Now since the idea is just a straightforward application of thunks, I 
wonder if it really satisfies the patent requirement for non-obviousness.

But regardless, for D, Rainer has put code into druntime which fixes the 
bug! So actually a D implementation can use any thread-local slot.
<g>



 Apr 05 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Don" <nospam nospam.com> wrote in message 
news:inf4hj$3mg$1 digitalmars.com...

 Nick Sabalausky wrote:

 "spir" <denis.spir gmail.com> wrote in message 
 news:mailman.3141.1301915290.4748.digitalmars-d puremagic.com...

 On 04/04/2011 07:26 AM, Nick Sabalausky wrote:

 As far as LDC2, LLVM's uselessness on windows is a bit of a showstopper 
 for
 many people. And the LLVM project doesn't appear to be interested in 
 doing
 much about it. (Note I didn't say they *aren't* interested in getting 
 it
 working. That's not something I could even pretend to know. I'm just 
 saying
 that, at the very least, it *looks* like they don't care. And, for 
 better or
 worse, perception does count for a lot.)


 Yop, too bad. Else, LLVM could be the one target of choice for many PL's 
 "reference" implementation. I'd like to know rationales.


 AIUI, the standard explanation is that exception support on Windows 
 requires SEH which is covered by a patent owned by Borland/Microsoft. But 
 I have a hard time buying that explanation because non-MS compilers like 
 GCC and DMC support exceptions on windows just fine - so why not LLVM, 
 too?


 AFAICT, that explanation is absolute bollocks.

 SEH is *not* covered by a patent. The Borland patent that people talk 
 about refers to a particular implementation detail which is a workaround 
 for an absolutely horrific Microsoft bug.
 The idea is to use the exception handler pointer (which is in thread-local 
 storage(TLS)) to track which exception table to use.
 Instead of pointing to your exception handler, it points to a thunk (one 
 for each try block) which sets a pointer to the try block table, then the 
 exception handler.
 The reason for doing this, is that you need a TLS slot to store which try 
 block you're in.
 Unfortunately, Windows' thread local storage is hopelessly broken for 
 DLLs. The exception handler pointer is just about the only TLS slot 
 guaranteed to be available, so it allows you to escape the bug.


Interesting. (And could be another reason we need to get the DDL project up 
and running again :) )


 Now since the idea is just a straightforward application of thunks, I 
 wonder if it really satisfies the patent requirement for non-obviousness.

 But regardless, for D, Rainer has put code into druntime which fixes the 
 bug! So actually a D implementation can use any thread-local slot.
 <g>


Does that mean LLVM doesn't need exception support on Windows in order for 
LDC to support exceptions on windows?



 Apr 05 2011



  parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


== Quote from Nick Sabalausky (a a.a)'s article

 "Don" <nospam nospam.com> wrote in message
 news:inf4hj$3mg$1 digitalmars.com...

 Nick Sabalausky wrote:

 "spir" <denis.spir gmail.com> wrote in message
 news:mailman.3141.1301915290.4748.digitalmars-d puremagic.com...

 On 04/04/2011 07:26 AM, Nick Sabalausky wrote:

 As far as LDC2, LLVM's uselessness on windows is a bit of a showstopper
 for
 many people. And the LLVM project doesn't appear to be interested in
 doing
 much about it. (Note I didn't say they *aren't* interested in getting
 it
 working. That's not something I could even pretend to know. I'm just
 saying
 that, at the very least, it *looks* like they don't care. And, for
 better or
 worse, perception does count for a lot.)


 Yop, too bad. Else, LLVM could be the one target of choice for many PL's
 "reference" implementation. I'd like to know rationales.


 AIUI, the standard explanation is that exception support on Windows
 requires SEH which is covered by a patent owned by Borland/Microsoft. But
 I have a hard time buying that explanation because non-MS compilers like
 GCC and DMC support exceptions on windows just fine - so why not LLVM,
 too?


 AFAICT, that explanation is absolute bollocks.

 SEH is *not* covered by a patent. The Borland patent that people talk
 about refers to a particular implementation detail which is a workaround
 for an absolutely horrific Microsoft bug.
 The idea is to use the exception handler pointer (which is in thread-local
 storage(TLS)) to track which exception table to use.
 Instead of pointing to your exception handler, it points to a thunk (one
 for each try block) which sets a pointer to the try block table, then the
 exception handler.
 The reason for doing this, is that you need a TLS slot to store which try
 block you're in.
 Unfortunately, Windows' thread local storage is hopelessly broken for
 DLLs. The exception handler pointer is just about the only TLS slot
 guaranteed to be available, so it allows you to escape the bug.


 Interesting. (And could be another reason we need to get the DDL project up
 and running again :) )

 Now since the idea is just a straightforward application of thunks, I
 wonder if it really satisfies the patent requirement for non-obviousness.

 But regardless, for D, Rainer has put code into druntime which fixes the
 bug! So actually a D implementation can use any thread-local slot.
 <g>


 Does that mean LLVM doesn't need exception support on Windows in order for
 LDC to support exceptions on windows?


I would have thought it would still need to implement the EH tables in the same
way that the runtime code in Druntime/Phobos expects it to be. But I wouldn't
know
just how tied to the LLVM backend LDC is with exceptions.



 Apr 05 2011



prev sibling  parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


== Quote from Caligo (iteronvexor gmail.com)'s article

 I don't understand why so much time is spent on such a small issue as
 octal syntax while there has been no discussion on how to recruit more
 developers to work on GDC or LDC2.  You could have the perfect
 language, but it wouldn't mean anything if you don't have a stable and
 reliable compiler for it.  GDC has one active developer, and who knows
 how long he'll stay active.  I don't want to see GDC die a second
 time.  LDC2, same situation.


I'll be around for at least another week. Not that is a vote of confidence for
you. :o)



 Apr 04 2011



prev sibling  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On 2011-04-03 18:03, Caligo wrote:

 I don't understand why so much time is spent on such a small issue as
 octal syntax while there has been no discussion on how to recruit more
 developers to work on GDC or LDC2.  You could have the perfect
 language, but it wouldn't mean anything if you don't have a stable and
 reliable compiler for it.  GDC has one active developer, and who knows
 how long he'll stay active.  I don't want to see GDC die a second
 time.  LDC2, same situation.


I think that it's essentially a classic case of bikeshedding. It doesn't take 
much to understand, so it's something that pretty much anyone can have an 
opinion on and comment on. So, they do. Whereas with more complicated topics, 
it takes enough time and effort to understand them, that people often don't 
know enough to have an opinion on them and aren't really able to comment on 
them.

And as far as getting people to work on actual code goes, that's a whole other 
level of time committment that many can't or won't give.

It would be worth a lot to the community if a larger percentage of the 
community pitched in and helped write and fix code - be it for dmd, Phobos, 
gdc, qtd, or whatever. But we need developers who have both the time, skills, 
and desire to work on those projects, and the number of developers who have 
all three of those is unfortunately rather small.

So, all too often, it's bikeshed issues that get the most focus and attention, 
and the stuff that really needs to get worked on isn't helped by that. But 
unfortunately, I think that that's pretty typical for this type of community. 
There are always more people with the time and desire to comment than there 
are with the time, desire, and skill to actually get work done on what the 
community needs work done on.

- Jonathan M Davis



 Apr 03 2011



  parent  dsimcha <dsimcha yahoo.com>  writes:


== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article

 It would be worth a lot to the community if a larger percentage of the
 community pitched in and helped write and fix code - be it for dmd, Phobos,
 gdc, qtd, or whatever. But we need developers who have both the time, skills,
 and desire to work on those projects, and the number of developers who have
 all three of those is unfortunately rather small.


One of the reasons I don't work on these projects but do contribute
significantly
to Phobos and druntime is because, when I'm doing volunteer work on my own free
time, I don't want to deal with legacy code in legacy languages.  If I'm going
to
do something for the fun of it, then I want to do it from scratch or from a
codebase that I really like, in pure D.

Secondly, these projects tend to require a comprehensive understanding of a
large
codebase.  Things like optimizing the GC or cleaning up std.range or
std.algorithm
(which I've done) involve dealing with a single module, only a few thousand
lines
of code.  I can just dive in, fix what needs fixing and get out, rather than
embarking on a long-term commitment.



 Apr 03 2011



prev sibling  parent reply Dan Olson <zans.is.for.cans yahoo.com>  writes:


Walter Bright <newshound2 digitalmars.com> writes:


 I can see that the syntax octal!677 can be a bit off-putting at first,
 simply because it is not what we're used to. But give it a chance.


Thought I'd test drive octal!.  I'm still on v2.051 though.

writefln("%o", octal!777);    -> 777
writefln("%o", octal!0777);   -> 511 (0ops)

Maybe in a new version the second line will generate a error for the
leading zero on the second line?

-- 
Dan



 Apr 03 2011



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 4/3/2011 1:23 PM, Dan Olson wrote:

 Thought I'd test drive octal!.  I'm still on v2.051 though.

 writefln("%o", octal!777);    ->  777
 writefln("%o", octal!0777);   ->  511 (0ops)

 Maybe in a new version the second line will generate a error for the
 leading zero on the second line?


Yes, it will.



 Apr 03 2011



  parent reply Daniel Gibson <metalcaedes gmail.com>  writes:


Am 03.04.2011 22:38, schrieb Walter Bright:

 On 4/3/2011 1:23 PM, Dan Olson wrote:

 Thought I'd test drive octal!.  I'm still on v2.051 though.

 writefln("%o", octal!777);    ->  777
 writefln("%o", octal!0777);   ->  511 (0ops)

 Maybe in a new version the second line will generate a error for the
 leading zero on the second line?


 
 Yes, it will.


What about octal!"0777"? I'm not even sure what it should do (ignore 0?
complain? behave like the old 0777?)



 Apr 03 2011



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 4/3/2011 1:42 PM, Daniel Gibson wrote:

 Am 03.04.2011 22:38, schrieb Walter Bright:

 On 4/3/2011 1:23 PM, Dan Olson wrote:

 Thought I'd test drive octal!.  I'm still on v2.051 though.

 writefln("%o", octal!777);    ->   777
 writefln("%o", octal!0777);   ->   511 (0ops)

 Maybe in a new version the second line will generate a error for the
 leading zero on the second line?


 Yes, it will.


 What about octal!"0777"?


No.


 I'm not even sure what it should do (ignore 0?
 complain? behave like the old 0777?)


It's seems clear to me. octal!"0777" should generate 777 octal.



 Apr 03 2011



  parent  Daniel Gibson <metalcaedes gmail.com>  writes:


Am 03.04.2011 22:47, schrieb Walter Bright:

 On 4/3/2011 1:42 PM, Daniel Gibson wrote:

 Am 03.04.2011 22:38, schrieb Walter Bright:

 On 4/3/2011 1:23 PM, Dan Olson wrote:

 Thought I'd test drive octal!.  I'm still on v2.051 though.

 writefln("%o", octal!777);    ->   777
 writefln("%o", octal!0777);   ->   511 (0ops)

 Maybe in a new version the second line will generate a error for the
 leading zero on the second line?


 Yes, it will.


 What about octal!"0777"?


 
 No.
 

 I'm not even sure what it should do (ignore 0?
 complain? behave like the old 0777?)


 
 It's seems clear to me. octal!"0777" should generate 777 octal.
 


Hm yes, you're right. I think I was having a knot in my brain from octal!0777 ;)



 Apr 03 2011



prev sibling  parent  Adam D. Ruppe <destructionator gmail.com>  writes:


Daniel Gibson wrote:

 What about octal!"0777"?


The current implementation ignores it. From the comment:

/* The leading zero is allowed, but not required. */

(The actual string -> int code gives it no special treatment.
sum += x * 0 makes no difference.)



 Apr 03 2011



prev sibling next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"spir" <denis.spir gmail.com> wrote in message 
news:mailman.3064.1301831318.4748.digitalmars-d puremagic.com...

 On 04/03/2011 02:52 AM, bearophile wrote:

 Michel Fortin:


 The new syntax is certainly usable, it's just inelegant and hackish.
 Its your language, it's your choice, and I'll admit it won't affect me
 much.


 My suggestions for Walter are:
 - To turn 01 .. 07 too into errors;
 - to deprecate the octal! Phobos template.
 - To introduce the 0o leading that works from 0o0 to the uint.max;
 - To change the new error message, so it suggests to use 0o.
 - To ask opinions to the community here next time before changing things 
 in D2/D3 :-)


 I'm very surprised of this move -- aside the concrete details. What I 
 point out here is how far sentiments about what is "obvious" or "correct" 
 can be, for a given issue, that most of us considered wrong for the same 
 reason.

 When I introduced the topic of octal notation 0nnn beeing bad, I was 100% 
 sure that (if a move was ever made) either octals would be thrown out of D 
 all together for beeing nearly useless, or the syntax would be fixed --  
 the "obvious" "correct" solution if octals remain. While I new about 
 octal!, this was so hackish and obviously wrong *for me*, that I did not 
 even imagine one second it could become the "official" solution.
 I'm certainly not the only one.
 Questions of detail, sure, but we all know what the details hide ;-)


Sounds to me like you wanted a faster horse instead of a car ;)



 Apr 03 2011



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sun, 03 Apr 2011 07:48:24 -0400, spir <denis.spir gmail.com> wrote:


 On 04/03/2011 02:52 AM, bearophile wrote:

 Michel Fortin:


 The new syntax is certainly usable, it's just inelegant and hackish.
 Its your language, it's your choice, and I'll admit it won't affect me
 much.


 My suggestions for Walter are:
 - To turn 01 .. 07 too into errors;
 - to deprecate the octal! Phobos template.
 - To introduce the 0o leading that works from 0o0 to the uint.max;
 - To change the new error message, so it suggests to use 0o.
 - To ask opinions to the community here next time before changing  
 things in D2/D3 :-)


 I'm very surprised of this move -- aside the concrete details. What I  
 point out here is how far sentiments about what is "obvious" or  
 "correct" can be, for a given issue, that most of us considered wrong  
 for the same reason.

 When I introduced the topic of octal notation 0nnn beeing bad, I was  
 100% sure that (if a move was ever made) either octals would be thrown  
 out of D all together for beeing nearly useless, or the syntax would be  
 fixed -- the "obvious" "correct" solution if octals remain. While I new  
 about octal!, this was so hackish and obviously wrong *for me*, that I  
 did not even imagine one second it could become the "official" solution.
 I'm certainly not the only one.
 Questions of detail, sure, but we all know what the details hide ;-)


Octal literals *are* out of the language, it's no longer supported.   
Because of historical reasons, the syntax is disallowed (otherwise, ported  
code from C that used octal notation would be horrifically broken).

The octal template is a separate addition to allow octal in the very few  
places it is needed.

IIRC, you never complained that octal notation is horrible because you  
wanted to *use* octal, it's because you *accidentally* used it.  This  
change fixes your problem, you can't accidentally use the octal literal  
notation.  So why the complaints?

-Steve



 Apr 04 2011



  parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 On Sun, 03 Apr 2011 07:48:24 -0400, spir <denis.spir gmail.com> wrote:

 On 04/03/2011 02:52 AM, bearophile wrote:

 Michel Fortin:


 The new syntax is certainly usable, it's just inelegant and hackish.
 Its your language, it's your choice, and I'll admit it won't affect me
 much.


 My suggestions for Walter are:
 - To turn 01 .. 07 too into errors;
 - to deprecate the octal! Phobos template.
 - To introduce the 0o leading that works from 0o0 to the uint.max;
 - To change the new error message, so it suggests to use 0o.
 - To ask opinions to the community here next time before changing
 things in D2/D3 :-)


 I'm very surprised of this move -- aside the concrete details. What I
 point out here is how far sentiments about what is "obvious" or
 "correct" can be, for a given issue, that most of us considered wrong
 for the same reason.

 When I introduced the topic of octal notation 0nnn beeing bad, I was
 100% sure that (if a move was ever made) either octals would be thrown
 out of D all together for beeing nearly useless, or the syntax would be
 fixed -- the "obvious" "correct" solution if octals remain. While I new
 about octal!, this was so hackish and obviously wrong *for me*, that I
 did not even imagine one second it could become the "official" solution.
 I'm certainly not the only one.
 Questions of detail, sure, but we all know what the details hide ;-)


 Octal literals *are* out of the language, it's no longer supported.
 Because of historical reasons, the syntax is disallowed (otherwise, ported
 code from C that used octal notation would be horrifically broken).
 The octal template is a separate addition to allow octal in the very few
 places it is needed.
 IIRC, you never complained that octal notation is horrible because you
 wanted to *use* octal, it's because you *accidentally* used it.  This
 change fixes your problem, you can't accidentally use the octal literal
 notation.  So why the complaints?
 -Steve


Both ways compile down to the same instruction.

auto a = 0777;          // movl   $0x1ff,-0x4(%ebp)
auto b = octal!777;     // movl   $0x1ff,-0x8(%ebp)


The only real difference is the latter method:
- Instantiates and emits a (possibly unwanted) template, so those who still
believe in bloat are kicking themselves.
- Adds a seemingly useless library dependency on something the compiler *can* do
automatically.
- Takes 100% longer to compile from source to object file (in comparison to the
time it takes to output the former).

Boo hoo. :)



 Apr 04 2011



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Mon, 04 Apr 2011 11:16:32 -0400, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 On Sun, 03 Apr 2011 07:48:24 -0400, spir <denis.spir gmail.com> wrote:

 On 04/03/2011 02:52 AM, bearophile wrote:

 Michel Fortin:


 The new syntax is certainly usable, it's just inelegant and hackish.
 Its your language, it's your choice, and I'll admit it won't affect  






 me

 much.


 My suggestions for Walter are:
 - To turn 01 .. 07 too into errors;
 - to deprecate the octal! Phobos template.
 - To introduce the 0o leading that works from 0o0 to the uint.max;
 - To change the new error message, so it suggests to use 0o.
 - To ask opinions to the community here next time before changing
 things in D2/D3 :-)


 I'm very surprised of this move -- aside the concrete details. What I
 point out here is how far sentiments about what is "obvious" or
 "correct" can be, for a given issue, that most of us considered wrong
 for the same reason.

 When I introduced the topic of octal notation 0nnn beeing bad, I was
 100% sure that (if a move was ever made) either octals would be thrown
 out of D all together for beeing nearly useless, or the syntax would  


 be

 fixed -- the "obvious" "correct" solution if octals remain. While I  


 new

 about octal!, this was so hackish and obviously wrong *for me*, that I
 did not even imagine one second it could become the "official"  


 solution.

 I'm certainly not the only one.
 Questions of detail, sure, but we all know what the details hide ;-)


 Octal literals *are* out of the language, it's no longer supported.
 Because of historical reasons, the syntax is disallowed (otherwise,  
 ported
 code from C that used octal notation would be horrifically broken).
 The octal template is a separate addition to allow octal in the very few
 places it is needed.
 IIRC, you never complained that octal notation is horrible because you
 wanted to *use* octal, it's because you *accidentally* used it.  This
 change fixes your problem, you can't accidentally use the octal literal
 notation.  So why the complaints?
 -Steve


 Both ways compile down to the same instruction.

 auto a = 0777;          // movl   $0x1ff,-0x4(%ebp)
 auto b = octal!777;     // movl   $0x1ff,-0x8(%ebp)


 The only real difference is the latter method:
 - Instantiates and emits a (possibly unwanted) template, so those who  
 still
 believe in bloat are kicking themselves.


That is something that D suffers from in general.  All CFTE-only templates  
shouild be optimized out (e.g. isInputRange, etc.).  It seems every  
release of phobos adds more templates, and grows in size both the library  
and the traditional "hello world" program.

-Steve



 Apr 04 2011



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 4/4/2011 8:19 AM, Steven Schveighoffer wrote:

 That is something that D suffers from in general. All CFTE-only templates
 shouild be optimized out (e.g. isInputRange, etc.). It seems every release of
 phobos adds more templates, and grows in size both the library and the
 traditional "hello world" program.


That's something we have to fix sooner or later.



 Apr 04 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrej Mitrovic" <none none.none> wrote in message 
news:in8060$lt3$1 digitalmars.com...

 https://github.com/D-Programming-Language/phobos/commit/83f99df573c089cc186ef370cb691c2f8a25c873
 https://github.com/D-Programming-Language/phobos/commit/88904f7795a94b23e750e10a2addc90783089de7

 If I didn't know it better I would think it's still April 1st. :D


Yea! I stumbled onto that, too. IIRC, I let out a rather audible "Whoohoo!" 
:)



 Apr 03 2011



  parent  Don <nospam nospam.com>  writes:


Nick Sabalausky wrote:

 "Andrej Mitrovic" <none none.none> wrote in message 
 news:in8060$lt3$1 digitalmars.com...

 https://github.com/D-Programming-Language/phobos/commit/83f99df573c089cc186ef370cb691c2f8a25c873
 https://github.com/D-Programming-Language/phobos/commit/88904f7795a94b23e750e10a2addc90783089de7

 If I didn't know it better I would think it's still April 1st. :D


 
 Yea! I stumbled onto that, too. IIRC, I let out a rather audible "Whoohoo!" 
 :)
 
 


Me too.



 Apr 04 2011