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 ;-)
No, that's C's last century's "#" prefix. 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