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

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

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

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

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

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

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

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

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=


 for defining other user-defined literals. Adding 0o or whatever would=20
 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?

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

"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

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

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

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

"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

"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

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

"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

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

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

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

"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

"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

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

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

"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

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

"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

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

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

"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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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

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

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


 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

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

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

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

"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

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

"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

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


 "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

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


 "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

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


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


 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>


 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

"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

"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  






 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  


 fixed -- the "obvious" "correct" solution if octals remain. While I  


 about octal!, this was so hackish and obviously wrong *for me*, that I
 did not even imagine one second it could become the "official"  


 I'm certainly not the only one.
 Questions of detail, sure, but we all know what the details hide ;-)


 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

"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

Caligo <iteronvexor gmail.com> writes:

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

Apr 09 2011

D Programming

C/C++ Programming

Other

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