• Yigal Chripun (10/10) Nov 20 2009 Based on recent discussions on the NG a few features were
• Ellery Newcomer (6/23) Nov 20 2009 s/function pointers/type declarations/
• Nick Sabalausky (13/24) Nov 20 2009 s/reverse_foreach/foreach_reverse/ ;)
• Adam D. Ruppe (10/12) Nov 20 2009 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it seems
• Bill Baxter (6/13) Nov 20 2009 Exactly what I was thinking. 0o08.
• Justin Johansson (2/18) Nov 20 2009 Agree on all points. This is a sensible suggestion (IMHO).
• Leandro Lucarella (9/24) Nov 20 2009 And it is consistent with Python 3.0, if anybody cares ;)
• Bill Baxter (9/26) Nov 20 2009 or even
• Leandro Lucarella (10/32) Nov 20 2009 I didn't get the... joke?
• Bill Baxter (11/35) Nov 20 2009 ote:
• Justin Johansson (3/35) Nov 20 2009 What? I don't know that!
• Bill Baxter (12/47) Nov 20 2009 wrote:
• Leandro Lucarella (14/44) Nov 20 2009 I thought about the Monty Python sketch, but I didn't get your joke stil...
• Lionello Lunesu (4/5) Nov 20 2009 http://www.youtube.com/watch?v=_f_p0CgPeyA
• Yigal Chripun (3/33) Nov 20 2009 agree two all counts.
• Justin Johansson (34/68) Nov 20 2009 On 1. I understand you mean floating point literals without digits on
• Nick Sabalausky (9/34) Nov 21 2009 I'm not sure I understand the usefulness of doing that, or what exactly ...
• Justin Johansson (28/69) Nov 21 2009 I wasn't thinking XSLT particularly.
• Chad J (23/56) Nov 21 2009 Thank you for the well written explanation.
• Travis Boucher (14/76) Nov 21 2009 Face it, XML is a text base markup language, not a programming language....
• Ellery Newcomer (6/43) Nov 20 2009
• Andrei Alexandrescu (3/48) Nov 20 2009 This I'm on board with. 0o is too much like a practical joke.
• Bill Baxter (4/53) Nov 20 2009 0c works for me. 0o000-0o000 woulda been fun to write though. Looks lik...
• Justin Johansson (12/32) Nov 20 2009 Okay let's go for some consistency then.
• Bill Baxter (14/45) Nov 20 2009 lly
• Yigal Chripun (10/59) Nov 20 2009 in the short term I wouldn't mind if they would be typed as:
• Walter Bright (2/9) Nov 20 2009 Is there any language that does this?
• Don (2/13) Nov 21 2009 It's trivial to do that with CTFE!
• =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= (5/16) Nov 21 2009 "Integers can be specified in any base supported by Integer.parseInt(),
• Walter Bright (4/21) Nov 21 2009 Thanks, I also discovered that Ada supports it.
• KennyTM~ (2/63) Nov 21 2009 What's the point of using bases other than 2, 8, 10, 16, 36 and 64?
• Nick Sabalausky (3/17) Nov 21 2009 Numeric processing, maybe?
• Leandro Lucarella (12/22) Nov 21 2009 Are there any common uses for bases other than 2, 8, 10 and 16 that make...
• BCS (2/70) Nov 24 2009 Base 13 is useful in literature.
• Nick Sabalausky (7/11) Nov 25 2009 Also, base 4 is very useful on Parallax's Propeller microcontroller beca...
• Lars T. Kyllingstad (8/40) Nov 20 2009 It would definitely be a problem if octal literals disappeared from the
• Justin Johansson (2/46) Nov 20 2009 Good point. Few if any other of us though of that! :-)
• Justin Johansson (2/14) Nov 20 2009 s/though/thought/
• Leandro Lucarella (14/25) Nov 20 2009 This was discussed before, there is a bug report filled by Don too:
• Bill Baxter (13/53) Nov 20 2009 ers.
• Justin Johansson (6/52) Nov 20 2009 octal(755)?
• Bill Baxter (10/74) Nov 20 2009 r
• Justin Johansson (5/74) Nov 20 2009 Thanks for clarifying your position;
• Bill Baxter (13/98) Nov 20 2009 at
• Leandro Lucarella (17/29) Nov 20 2009 Please, understand this: IS NOT RARE IF YOU DO POSIX SYSTEM PROGRAMMING.
• Don (11/33) Nov 20 2009 That's quite a false dichotomy! Octal literals are used for POSIX file
• Lars T. Kyllingstad (3/6) Nov 21 2009 That I agree with. It looks like a zero-padded decimal.
• Travis Boucher (5/22) Nov 20 2009 Make version() statements case insensitive, although I guess that would
• Nick Sabalausky (12/35) Nov 21 2009 Yes! Capitalization consistency in the predefined versions! If it needs ...
• Travis Boucher (6/44) Nov 21 2009 In alot of places, I think he tried to use GCC's capitalization. It is
• Walter Bright (3/13) Nov 21 2009 The choices were not random. They coincided with the common usage of the...
• Leandro Lucarella (10/25) Nov 21 2009 Right, like OSX.
• Travis Boucher (5/23) Nov 21 2009 http://predef.sourceforge.net/preos.html Has a decent list of macros
• Nick Sabalausky (3/16) Nov 21 2009 To the average D user they may as well be random.
• Chad J (3/7) Nov 21 2009 I'd at least like a function that returns random D users. And not the
• Steven Schveighoffer (5/18) Nov 23 2009 Makes sense, I always have trouble re-capitalizing version statements wh...
• klickverbot (6/7) Nov 21 2009 /agree
• Justin Johansson (2/47) Nov 20 2009 Sweet. I'm curious though, have you ever programmed in BrainF? Ha :-)
• Don (6/21) Nov 23 2009 So weak that they're pretty much useless:
• bearophile (7/12) Nov 23 2009 I have used that for something unrelated that deserves (as in Fortress) ...
• Don (6/20) Nov 23 2009 There seems to be no point in having a *single* integer value, shared
• bearophile (7/9) Nov 23 2009 It doesn't reduce flexibility at all, because if you need something more...
• dsimcha (28/37) Nov 23 2009 about single-module 500-lines long programs that replace some scripts; a...
• bearophile (8/11) Nov 23 2009 "Scala" means "scalable language", it's supposed to be designed to be ab...
• retard (22/31) Nov 23 2009 Have you any idea what you are talking about? In Scala arrays are
• retard (3/6) Nov 23 2009 That's a library issue. Has nothing to do with the language.
• dsimcha (5/11) Nov 23 2009 I agree completely, but for all practical purposes basic parts of the st...
• =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= (7/19) Nov 23 2009 Sure you can!
• Bill Baxter (11/36) Nov 23 2009 ck,
• =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= (6/39) Nov 23 2009 Fair enough. :) I do think I need the dup, though, since the literal is
• Bill Baxter (8/55) Nov 23 2009 mail.com>
• Denis Koroskin (10/31) Nov 23 2009 e
• retard (19/52) Nov 23 2009 Or even bettar
• dsimcha (3/55) Nov 23 2009 Notice the word canonical in my orig. post. By this I meant a "regular"...
• Don (13/21) Nov 23 2009 I meant future D flexibility.
• Bill Baxter (8/12) Nov 23 2009 One variable, and one operator, >=.
• Walter Bright (13/24) Nov 25 2009 The way to use it would be:
• Don (3/31) Nov 25 2009 You cannot use version(int) inside libraries. You can only use it for
• Don (16/48) Nov 25 2009 And the other stupid case is when an API changes in a later version.
• bearophile (6/13) Nov 23 2009 You seem one of the best programmers I've seen in tens of years, I'd lik...
• bearophile (3/4) Nov 23 2009 I meant one of more constant numbers, of course :-)
• Yigal Chripun (14/49) Nov 25 2009 IMO, computer scientists are over-rated. The only great (as in very

Yigal Chripun <yigal100 gmail.com> writes:

Based on recent discussions on the NG a few features were 
deprecated/removed from D, such as typedef and C style struct initializers.

IMO this cleanup and polish is important and all successful languages do 
such cleanup for major releases (Python and Ruby come to mind). I'm glad 
to see that D follows in those footsteps instead of accumulating craft 
like C++ does.


As part of this trend of cleaning up D before the release of D2, what 
other features/craft should be removed/deprecated?

I suggest reverse_foreach and c style function pointers

please add your candidates for removal.

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

Yigal Chripun wrote:
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct initializers.
 
 IMO this cleanup and polish is important and all successful languages do
 such cleanup for major releases (Python and Ruby come to mind). I'm glad
 to see that D follows in those footsteps instead of accumulating craft
 like C++ does.
 
 
 As part of this trend of cleaning up D before the release of D2, what
 other features/craft should be removed/deprecated?
 
 I suggest reverse_foreach and c style function pointers
 
 please add your candidates for removal.
 
 

s/function pointers/type declarations/

also permitting

int[] a = [1,2,3,];

but not

a = [1,2,3,];

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

"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct 
 initializers.

 IMO this cleanup and polish is important and all successful languages do 
 such cleanup for major releases (Python and Ruby come to mind). I'm glad 
 to see that D follows in those footsteps instead of accumulating craft 
 like C++ does.


 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

s/reverse_foreach/foreach_reverse/ ;)

1. Floating point literals without digits on *both* sides!!! "1.", ".1" --> 
Useless hindrance to future language expansion!

2. Octal literals! I think it'd be great to have a new octal syntax, or even 
better, a general any-positive-inter-base syntax. But until that finally 
happens, I don't want "010 == 8" preserved. And I don't think the ability to 
have an octal literal is important enough that lacking it for a while is a 
problem. And if porting-from-C really has to be an issue, then just make 
0[0-9_]+ an error for a transitionary period (or forever - it'd at least be 
better than maintaining "010 == 8").

3. Also the comma operator, but that's already been recently discussed.

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, or even 
 better, a general any-positive-inter-base syntax.

Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it seems
logical that octal should be 0o10.

It looks silly, but it fits the pattern, provides the literal for those
who use it, and isn't valid right now.

Actually, I feel like DMC used to accept that, but testing now shows it
doesn't, so I must just be mistaken.


-- 
Adam D. Ruppe
http://arsdnet.net

Bill Baxter <wbaxter gmail.com> writes:

On Fri, Nov 20, 2009 at 2:12 PM, Adam D. Ruppe
<destructionator gmail.com> wrote:
 On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, or even
 better, a general any-positive-inter-base syntax.

 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it seems
 logical that octal should be 0o10.

 It looks silly, but it fits the pattern, provides the literal for those
 who use it, and isn't valid right now.

Exactly what I was thinking. 0o08.
Except I don't think it looks so silly.
And even if it does look silly, who cares.  Octal literals *are* silly.  :-)

--bb

Justin Johansson <no spam.com> writes:

Bill Baxter wrote:
 On Fri, Nov 20, 2009 at 2:12 PM, Adam D. Ruppe
 <destructionator gmail.com> wrote:
 On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, or even
 better, a general any-positive-inter-base syntax.

 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it seems
 logical that octal should be 0o10.

 It looks silly, but it fits the pattern, provides the literal for those
 who use it, and isn't valid right now.

 
 Exactly what I was thinking. 0o08.
 Except I don't think it looks so silly.
 And even if it does look silly, who cares.  Octal literals *are* silly.  :-)
 
 --bb

Agree on all points.  This is a sensible suggestion (IMHO).

Leandro Lucarella <llucax gmail.com> writes:

Bill Baxter, el 20 de noviembre a las 14:10 me escribiste:
 On Fri, Nov 20, 2009 at 2:12 PM, Adam D. Ruppe
 <destructionator gmail.com> wrote:
 On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, or even
 better, a general any-positive-inter-base syntax.

 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it seems
 logical that octal should be 0o10.

 It looks silly, but it fits the pattern, provides the literal for those
 who use it, and isn't valid right now.

 
 Exactly what I was thinking. 0o08.
 Except I don't think it looks so silly.
 And even if it does look silly, who cares.  Octal literals *are* silly.  :-)

And it is consistent with Python 3.0, if anybody cares ;)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
La máquina de la moneda, mirá como te queda!
	-- Sidharta Kiwi

Bill Baxter <wbaxter gmail.com> writes:

On Fri, Nov 20, 2009 at 5:09 PM, Leandro Lucarella <llucax gmail.com> wrote=
:
 Bill Baxter, el 20 de noviembre a las 14:10 me escribiste:
 On Fri, Nov 20, 2009 at 2:12 PM, Adam D. Ruppe
 <destructionator gmail.com> wrote:
 On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, =




or even
 better, a general any-positive-inter-base syntax.

 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it see=



ms
 logical that octal should be 0o10.

 It looks silly, but it fits the pattern, provides the literal for thos=



e
 who use it, and isn't valid right now.

 Exactly what I was thinking. 0o08.
 Except I don't think it looks so silly.
 And even if it does look silly, who cares. =A0Octal literals *are* silly=


. =A0:-)
 And it is consistent with Python 3.0, if anybody cares ;)

Yikes, python even allows 0O08.
That's going to cause a little confusion.  Mind if we call you Bruce?

--bb

Leandro Lucarella <llucax gmail.com> writes:

Bill Baxter, el 20 de noviembre a las 17:18 me escribiste:
 On Fri, Nov 20, 2009 at 5:09 PM, Leandro Lucarella <llucax gmail.com> wrote:
 Bill Baxter, el 20 de noviembre a las 14:10 me escribiste:
 On Fri, Nov 20, 2009 at 2:12 PM, Adam D. Ruppe
 <destructionator gmail.com> wrote:
 On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, or even
 better, a general any-positive-inter-base syntax.

 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it seems
 logical that octal should be 0o10.

 It looks silly, but it fits the pattern, provides the literal for those
 who use it, and isn't valid right now.

 Exactly what I was thinking. 0o08.
 Except I don't think it looks so silly.
 And even if it does look silly, who cares.  Octal literals *are* silly.  :-)

 And it is consistent with Python 3.0, if anybody cares ;)

 
 Yikes, python even allows 0O08.
 That's going to cause a little confusion.  Mind if we call you Bruce?

I didn't get the... joke?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
La terapia no sirve: es mucho mejor pagar para hacer las perversiones
que para contarlas.
	-- Alberto Giordano (filósofo estilista)

Bill Baxter <wbaxter gmail.com> writes:

On Fri, Nov 20, 2009 at 5:31 PM, Leandro Lucarella <llucax gmail.com> wrote=
:
 Bill Baxter, el 20 de noviembre a las 17:18 me escribiste:
 On Fri, Nov 20, 2009 at 5:09 PM, Leandro Lucarella <llucax gmail.com> wr=


ote:
 Bill Baxter, el 20 de noviembre a las 14:10 me escribiste:
 On Fri, Nov 20, 2009 at 2:12 PM, Adam D. Ruppe
 <destructionator gmail.com> wrote:
 On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal synta=






x, or even
 better, a general any-positive-inter-base syntax.

 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it =





seems
 logical that octal should be 0o10.

 It looks silly, but it fits the pattern, provides the literal for t=





hose
 who use it, and isn't valid right now.

 Exactly what I was thinking. 0o08.
 Except I don't think it looks so silly.
 And even if it does look silly, who cares. =A0Octal literals *are* si=




lly. =A0:-)
 And it is consistent with Python 3.0, if anybody cares ;)

 Yikes, python even allows 0O08.
 That's going to cause a little confusion. =A0Mind if we call you Bruce?

 I didn't get the... joke?

It's a quote from a Monty Python sketch.  I think I heard you're
supposed to use as many Monty Python quotes as possible when
discussing Python.

--bb

Justin Johansson <no spam.com> writes:

Bill Baxter Wrote:

 On Fri, Nov 20, 2009 at 5:31 PM, Leandro Lucarella <llucax gmail.com> wrote:
 Bill Baxter, el 20 de noviembre a las 17:18 me escribiste:
 On Fri, Nov 20, 2009 at 5:09 PM, Leandro Lucarella <llucax gmail.com> wrote:
 Bill Baxter, el 20 de noviembre a las 14:10 me escribiste:
 On Fri, Nov 20, 2009 at 2:12 PM, Adam D. Ruppe
 <destructionator gmail.com> wrote:
 On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, or even
 better, a general any-positive-inter-base syntax.

 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it seems
 logical that octal should be 0o10.

 It looks silly, but it fits the pattern, provides the literal for those
 who use it, and isn't valid right now.

 Exactly what I was thinking. 0o08.
 Except I don't think it looks so silly.
 And even if it does look silly, who cares.  Octal literals *are* silly.  :-)

 And it is consistent with Python 3.0, if anybody cares ;)

 Yikes, python even allows 0O08.
 That's going to cause a little confusion.  Mind if we call you Bruce?

 I didn't get the... joke?

 
 It's a quote from a Monty Python sketch.  I think I heard you're
 supposed to use as many Monty Python quotes as possible when
 discussing Python.
 
 --bb

What?  I don't know that!

http://www.sacred-texts.com/neu/mphg/mphg.htm

Bill Baxter <wbaxter gmail.com> writes:

On Fri, Nov 20, 2009 at 6:01 PM, Justin Johansson <no spam.com> wrote:
 Bill Baxter Wrote:

 On Fri, Nov 20, 2009 at 5:31 PM, Leandro Lucarella <llucax gmail.com> wr=


ote:
 Bill Baxter, el 20 de noviembre a las 17:18 me escribiste:
 On Fri, Nov 20, 2009 at 5:09 PM, Leandro Lucarella <llucax gmail.com>=




 wrote:
 Bill Baxter, el 20 de noviembre a las 14:10 me escribiste:
 On Fri, Nov 20, 2009 at 2:12 PM, Adam D. Ruppe
 <destructionator gmail.com> wrote:
 On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal sy=








ntax, or even
 better, a general any-positive-inter-base syntax.

 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, =







it seems
 logical that octal should be 0o10.

 It looks silly, but it fits the pattern, provides the literal fo=







r those
 who use it, and isn't valid right now.

 Exactly what I was thinking. 0o08.
 Except I don't think it looks so silly.
 And even if it does look silly, who cares. =A0Octal literals *are*=






 silly. =A0:-)
 And it is consistent with Python 3.0, if anybody cares ;)

 Yikes, python even allows 0O08.
 That's going to cause a little confusion. =A0Mind if we call you Bruc=




e?
 I didn't get the... joke?

 It's a quote from a Monty Python sketch. =A0I think I heard you're
 supposed to use as many Monty Python quotes as possible when
 discussing Python.

 --bb

 What? =A0I don't know that!

 http://www.sacred-texts.com/neu/mphg/mphg.htm

Well here ya go then:
http://www.youtube.com/watch?v=3D_f_p0CgPeyA
Courtesy of Bruce, Bruce, Bruce, and myself.

--bb

Leandro Lucarella <llucax gmail.com> writes:

Bill Baxter, el 20 de noviembre a las 17:50 me escribiste:
 On Fri, Nov 20, 2009 at 5:31 PM, Leandro Lucarella <llucax gmail.com> wrote:
 Bill Baxter, el 20 de noviembre a las 17:18 me escribiste:
 On Fri, Nov 20, 2009 at 5:09 PM, Leandro Lucarella <llucax gmail.com> wrote:
 Bill Baxter, el 20 de noviembre a las 14:10 me escribiste:
 On Fri, Nov 20, 2009 at 2:12 PM, Adam D. Ruppe
 <destructionator gmail.com> wrote:
 On Fri, Nov 20, 2009 at 04:49:52PM -0500, Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, or even
 better, a general any-positive-inter-base syntax.

 Both D and DMC accept 0b0000 as a binary literal. If 0x is hex, it seems
 logical that octal should be 0o10.

 It looks silly, but it fits the pattern, provides the literal for those
 who use it, and isn't valid right now.

 Exactly what I was thinking. 0o08.
 Except I don't think it looks so silly.
 And even if it does look silly, who cares.  Octal literals *are* silly.  :-)

 And it is consistent with Python 3.0, if anybody cares ;)

 Yikes, python even allows 0O08.
 That's going to cause a little confusion.  Mind if we call you Bruce?

 I didn't get the... joke?

 
 It's a quote from a Monty Python sketch. 

I thought about the Monty Python sketch, but I didn't get your joke still
=P, now that you say that the joke *is* about the sketch, I guess you were
just emphasizing how dumb it is to allow 0O08 as an octal literal =)

 I think I heard you're supposed to use as many Monty Python quotes as
 possible when discussing Python.

=P

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hello?
Is there anybody in there?
Just nod if you can hear me.
s there anyone at home?

Lionello Lunesu <lio lunesu.remove.com> writes:

On 21-11-2009 9:50, Bill Baxter wrote:
  That's going to cause a little confusion.  Mind if we call you Bruce?



http://www.youtube.com/watch?v=_f_p0CgPeyA

Thanks for that :) hadn't seen it earlier.

L.

Yigal Chripun <yigal100 gmail.com> writes:

On 20/11/2009 23:49, Nick Sabalausky wrote:
 "Yigal Chripun"<yigal100 gmail.com>  wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct
 initializers.

 IMO this cleanup and polish is important and all successful languages do
 such cleanup for major releases (Python and Ruby come to mind). I'm glad
 to see that D follows in those footsteps instead of accumulating craft
 like C++ does.


 As part of this trend of cleaning up D before the release of D2, what
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

thanks :)

 1. Floating point literals without digits on *both* sides!!! "1.", ".1" -->
 Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax, or even
 better, a general any-positive-inter-base syntax. But until that finally
 happens, I don't want "010 == 8" preserved. And I don't think the ability to
 have an octal literal is important enough that lacking it for a while is a
 problem. And if porting-from-C really has to be an issue, then just make
 0[0-9_]+ an error for a transitionary period (or forever - it'd at least be
 better than maintaining "010 == 8").

 3. Also the comma operator, but that's already been recently discussed.

agree two all counts.

Justin Johansson <no spam.com> writes:

Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message 
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct 
 initializers.

 IMO this cleanup and polish is important and all successful languages do 
 such cleanup for major releases (Python and Ruby come to mind). I'm glad 
 to see that D follows in those footsteps instead of accumulating craft 
 like C++ does.


 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 
 s/reverse_foreach/foreach_reverse/ ;)
 
 1. Floating point literals without digits on *both* sides!!! "1.", ".1" --> 
 Useless hindrance to future language expansion!
 
 2. Octal literals! I think it'd be great to have a new octal syntax, or even 
 better, a general any-positive-inter-base syntax. But until that finally 
 happens, I don't want "010 == 8" preserved. And I don't think the ability to 
 have an octal literal is important enough that lacking it for a while is a 
 problem. And if porting-from-C really has to be an issue, then just make 
 0[0-9_]+ an error for a transitionary period (or forever - it'd at least be 
 better than maintaining "010 == 8").
 
 3. Also the comma operator, but that's already been recently discussed.

On 1.  I understand you mean floating point literals without digits on 
both sides of the decimal point should be disallowed.  On basis of this 
understanding I beg to differ on grounds that this *should* be allowed 
for future language expansion.

Rationale: Whilst D is not currently XML aware (to any meaningful level 
of standards compliance), the language may go that way in the future. 
Therefore I would suggest that the lexical form of all literals in the 
language should be aligned with, or at least include the lexical forms 
of, literals as allowed by XML Schema Part 2: Datatypes Second Edition

http://www.w3.org/TR/xmlschema-2/

Specifically this does allow digits to be omitted from either size as 
per the following lexical production:

DoubleLiteral ::=
(("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits

It is noted, of course, that D does provide the very programmer-friendly 
mechanism of allowing underscores to used to separate digits in integer 
literals.  Whilst integers with embedded underscores are not included in 
the lexical space of integers as in cited XML Schema Datatypes, I do not 
argue against them.  In other words, whatever D supports with respect to 
the lexical forms of literals is fine so long as it *does not* preclude 
    lexical forms from XML Schema Datatypes.

On 3.  I cannot see the comma operator being removed in any short space 
of time; this would have the adverse effect of introducing more problems 
  at this stage and would likely delay D2 even further.  There is a 
special case usage of comma operator expressions that I would like to 
see disallowed and that is in the declaration of array dimensions, a 
confusing situation that I have mentioned before.

Recap:  What does the following declaration mean?

int[3,4,5] x;

Does this look like a 3 dimensional array declaration in any other 
language?  Of course it is not though (in D).

Cheers
Justin Johansson

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

"Justin Johansson" <no spam.com> wrote in message 
news:he768r$244h$1 digitalmars.com...
 Nick Sabalausky wrote:
 1. Floating point literals without digits on *both* sides!!! "1.", 
 ".1" --> Useless hindrance to future language expansion!

 On 1.  I understand you mean floating point literals without digits on 
 both sides of the decimal point should be disallowed.  On basis of this 
 understanding I beg to differ on grounds that this *should* be allowed for 
 future language expansion.

 Rationale: Whilst D is not currently XML aware (to any meaningful level of 
 standards compliance), the language may go that way in the future. 
 Therefore I would suggest that the lexical form of all literals in the 
 language should be aligned with, or at least include the lexical forms of, 
 literals as allowed by XML Schema Part 2: Datatypes Second Edition

 http://www.w3.org/TR/xmlschema-2/

 Specifically this does allow digits to be omitted from either size as per 
 the following lexical production:

 DoubleLiteral ::=
 (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits

 It is noted, of course, that D does provide the very programmer-friendly 
 mechanism of allowing underscores to used to separate digits in integer 
 literals.  Whilst integers with embedded underscores are not included in 
 the lexical space of integers as in cited XML Schema Datatypes, I do not 
 argue against them.  In other words, whatever D supports with respect to 
 the lexical forms of literals is fine so long as it *does not* preclude 
 lexical forms from XML Schema Datatypes.

I'm not sure I understand the usefulness of doing that, or what exactly you 
mean by a language being XML-aware. If you mean it would help translating 
some sort of special XML files into D code, then supporting those types of 
float literals from xml would be trivial to special-case. Or if you mean 
doing some sort of XML->D translation via XSLT: in my experience, I've found 
that XSLT is in general a very poor choice for anything other than XML->XML 
translations. Other than that, I don't understand the point...?

Justin Johansson <no spam.com> writes:

Nick Sabalausky wrote:
 "Justin Johansson" <no spam.com> wrote in message 
 news:he768r$244h$1 digitalmars.com...
 Nick Sabalausky wrote:
 1. Floating point literals without digits on *both* sides!!! "1.", 
 ".1" --> Useless hindrance to future language expansion!

 On 1.  I understand you mean floating point literals without digits on 
 both sides of the decimal point should be disallowed.  On basis of this 
 understanding I beg to differ on grounds that this *should* be allowed for 
 future language expansion.

 Rationale: Whilst D is not currently XML aware (to any meaningful level of 
 standards compliance), the language may go that way in the future. 
 Therefore I would suggest that the lexical form of all literals in the 
 language should be aligned with, or at least include the lexical forms of, 
 literals as allowed by XML Schema Part 2: Datatypes Second Edition

 http://www.w3.org/TR/xmlschema-2/

 Specifically this does allow digits to be omitted from either size as per 
 the following lexical production:

 DoubleLiteral ::=
 (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits

 It is noted, of course, that D does provide the very programmer-friendly 
 mechanism of allowing underscores to used to separate digits in integer 
 literals.  Whilst integers with embedded underscores are not included in 
 the lexical space of integers as in cited XML Schema Datatypes, I do not 
 argue against them.  In other words, whatever D supports with respect to 
 the lexical forms of literals is fine so long as it *does not* preclude 
 lexical forms from XML Schema Datatypes.

 
 I'm not sure I understand the usefulness of doing that, or what exactly you 
 mean by a language being XML-aware. If you mean it would help translating 
 some sort of special XML files into D code, then supporting those types of 
 float literals from xml would be trivial to special-case. Or if you mean 
 doing some sort of XML->D translation via XSLT: in my experience, I've found 
 that XSLT is in general a very poor choice for anything other than XML->XML 
 translations. Other than that, I don't understand the point...?

I wasn't thinking XSLT particularly.

By XML aware, I meant awareness of (any parts of) the wider XML 
ecosystem in general and W3C related specs so not just XML syntax but 
including XML Schema Datatypes for example.  Obviously XSLT is something 
that would be implemented in a library rather than being reflected in a 
language but such a library would be easier to implement in a language 
that acknowledged XML Schema Datatypes.

In the case of XML syntax, note that both Scala and JavaScript support 
XML syntax at the language level (the latter via the E4X extension to 
JavaScript).  At some point in the (distant) future, D might support XML 
syntax in the language in similar fashion to Scala, who knows.  I 
understand that D1 has some ability to embed D code in HTML.  Though 
I've never used it, and considering that (X)HTML is an application of 
XML, this is at least an acknowledgement by D that HTML exists!

My point basically boils down to this.  We all accept IEEE Standard for 
Floating-Point Arithmetic (IEEE 754) as the basis for the binary 
representation of floating point data and nobody is going to argue 
against that.  In terms of the evolution of standards, XML Schema 
Datatypes does for the lexical representation of common datatypes 
(numeric and string data), what IEEE 754 does for floating point data at 
the binary level.

In the future I believe that PL's will implicitly acknowledge XML Schema 
Datatypes as much as vernacular PL's implicitly acknowledge IEEE 754 
today and that's why I took shot at your comment "Useless hindrance to 
future language expansion".

Cheers
Justin

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Justin Johansson wrote:
 
 I wasn't thinking XSLT particularly.
 
 By XML aware, I meant awareness of (any parts of) the wider XML
 ecosystem in general and W3C related specs so not just XML syntax but
 including XML Schema Datatypes for example.  Obviously XSLT is something
 that would be implemented in a library rather than being reflected in a
 language but such a library would be easier to implement in a language
 that acknowledged XML Schema Datatypes.
 
 In the case of XML syntax, note that both Scala and JavaScript support
 XML syntax at the language level (the latter via the E4X extension to
 JavaScript).  At some point in the (distant) future, D might support XML
 syntax in the language in similar fashion to Scala, who knows.  I
 understand that D1 has some ability to embed D code in HTML.  Though
 I've never used it, and considering that (X)HTML is an application of
 XML, this is at least an acknowledgement by D that HTML exists!
 
 My point basically boils down to this.  We all accept IEEE Standard for
 Floating-Point Arithmetic (IEEE 754) as the basis for the binary
 representation of floating point data and nobody is going to argue
 against that.  In terms of the evolution of standards, XML Schema
 Datatypes does for the lexical representation of common datatypes
 (numeric and string data), what IEEE 754 does for floating point data at
 the binary level.
 
 In the future I believe that PL's will implicitly acknowledge XML Schema
 Datatypes as much as vernacular PL's implicitly acknowledge IEEE 754
 today and that's why I took shot at your comment "Useless hindrance to
 future language expansion".
 
 Cheers
 Justin

Thank you for the well written explanation.

Now then, if XML is the way of the future, just shoot me now.

I know ActionScript 3 also supports XML syntax at the language level.
When I first learned this I likely had a huge look of disgust on my
face.  Something like (╬ ಠ益ಠ).  Requiring a general purpose programming
language to also implement XML is just too harsh for too little gain.
Wrap that stuff in qoutes.  D even has a rather rich selection of string
literals; too many if you ask me.  I really do not understand why XML
should have such a preferred status over every other DSL that will find
itself embedded in D code (or any other PL for that matter).

In other news, I discovered YAML.  I haven't used it enough to see if it
has a dark side or not, but so far it looks promising.  It doesn't make
my eyes bleed.  That's a good start.  It may just be worthy of me using
it instead of rolling my own encodings.

And yes, I'll roll my own encodings if I damn well feel like it.  I plan
on using D for hobby game programming in the future, so I have no desire
to drink the over-engineered koolaid that is XML.  I'll swallow SVG, but
only in small doses.  SVG is actually useful because Inkscape exists,
but I don't really intend to implement all of it, since SVG is also
quite over-engineered.

Ah, that felt good.

- Chad

Travis Boucher <boucher.travis gmail.com> writes:

Chad J wrote:
 Justin Johansson wrote:
 I wasn't thinking XSLT particularly.

 By XML aware, I meant awareness of (any parts of) the wider XML
 ecosystem in general and W3C related specs so not just XML syntax but
 including XML Schema Datatypes for example.  Obviously XSLT is something
 that would be implemented in a library rather than being reflected in a
 language but such a library would be easier to implement in a language
 that acknowledged XML Schema Datatypes.

 In the case of XML syntax, note that both Scala and JavaScript support
 XML syntax at the language level (the latter via the E4X extension to
 JavaScript).  At some point in the (distant) future, D might support XML
 syntax in the language in similar fashion to Scala, who knows.  I
 understand that D1 has some ability to embed D code in HTML.  Though
 I've never used it, and considering that (X)HTML is an application of
 XML, this is at least an acknowledgement by D that HTML exists!

 My point basically boils down to this.  We all accept IEEE Standard for
 Floating-Point Arithmetic (IEEE 754) as the basis for the binary
 representation of floating point data and nobody is going to argue
 against that.  In terms of the evolution of standards, XML Schema
 Datatypes does for the lexical representation of common datatypes
 (numeric and string data), what IEEE 754 does for floating point data at
 the binary level.

 In the future I believe that PL's will implicitly acknowledge XML Schema
 Datatypes as much as vernacular PL's implicitly acknowledge IEEE 754
 today and that's why I took shot at your comment "Useless hindrance to
 future language expansion".

 Cheers
 Justin

 
 Thank you for the well written explanation.
 
 Now then, if XML is the way of the future, just shoot me now.
 
 I know ActionScript 3 also supports XML syntax at the language level.
 When I first learned this I likely had a huge look of disgust on my
 face.  Something like (╬ ಠ益ಠ).  Requiring a general purpose programming
 language to also implement XML is just too harsh for too little gain.
 Wrap that stuff in qoutes.  D even has a rather rich selection of string
 literals; too many if you ask me.  I really do not understand why XML
 should have such a preferred status over every other DSL that will find
 itself embedded in D code (or any other PL for that matter).
 
 In other news, I discovered YAML.  I haven't used it enough to see if it
 has a dark side or not, but so far it looks promising.  It doesn't make
 my eyes bleed.  That's a good start.  It may just be worthy of me using
 it instead of rolling my own encodings.
 
 And yes, I'll roll my own encodings if I damn well feel like it.  I plan
 on using D for hobby game programming in the future, so I have no desire
 to drink the over-engineered koolaid that is XML.  I'll swallow SVG, but
 only in small doses.  SVG is actually useful because Inkscape exists,
 but I don't really intend to implement all of it, since SVG is also
 quite over-engineered.
 
 Ah, that felt good.
 
 - Chad

Face it, XML is a text base markup language, not a programming language. 
  Text is for strings, and belong in quotes.  I don't care if the 
underlying data is a structure, or some logical construct which pretends 
to be code.

XML is not a programming language.  We should not be hindered by it.  I 
do not want to have to & codes for extended characters either. 
Also, D is targeted at being a system level programming language.  XML 
does not belong in system level code (yes redhat, I am glaring at you).

We already have standards which we follow, including UTF-8/16/32.  If 
you want a to standardize the way we represent numbers beyond the way we 
are doing it, then we might as well implement full localization and 
binary formatted source code.  I guess my rant is simple, XML is XML, D 
is D, mixing them is stupid.

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message 
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct 
 initializers.

 IMO this cleanup and polish is important and all successful languages do 
 such cleanup for major releases (Python and Ruby come to mind). I'm glad 
 to see that D follows in those footsteps instead of accumulating craft 
 like C++ does.


 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 
 s/reverse_foreach/foreach_reverse/ ;)
 
 1. Floating point literals without digits on *both* sides!!! "1.", ".1" --> 
 Useless hindrance to future language expansion!
 
 2. Octal literals! I think it'd be great to have a new octal syntax, or even 
 better, a general any-positive-inter-base syntax. But until that finally 
 happens, I don't want "010 == 8" preserved. And I don't think the ability to 
 have an octal literal is important enough that lacking it for a while is a 
 problem. And if porting-from-C really has to be an issue, then just make 
 0[0-9_]+ an error for a transitionary period (or forever - it'd at least be 
 better than maintaining "010 == 8").
 
 3. Also the comma operator, but that's already been recently discussed.
 
 
 

<bikeshed>

hex literal prefix: 0x, not 0h
=>
octal literal prefix: 0c, not 0o

</bikeshed>

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Ellery Newcomer wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message 
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct 
 initializers.

 IMO this cleanup and polish is important and all successful languages do 
 such cleanup for major releases (Python and Ruby come to mind). I'm glad 
 to see that D follows in those footsteps instead of accumulating craft 
 like C++ does.


 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.", ".1" --> 
 Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax, or even 
 better, a general any-positive-inter-base syntax. But until that finally 
 happens, I don't want "010 == 8" preserved. And I don't think the ability to 
 have an octal literal is important enough that lacking it for a while is a 
 problem. And if porting-from-C really has to be an issue, then just make 
 0[0-9_]+ an error for a transitionary period (or forever - it'd at least be 
 better than maintaining "010 == 8").

 3. Also the comma operator, but that's already been recently discussed.

 
 <bikeshed>
 
 hex literal prefix: 0x, not 0h
 =>
 octal literal prefix: 0c, not 0o
 
 </bikeshed>

This I'm on board with. 0o is too much like a practical joke.

Andrei

Bill Baxter <wbaxter gmail.com> writes:

On Fri, Nov 20, 2009 at 4:45 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Ellery Newcomer wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct initializers.

 IMO this cleanup and polish is important and all successful languages do
 such cleanup for major releases (Python and Ruby come to mind). I'm glad to
 see that D follows in those footsteps instead of accumulating craft like C++
 does.


 As part of this trend of cleaning up D before the release of D2, what
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.", ".1"
 --> Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax, or
 even better, a general any-positive-inter-base syntax. But until that
 finally happens, I don't want "010 == 8" preserved. And I don't think the
 ability to have an octal literal is important enough that lacking it for a
 while is a problem. And if porting-from-C really has to be an issue, then
 just make 0[0-9_]+ an error for a transitionary period (or forever - it'd at
 least be better than maintaining "010 == 8").

 3. Also the comma operator, but that's already been recently discussed.

 <bikeshed>

 hex literal prefix: 0x, not 0h
 =>
 octal literal prefix: 0c, not 0o

 </bikeshed>

 This I'm on board with. 0o is too much like a practical joke.

0c works for me. 0o000-0o000 woulda been fun to write though.  Looks like toes.

--bb

Justin Johansson <no spam.com> writes:

Andrei Alexandrescu Wrote:

 Ellery Newcomer wrote:
 Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, or even 
 better, a general any-positive-inter-base syntax. But until that finally 
 happens, I don't want "010 == 8" preserved. And I don't think the ability to 
 have an octal literal is important enough that lacking it for a while is a 
 problem. And if porting-from-C really has to be an issue, then just make 
 0[0-9_]+ an error for a transitionary period (or forever - it'd at least be 
 better than maintaining "010 == 8").

 3. Also the comma operator, but that's already been recently discussed.

 <bikeshed>
 
 hex literal prefix: 0x, not 0h
 =>
 octal literal prefix: 0c, not 0o
 
 </bikeshed>

 
 This I'm on board with. 0o is too much like a practical joke.

Okay let's go for some consistency then.

First try. Radix character comes from 3rd character of radix name.

hexadecimal   0x
octal             0t
binary           0n

Or, second try, how about first non-digit-looking character in radix name?

hexadecimal   0h
octal             0c
binary           0b

My point being ... if there were to be a change in lexical form, a simple rule
would be nice.  Of course the rule can be anything that can be coerced to a
rule.  Hope this doesn't sound like a false choice :-)

--Justin

Bill Baxter <wbaxter gmail.com> writes:

On Fri, Nov 20, 2009 at 5:22 PM, Justin Johansson <no spam.com> wrote:
 Andrei Alexandrescu Wrote:

 Ellery Newcomer wrote:
 Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, =




or even
 better, a general any-positive-inter-base syntax. But until that fina=




lly
 happens, I don't want "010 =3D=3D 8" preserved. And I don't think the=




 ability to
 have an octal literal is important enough that lacking it for a while=




 is a
 problem. And if porting-from-C really has to be an issue, then just m=




ake
 0[0-9_]+ an error for a transitionary period (or forever - it'd at le=




ast be
 better than maintaining "010 =3D=3D 8").

 3. Also the comma operator, but that's already been recently discusse=




d.
 <bikeshed>

 hex literal prefix: 0x, not 0h
 =3D>
 octal literal prefix: 0c, not 0o

 </bikeshed>

 This I'm on board with. 0o is too much like a practical joke.

 Okay let's go for some consistency then.

 First try. Radix character comes from 3rd character of radix name.

 hexadecimal =A0 0x
 octal =A0 =A0 =A0 =A0 =A0 =A0 0t
 binary =A0 =A0 =A0 =A0 =A0 0n

 Or, second try, how about first non-digit-looking character in radix name=

?
 hexadecimal =A0 0h
 octal =A0 =A0 =A0 =A0 =A0 =A0 0c
 binary =A0 =A0 =A0 =A0 =A0 0b

 My point being ... if there were to be a change in lexical form, a simple=

 rule would be nice. =A0Of course the rule can be anything that can be coer=
ced to a rule. =A0Hope this doesn't sound like a false choice :-)

No problem!

  charToUse =3D basename[ floor(log2(log2(base))) ];

--bb

Yigal Chripun <yigal100 gmail.com> writes:

On 21/11/2009 02:45, Andrei Alexandrescu wrote:
 Ellery Newcomer wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct
 initializers.

 IMO this cleanup and polish is important and all successful
 languages do such cleanup for major releases (Python and Ruby come
 to mind). I'm glad to see that D follows in those footsteps instead
 of accumulating craft like C++ does.


 As part of this trend of cleaning up D before the release of D2,
 what other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.",
 ".1" --> Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax,
 or even better, a general any-positive-inter-base syntax. But until
 that finally happens, I don't want "010 == 8" preserved. And I don't
 think the ability to have an octal literal is important enough that
 lacking it for a while is a problem. And if porting-from-C really has
 to be an issue, then just make 0[0-9_]+ an error for a transitionary
 period (or forever - it'd at least be better than maintaining "010 ==
 8").

 3. Also the comma operator, but that's already been recently discussed.

 <bikeshed>

 hex literal prefix: 0x, not 0h
 =>
 octal literal prefix: 0c, not 0o

 </bikeshed>

 This I'm on board with. 0o is too much like a practical joke.

 Andrei

in the short term I wouldn't mind if they would be typed as: 
0baseEightXXX or what ever as long as the current syntax is removed.

in the long term, I'd like to see a more general syntax that allows to 
write numbers in any base.
something like:
[base]n[number] - e.g. 16nA0FF, 2n0101, 18nGH129, etc.
also define syntax to write a list of digits:
1024n[1005, 452, 645, 16nFFF] // each digit can also be defined in 
arbitrary base

Walter Bright <newshound1 digitalmars.com> writes:

Yigal Chripun wrote:
 in the long term, I'd like to see a more general syntax that allows to 
 write numbers in any base.
 something like:
 [base]n[number] - e.g. 16nA0FF, 2n0101, 18nGH129, etc.
 also define syntax to write a list of digits:
 1024n[1005, 452, 645, 16nFFF] // each digit can also be defined in 
 arbitrary base


Is there any language that does this?

Don <nospam nospam.com> writes:

Walter Bright wrote:
 Yigal Chripun wrote:
 in the long term, I'd like to see a more general syntax that allows to 
 write numbers in any base.
 something like:
 [base]n[number] - e.g. 16nA0FF, 2n0101, 18nGH129, etc.
 also define syntax to write a list of digits:
 1024n[1005, 452, 645, 16nFFF] // each digit can also be defined in 
 arbitrary base

 
 
 Is there any language that does this?

It's trivial to do that with CTFE!

=?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:

Walter Bright wrote:
 Yigal Chripun wrote:
 in the long term, I'd like to see a more general syntax that allows to 
 write numbers in any base.
 something like:
 [base]n[number] - e.g. 16nA0FF, 2n0101, 18nGH129, etc.
 also define syntax to write a list of digits:
 1024n[1005, 452, 645, 16nFFF] // each digit can also be defined in 
 arbitrary base

 
 
 Is there any language that does this?

"Integers can be specified in any base supported by Integer.parseInt(), 
that is any radix from 2 to 36; for example 2r101010, 8r52, 36r16, and 
42 are all the same Integer."

http://clojure.org/reader

Walter Bright <newshound1 digitalmars.com> writes:

Pelle MÃ¥nsson wrote:
 Walter Bright wrote:
 Yigal Chripun wrote:
 in the long term, I'd like to see a more general syntax that allows 
 to write numbers in any base.
 something like:
 [base]n[number] - e.g. 16nA0FF, 2n0101, 18nGH129, etc.
 also define syntax to write a list of digits:
 1024n[1005, 452, 645, 16nFFF] // each digit can also be defined in 
 arbitrary base


 Is there any language that does this?

 "Integers can be specified in any base supported by Integer.parseInt(), 
 that is any radix from 2 to 36; for example 2r101010, 8r52, 36r16, and 
 42 are all the same Integer."
 
 http://clojure.org/reader

Thanks, I also discovered that Ada supports it.

Next question, is what's the point? Any need for radices other than 2, 
8, 10 or 16? I can't think of any.

KennyTM~ <kennytm gmail.com> writes:

On Nov 21, 09 15:40, Yigal Chripun wrote:
 On 21/11/2009 02:45, Andrei Alexandrescu wrote:
 Ellery Newcomer wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct
 initializers.

 IMO this cleanup and polish is important and all successful
 languages do such cleanup for major releases (Python and Ruby come
 to mind). I'm glad to see that D follows in those footsteps instead
 of accumulating craft like C++ does.


 As part of this trend of cleaning up D before the release of D2,
 what other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.",
 ".1" --> Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax,
 or even better, a general any-positive-inter-base syntax. But until
 that finally happens, I don't want "010 == 8" preserved. And I don't
 think the ability to have an octal literal is important enough that
 lacking it for a while is a problem. And if porting-from-C really has
 to be an issue, then just make 0[0-9_]+ an error for a transitionary
 period (or forever - it'd at least be better than maintaining "010 ==
 8").

 3. Also the comma operator, but that's already been recently discussed.

 <bikeshed>

 hex literal prefix: 0x, not 0h
 =>
 octal literal prefix: 0c, not 0o

 </bikeshed>

 This I'm on board with. 0o is too much like a practical joke.

 Andrei

 in the short term I wouldn't mind if they would be typed as:
 0baseEightXXX or what ever as long as the current syntax is removed.

 in the long term, I'd like to see a more general syntax that allows to
 write numbers in any base.
 something like:
 [base]n[number] - e.g. 16nA0FF, 2n0101, 18nGH129, etc.
 also define syntax to write a list of digits:
 1024n[1005, 452, 645, 16nFFF] // each digit can also be defined in
 arbitrary base

What's the point of using bases other than 2, 8, 10, 16, 36 and 64?

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

"KennyTM~" <kennytm gmail.com> wrote in message 
news:he8a02$1jtn$1 digitalmars.com...
 On Nov 21, 09 15:40, Yigal Chripun wrote:
 in the short term I wouldn't mind if they would be typed as:
 0baseEightXXX or what ever as long as the current syntax is removed.

 in the long term, I'd like to see a more general syntax that allows to
 write numbers in any base.
 something like:
 [base]n[number] - e.g. 16nA0FF, 2n0101, 18nGH129, etc.
 also define syntax to write a list of digits:
 1024n[1005, 452, 645, 16nFFF] // each digit can also be defined in
 arbitrary base

 What's the point of using bases other than 2, 8, 10, 16, 36 and 64?

Numeric processing, maybe?

Leandro Lucarella <llucax gmail.com> writes:

KennyTM~, el 21 de noviembre a las 16:56 me escribiste:
in the long term, I'd like to see a more general syntax that allows to
write numbers in any base.
something like:
[base]n[number] - e.g. 16nA0FF, 2n0101, 18nGH129, etc.
also define syntax to write a list of digits:
1024n[1005, 452, 645, 16nFFF] // each digit can also be defined in
arbitrary base

 
 What's the point of using bases other than 2, 8, 10, 16, 36 and 64?

Are there any common uses for bases other than 2, 8, 10 and 16 that makes
language support reasonable (instead of library support)?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
He cometido pecados, he hecho el mal, he sido víctima de la envidia, el
egoísmo, la ambición, la mentira y la frivolidad, pero siempre he sido
un padre argentino que quiere que su hijo triunfe en la vida.
	-- Ricardo Vaporeso

BCS <none anon.com> writes:

Hello KennyTM~,

 On Nov 21, 09 15:40, Yigal Chripun wrote:
 
 On 21/11/2009 02:45, Andrei Alexandrescu wrote:
 
 Ellery Newcomer wrote:
 
 Nick Sabalausky wrote:
 
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct
 initializers.
 
 IMO this cleanup and polish is important and all successful
 languages do such cleanup for major releases (Python and Ruby
 come to mind). I'm glad to see that D follows in those footsteps
 instead of accumulating craft like C++ does.
 
 As part of this trend of cleaning up D before the release of D2,
 what other features/craft should be removed/deprecated?
 
 I suggest reverse_foreach and c style function pointers
 
 please add your candidates for removal.
 

 s/reverse_foreach/foreach_reverse/ ;)
 
 1. Floating point literals without digits on *both* sides!!! "1.",
 ".1" --> Useless hindrance to future language expansion!
 
 2. Octal literals! I think it'd be great to have a new octal
 syntax, or even better, a general any-positive-inter-base syntax.
 But until that finally happens, I don't want "010 == 8" preserved.
 And I don't think the ability to have an octal literal is
 important enough that lacking it for a while is a problem. And if
 porting-from-C really has to be an issue, then just make 0[0-9_]+
 an error for a transitionary period (or forever - it'd at least be
 better than maintaining "010 == 8").
 
 3. Also the comma operator, but that's already been recently
 discussed.
 

 <bikeshed>
 
 hex literal prefix: 0x, not 0h
 =>
 octal literal prefix: 0c, not 0o
 </bikeshed>
 

 This I'm on board with. 0o is too much like a practical joke.
 
 Andrei
 

 in the short term I wouldn't mind if they would be typed as:
 0baseEightXXX or what ever as long as the current syntax is removed.
 
 in the long term, I'd like to see a more general syntax that allows
 to
 write numbers in any base.
 something like:
 [base]n[number] - e.g. 16nA0FF, 2n0101, 18nGH129, etc.
 also define syntax to write a list of digits:
 1024n[1005, 452, 645, 16nFFF] // each digit can also be defined in
 arbitrary base

 What's the point of using bases other than 2, 8, 10, 16, 36 and 64?
 

Base 13 is useful in literature.

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

"BCS" <none anon.com> wrote in message 
news:a6268ffd62c8cc3b5a3ae2d73c news.digitalmars.com...
 Hello KennyTM~,
 What's the point of using bases other than 2, 8, 10, 16, 36 and 64?

 Base 13 is useful in literature.

Also, base 4 is very useful on Parallax's Propeller microcontroller because 
it's graphics stuff involves a lot of packed 2-bit values. Not that the 
Propeller is necessarily powerful enough for D, but I'd image there must be 
other embedded systems that do things with packed 2-bit values which could 
therefore benefit from base 4. 

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message 
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct 
 initializers.

 IMO this cleanup and polish is important and all successful languages do 
 such cleanup for major releases (Python and Ruby come to mind). I'm glad 
 to see that D follows in those footsteps instead of accumulating craft 
 like C++ does.


 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 
 s/reverse_foreach/foreach_reverse/ ;)
 
 1. Floating point literals without digits on *both* sides!!! "1.", ".1" --> 
 Useless hindrance to future language expansion!
 
 2. Octal literals! I think it'd be great to have a new octal syntax, or even 
 better, a general any-positive-inter-base syntax. But until that finally 
 happens, I don't want "010 == 8" preserved. And I don't think the ability to 
 have an octal literal is important enough that lacking it for a while is a 
 problem. And if porting-from-C really has to be an issue, then just make 
 0[0-9_]+ an error for a transitionary period (or forever - it'd at least be 
 better than maintaining "010 == 8").

It would definitely be a problem if octal literals disappeared from the 
language, even if only for a short while. They are pretty much the only 
sensible way to specify POSIX file permissions.

   import core.sys.posix.sys.stat;
   ...
   chmod("path/to/file", 0755);

-Lars

Justin Johansson <no spam.com> writes:

Lars T. Kyllingstad wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message 
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct 
 initializers.

 IMO this cleanup and polish is important and all successful languages 
 do such cleanup for major releases (Python and Ruby come to mind). 
 I'm glad to see that D follows in those footsteps instead of 
 accumulating craft like C++ does.


 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.", 
 ".1" --> Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax, 
 or even better, a general any-positive-inter-base syntax. But until 
 that finally happens, I don't want "010 == 8" preserved. And I don't 
 think the ability to have an octal literal is important enough that 
 lacking it for a while is a problem. And if porting-from-C really has 
 to be an issue, then just make 0[0-9_]+ an error for a transitionary 
 period (or forever - it'd at least be better than maintaining "010 == 
 8").

 
 It would definitely be a problem if octal literals disappeared from the 
 language, even if only for a short while. They are pretty much the only 
 sensible way to specify POSIX file permissions.
 
   import core.sys.posix.sys.stat;
   ...
   chmod("path/to/file", 0755);
 
 -Lars

Good point.  Few if any other of us though of that! :-)

Justin Johansson <no spam.com> writes:

Justin Johansson wrote:
 Lars T. Kyllingstad wrote:
 It would definitely be a problem if octal literals disappeared from 
 the language, even if only for a short while. They are pretty much the 
 only sensible way to specify POSIX file permissions.

   import core.sys.posix.sys.stat;
   ...
   chmod("path/to/file", 0755);

 -Lars

 
 Good point.  Few if any other of us though of that! :-)

s/though/thought/

Leandro Lucarella <llucax gmail.com> writes:

Justin Johansson, el 21 de noviembre a las 09:42 me escribiste:
It would definitely be a problem if octal literals disappeared
from the language, even if only for a short while. They are pretty
much the only sensible way to specify POSIX file permissions.

  import core.sys.posix.sys.stat;
  ...
  chmod("path/to/file", 0755);

-Lars

 
 Good point.  Few if any other of us though of that! :-)

This was discussed before, there is a bug report filled by Don too:
http://d.puremagic.com/issues/show_bug.cgi?id=2656

I do think octal literal should be there for file permissions, being
a system programming language, it would be too odd for people doing POSIX
system programming not to have a way to easily manipulate file permissions
and masks included in the language.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
"CIRILO" Y "SIRACUSA" DE "SEÑORITA MAESTRA": UNO MUERTO Y OTRO PRESO
	-- Crónica TV

Bill Baxter <wbaxter gmail.com> writes:

On Fri, Nov 20, 2009 at 3:10 PM, Lars T. Kyllingstad
<public kyllingen.nospamnet> wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct initializ=



ers.
 IMO this cleanup and polish is important and all successful languages d=



o
 such cleanup for major releases (Python and Ruby come to mind). I'm gla=



d to
 see that D follows in those footsteps instead of accumulating craft lik=



e C++
 does.


 As part of this trend of cleaning up D before the release of D2, what
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.", ".1"
 --> Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax, or
 even better, a general any-positive-inter-base syntax. But until that
 finally happens, I don't want "010 =3D=3D 8" preserved. And I don't thin=


k the
 ability to have an octal literal is important enough that lacking it for=


 a
 while is a problem. And if porting-from-C really has to be an issue, the=


n
 just make 0[0-9_]+ an error for a transitionary period (or forever - it'=


d at
 least be better than maintaining "010 =3D=3D 8").

 It would definitely be a problem if octal literals disappeared from the
 language, even if only for a short while. They are pretty much the only
 sensible way to specify POSIX file permissions.

 =A0import core.sys.posix.sys.stat;
 =A0...
 =A0chmod("path/to/file", 0755);

Well you can always do..

chmod("path/to/file", octal(755));

--bb

Justin Johansson <no spam.com> writes:

Bill Baxter wrote:
 On Fri, Nov 20, 2009 at 3:10 PM, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct initializers.

 IMO this cleanup and polish is important and all successful languages do
 such cleanup for major releases (Python and Ruby come to mind). I'm glad to
 see that D follows in those footsteps instead of accumulating craft like C++
 does.


 As part of this trend of cleaning up D before the release of D2, what
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.", ".1"
 --> Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax, or
 even better, a general any-positive-inter-base syntax. But until that
 finally happens, I don't want "010 == 8" preserved. And I don't think the
 ability to have an octal literal is important enough that lacking it for a
 while is a problem. And if porting-from-C really has to be an issue, then
 just make 0[0-9_]+ an error for a transitionary period (or forever - it'd at
 least be better than maintaining "010 == 8").

 It would definitely be a problem if octal literals disappeared from the
 language, even if only for a short while. They are pretty much the only
 sensible way to specify POSIX file permissions.

  import core.sys.posix.sys.stat;
  ...
  chmod("path/to/file", 0755);

 
 Well you can always do..
 
 chmod("path/to/file", octal(755));
 
 --bb

octal(755)?

What's the base-10 identity of that?

decimal(493) or decimal(755)?

base-16 etc.

--Justin

Bill Baxter <wbaxter gmail.com> writes:

On Fri, Nov 20, 2009 at 3:37 PM, Justin Johansson <no spam.com> wrote:
 Bill Baxter wrote:
 On Fri, Nov 20, 2009 at 3:10 PM, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct
 initializers.

 IMO this cleanup and polish is important and all successful languages
 do
 such cleanup for major releases (Python and Ruby come to mind). I'm
 glad to
 see that D follows in those footsteps instead of accumulating craft
 like C++
 does.


 As part of this trend of cleaning up D before the release of D2, what
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.", ".1=




"
 --> Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax, o=




r
 even better, a general any-positive-inter-base syntax. But until that
 finally happens, I don't want "010 =3D=3D 8" preserved. And I don't th=




ink
 the
 ability to have an octal literal is important enough that lacking it f=




or
 a
 while is a problem. And if porting-from-C really has to be an issue,
 then
 just make 0[0-9_]+ an error for a transitionary period (or forever -
 it'd at
 least be better than maintaining "010 =3D=3D 8").

 It would definitely be a problem if octal literals disappeared from the
 language, even if only for a short while. They are pretty much the only
 sensible way to specify POSIX file permissions.

 =A0import core.sys.posix.sys.stat;
 =A0...
 =A0chmod("path/to/file", 0755);

 Well you can always do..

 chmod("path/to/file", octal(755));

 --bb

 octal(755)?

 What's the base-10 identity of that?

 decimal(493) or decimal(755)?

 base-16 etc.

Fine.  Make it octal!"755" if you prefer.
The point is just that you can write a function that will convert a
number to octal for the rare cases when you need it.
You don't absolutely need octal literals.

--bb

Justin Johansson <no spam.com> writes:

Bill Baxter wrote:
 On Fri, Nov 20, 2009 at 3:37 PM, Justin Johansson <no spam.com> wrote:
 Bill Baxter wrote:
 On Fri, Nov 20, 2009 at 3:10 PM, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct
 initializers.

 IMO this cleanup and polish is important and all successful languages
 do
 such cleanup for major releases (Python and Ruby come to mind). I'm
 glad to
 see that D follows in those footsteps instead of accumulating craft
 like C++
 does.


 As part of this trend of cleaning up D before the release of D2, what
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.", ".1"
 --> Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax, or
 even better, a general any-positive-inter-base syntax. But until that
 finally happens, I don't want "010 == 8" preserved. And I don't think
 the
 ability to have an octal literal is important enough that lacking it for
 a
 while is a problem. And if porting-from-C really has to be an issue,
 then
 just make 0[0-9_]+ an error for a transitionary period (or forever -
 it'd at
 least be better than maintaining "010 == 8").

 It would definitely be a problem if octal literals disappeared from the
 language, even if only for a short while. They are pretty much the only
 sensible way to specify POSIX file permissions.

  import core.sys.posix.sys.stat;
  ...
  chmod("path/to/file", 0755);

 Well you can always do..

 chmod("path/to/file", octal(755));

 --bb

 octal(755)?

 What's the base-10 identity of that?

 decimal(493) or decimal(755)?

 base-16 etc.

 
 Fine.  Make it octal!"755" if you prefer.
 The point is just that you can write a function that will convert a
 number to octal for the rare cases when you need it.
 You don't absolutely need octal literals.
 
 --bb

Thanks for clarifying your position;
I can happily go along with that. :-)
(Sorry if at all I sounded obtuse or curt).
--Justin

Bill Baxter <wbaxter gmail.com> writes:

On Fri, Nov 20, 2009 at 3:53 PM, Justin Johansson <no spam.com> wrote:
 Bill Baxter wrote:
 On Fri, Nov 20, 2009 at 3:37 PM, Justin Johansson <no spam.com> wrote:
 Bill Baxter wrote:
 On Fri, Nov 20, 2009 at 3:10 PM, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:
 Nick Sabalausky wrote:
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:he6sqe$1dqu$1 digitalmars.com...
 Based on recent discussions on the NG a few features were
 deprecated/removed from D, such as typedef and C style struct
 initializers.

 IMO this cleanup and polish is important and all successful languag=







es
 do
 such cleanup for major releases (Python and Ruby come to mind). I'm
 glad to
 see that D follows in those footsteps instead of accumulating craft
 like C++
 does.


 As part of this trend of cleaning up D before the release of D2, wh=







at
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 s/reverse_foreach/foreach_reverse/ ;)

 1. Floating point literals without digits on *both* sides!!! "1.",
 ".1"
 --> Useless hindrance to future language expansion!

 2. Octal literals! I think it'd be great to have a new octal syntax,
 or
 even better, a general any-positive-inter-base syntax. But until tha=






t
 finally happens, I don't want "010 =3D=3D 8" preserved. And I don't =






think
 the
 ability to have an octal literal is important enough that lacking it
 for
 a
 while is a problem. And if porting-from-C really has to be an issue,
 then
 just make 0[0-9_]+ an error for a transitionary period (or forever -
 it'd at
 least be better than maintaining "010 =3D=3D 8").

 It would definitely be a problem if octal literals disappeared from t=





he
 language, even if only for a short while. They are pretty much the on=





ly
 sensible way to specify POSIX file permissions.

 =A0import core.sys.posix.sys.stat;
 =A0...
 =A0chmod("path/to/file", 0755);

 Well you can always do..

 chmod("path/to/file", octal(755));

 --bb

 octal(755)?

 What's the base-10 identity of that?

 decimal(493) or decimal(755)?

 base-16 etc.

 Fine. =A0Make it octal!"755" if you prefer.
 The point is just that you can write a function that will convert a
 number to octal for the rare cases when you need it.
 You don't absolutely need octal literals.

 --bb

 Thanks for clarifying your position;
 I can happily go along with that. :-)
 (Sorry if at all I sounded obtuse or curt).

You were right, though.  Defining octal(x) that way would be a bad idea.  :=
-)
octal(0x755)  --> what now?
base11(999) --> ok but how you gonna do base11(AAA)?
binary(10101010101010101) ...  overflows a uint argument.

--bb

Leandro Lucarella <llucax gmail.com> writes:

Bill Baxter, el 20 de noviembre a las 15:43 me escribiste:
 octal(755)?

 What's the base-10 identity of that?

 decimal(493) or decimal(755)?

 base-16 etc.

 
 Fine.  Make it octal!"755" if you prefer.
 The point is just that you can write a function that will convert a
 number to octal for the rare cases when you need it.
 You don't absolutely need octal literals.

Please, understand this: IS NOT RARE IF YOU DO POSIX SYSTEM PROGRAMMING.

If you remove octals because they can be implemented in the library,
remove hexa and binary literals as well. And please, stop using the
argument of octal literal being rare, they aren't when programming using
POSIX. You use the all over it when managing filesystem related stuff.

I do think octal literals should be 0oNNN (or 0cNNN, I prefer 0oNNN
because it's already used by Python, so I would be very error prone to me
when switching the language to remember which to use).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
He used to do surgery
On girls in the eighties
But gravity always wins

Don <nospam nospam.com> writes:

Leandro Lucarella wrote:
 Bill Baxter, el 20 de noviembre a las 15:43 me escribiste:
 octal(755)?

 What's the base-10 identity of that?

 decimal(493) or decimal(755)?

 base-16 etc.

 Fine.  Make it octal!"755" if you prefer.
 The point is just that you can write a function that will convert a
 number to octal for the rare cases when you need it.
 You don't absolutely need octal literals.

 
 Please, understand this: IS NOT RARE IF YOU DO POSIX SYSTEM PROGRAMMING.
 
 If you remove octals because they can be implemented in the library,
 remove hexa and binary literals as well. And please, stop using the
 argument of octal literal being rare, they aren't when programming using
 POSIX. You use the all over it when managing filesystem related stuff.

That's quite a false dichotomy! Octal literals are used for POSIX file 
systems calls, and pretty much nowhere else (These days, they're a 
PDP-11 relic, really, once hex was invented octal became obsolete). For 
example, I don't think arithmetic is ever done on octal values.
I don't believe octal!("317"); is so terrible -- it's still much shorter 
than the equivalent code on Windows! Especially considering that they 
should never appear in OS-independent code.

But it's a matter of little consequence. The problem really is that 
octal has this preferred status, 0123 looks far too normal for something 
which is so obscure.

 I do think octal literals should be 0oNNN (or 0cNNN, I prefer 0oNNN
 because it's already used by Python, so I would be very error prone to me
 when switching the language to remember which to use).

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

Don wrote:
 But it's a matter of little consequence. The problem really is that 
 octal has this preferred status, 0123 looks far too normal for something 
 which is so obscure.

That I agree with. It looks like a zero-padded decimal.

-Lars

Travis Boucher <boucher.travis gmail.com> writes:

Yigal Chripun wrote:
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct initializers.
 
 IMO this cleanup and polish is important and all successful languages do 
 such cleanup for major releases (Python and Ruby come to mind). I'm glad 
 to see that D follows in those footsteps instead of accumulating craft 
 like C++ does.
 
 
 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?
 
 I suggest reverse_foreach and c style function pointers
 
 please add your candidates for removal.
 
 

Make version() statements case insensitive, although I guess that would 
be addition and not removal.  Either that, or add the common cases for 
all reserved version keywords (or at least some consistency, linux and 
FreeBSD).

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

"Travis Boucher" <boucher.travis gmail.com> wrote in message 
news:he7apn$2cru$1 digitalmars.com...
 Yigal Chripun wrote:
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct 
 initializers.

 IMO this cleanup and polish is important and all successful languages do 
 such cleanup for major releases (Python and Ruby come to mind). I'm glad 
 to see that D follows in those footsteps instead of accumulating craft 
 like C++ does.


 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 Make version() statements case insensitive, although I guess that would be 
 addition and not removal.  Either that, or add the common cases for all 
 reserved version keywords (or at least some consistency, linux and 
 FreeBSD).

Yes! Capitalization consistency in the predefined versions! If it needs to 
be worded as a "removal", then "Remove version's capitalization 
inconsistencies" ;). The current state of that is absolutely ridiculous, and 
frankly, a real PITA ("Ok, I need to version for Blah OS...now what random 
capitalization did Walter chose to use for that one again...?"). I don't 
care about that change breaking existing code: For one thing, it's D2, it's 
not supposed to be stable yet, and secondly: Just say "with this release, 
grep all your code for "version" and update your capitalizations", or, 
better yet, depricate any use of the old names as errors, and just get the 
damn issue fixed already!

Travis Boucher <boucher.travis gmail.com> writes:

Nick Sabalausky wrote:
 "Travis Boucher" <boucher.travis gmail.com> wrote in message 
 news:he7apn$2cru$1 digitalmars.com...
 Yigal Chripun wrote:
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct 
 initializers.

 IMO this cleanup and polish is important and all successful languages do 
 such cleanup for major releases (Python and Ruby come to mind). I'm glad 
 to see that D follows in those footsteps instead of accumulating craft 
 like C++ does.


 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

 Make version() statements case insensitive, although I guess that would be 
 addition and not removal.  Either that, or add the common cases for all 
 reserved version keywords (or at least some consistency, linux and 
 FreeBSD).

 
 Yes! Capitalization consistency in the predefined versions! If it needs to 
 be worded as a "removal", then "Remove version's capitalization 
 inconsistencies" ;). The current state of that is absolutely ridiculous, and 
 frankly, a real PITA ("Ok, I need to version for Blah OS...now what random 
 capitalization did Walter chose to use for that one again...?"). I don't 
 care about that change breaking existing code: For one thing, it's D2, it's 
 not supposed to be stable yet, and secondly: Just say "with this release, 
 grep all your code for "version" and update your capitalizations", or, 
 better yet, depricate any use of the old names as errors, and just get the 
 damn issue fixed already!
 
 


In alot of places, I think he tried to use GCC's capitalization.  It is 
implementation defined, which makes sense since some implementation 
target different things.  However, I think the specs should say either 
'version statements are not case sensitive' or 'implementation-defined 
versions much all be in (lower|UPPER) case'.

Walter Bright <newshound1 digitalmars.com> writes:

Nick Sabalausky wrote:
 Yes! Capitalization consistency in the predefined versions! If it needs to 
 be worded as a "removal", then "Remove version's capitalization 
 inconsistencies" ;). The current state of that is absolutely ridiculous, and 
 frankly, a real PITA ("Ok, I need to version for Blah OS...now what random 
 capitalization did Walter chose to use for that one again...?"). I don't 
 care about that change breaking existing code: For one thing, it's D2, it's 
 not supposed to be stable yet, and secondly: Just say "with this release, 
 grep all your code for "version" and update your capitalizations", or, 
 better yet, depricate any use of the old names as errors, and just get the 
 damn issue fixed already!

The choices were not random. They coincided with the common usage of the 
underlying C compiler.

Leandro Lucarella <llucax gmail.com> writes:

Walter Bright, el 21 de noviembre a las 11:51 me escribiste:
 Nick Sabalausky wrote:
Yes! Capitalization consistency in the predefined versions! If it
needs to be worded as a "removal", then "Remove version's
capitalization inconsistencies" ;). The current state of that is
absolutely ridiculous, and frankly, a real PITA ("Ok, I need to
version for Blah OS...now what random capitalization did Walter
chose to use for that one again...?"). I don't care about that
change breaking existing code: For one thing, it's D2, it's not
supposed to be stable yet, and secondly: Just say "with this
release, grep all your code for "version" and update your
capitalizations", or, better yet, depricate any use of the old
names as errors, and just get the damn issue fixed already!

 
 The choices were not random. They coincided with the common usage of
 the underlying C compiler.

Right, like OSX.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
He used to do surgery
On girls in the eighties
But gravity always wins

Travis Boucher <boucher.travis gmail.com> writes:

Leandro Lucarella wrote:
 Walter Bright, el 21 de noviembre a las 11:51 me escribiste:
 Nick Sabalausky wrote:
 Yes! Capitalization consistency in the predefined versions! If it
 needs to be worded as a "removal", then "Remove version's
 capitalization inconsistencies" ;). The current state of that is
 absolutely ridiculous, and frankly, a real PITA ("Ok, I need to
 version for Blah OS...now what random capitalization did Walter
 chose to use for that one again...?"). I don't care about that
 change breaking existing code: For one thing, it's D2, it's not
 supposed to be stable yet, and secondly: Just say "with this
 release, grep all your code for "version" and update your
 capitalizations", or, better yet, depricate any use of the old
 names as errors, and just get the damn issue fixed already!

 The choices were not random. They coincided with the common usage of
 the underlying C compiler.

 
 Right, like OSX.
 

http://predef.sourceforge.net/preos.html Has a decent list of macros 
defined for different OSes (and even different compilers in some cases).

Be glad he didn't use the different underscores.  I still think 
consistency would be nice (either all caps or no caps).

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

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:he9gba$167d$2 digitalmars.com...
 Nick Sabalausky wrote:
 Yes! Capitalization consistency in the predefined versions! If it needs 
 to be worded as a "removal", then "Remove version's capitalization 
 inconsistencies" ;). The current state of that is absolutely ridiculous, 
 and frankly, a real PITA ("Ok, I need to version for Blah OS...now what 
 random capitalization did Walter chose to use for that one again...?"). I 
 don't care about that change breaking existing code: For one thing, it's 
 D2, it's not supposed to be stable yet, and secondly: Just say "with this 
 release, grep all your code for "version" and update your 
 capitalizations", or, better yet, depricate any use of the old names as 
 errors, and just get the damn issue fixed already!

 The choices were not random. They coincided with the common usage of the 
 underlying C compiler.

To the average D user they may as well be random.

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Nick Sabalausky wrote:
 
 To the average D user they may as well be random.
 
 

I'd at least like a function that returns random D users.  And not the
names of D users, but actual D users.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sat, 21 Nov 2009 14:51:02 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Nick Sabalausky wrote:
 Yes! Capitalization consistency in the predefined versions! If it needs  
 to be worded as a "removal", then "Remove version's capitalization  
 inconsistencies" ;). The current state of that is absolutely  
 ridiculous, and frankly, a real PITA ("Ok, I need to version for Blah  
 OS...now what random capitalization did Walter chose to use for that  
 one again...?"). I don't care about that change breaking existing code:  
 For one thing, it's D2, it's not supposed to be stable yet, and  
 secondly: Just say "with this release, grep all your code for "version"  
 and update your capitalizations", or, better yet, depricate any use of  
 the old names as errors, and just get the damn issue fixed already!

 The choices were not random. They coincided with the common usage of the  
 underlying C compiler.

Makes sense, I always have trouble re-capitalizing version statements when  
porting C code...

-Steve

klickverbot <klickverbot gmail.com> writes:

Nick Sabalausky wrote:
 Yes! Capitalization consistency in the predefined versions! 

/agree
Altough this is only a minor itch, I would really like to scratch it – 
following consistent capitalization rules would probably make it more 
intuitive to a much larger user group than coinciding with the usage by some 
C compiler…

Justin Johansson <no spam.com> writes:

Bill Baxter Wrote:

 On Fri, Nov 20, 2009 at 5:22 PM, Justin Johansson <no spam.com> wrote:
 Andrei Alexandrescu Wrote:

 Ellery Newcomer wrote:
 Nick Sabalausky wrote:
 2. Octal literals! I think it'd be great to have a new octal syntax, or even
 better, a general any-positive-inter-base syntax. But until that finally
 happens, I don't want "010 == 8" preserved. And I don't think the ability to
 have an octal literal is important enough that lacking it for a while is a
 problem. And if porting-from-C really has to be an issue, then just make
 0[0-9_]+ an error for a transitionary period (or forever - it'd at least be
 better than maintaining "010 == 8").

 3. Also the comma operator, but that's already been recently discussed.

 <bikeshed>

 hex literal prefix: 0x, not 0h
 =>
 octal literal prefix: 0c, not 0o

 </bikeshed>

 This I'm on board with. 0o is too much like a practical joke.

 Okay let's go for some consistency then.

 First try. Radix character comes from 3rd character of radix name.

 hexadecimal   0x
 octal             0t
 binary           0n

 Or, second try, how about first non-digit-looking character in radix name?

 hexadecimal   0h
 octal             0c
 binary           0b

 My point being ... if there were to be a change in lexical form, a simple rule
would be nice.  Of course the rule can be anything that can be coerced to a
rule.  Hope this doesn't sound like a false choice :-)

 
 No problem!
 
   charToUse = basename[ floor(log2(log2(base))) ];
 
 --bb

Sweet.  I'm curious though, have you ever programmed in BrainF? Ha :-)

Don <nospam nospam.com> writes:

Yigal Chripun wrote:
 Based on recent discussions on the NG a few features were 
 deprecated/removed from D, such as typedef and C style struct initializers.
 
 IMO this cleanup and polish is important and all successful languages do 
 such cleanup for major releases (Python and Ruby come to mind). I'm glad 
 to see that D follows in those footsteps instead of accumulating craft 
 like C++ does.
 
 
 As part of this trend of cleaning up D before the release of D2, what 
 other features/craft should be removed/deprecated?
 
 I suggest reverse_foreach and c style function pointers
 
 please add your candidates for removal.


So weak that they're pretty much useless:

version(integer), debug(integer)

And these should in the library, not the language:
array.sort
array.reverse

bearophile <bearophileHUGS lycos.com> writes:

Don:
 So weak that they're pretty much useless:
 version(integer), debug(integer)

I have used that for something unrelated that deserves (as in Fortress) a
better standard implementation (to give numeric integer/float constants during
compilation):
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=18169


 And these should in the library, not the language:
 array.sort
 array.reverse

I think keeping reverse is OK, because its purpose is simple.
sort can be moved in the std library (or improved a lot).

Bye,
bearophile

Don <nospam nospam.com> writes:

bearophile wrote:
 Don:
 So weak that they're pretty much useless:
 version(integer), debug(integer)

 
 I have used that for something unrelated that deserves (as in Fortress) a
better standard implementation (to give numeric integer/float constants during
compilation):
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=18169

There seems to be no point in having a *single* integer value, shared 
between the app and all libraries! It's just reducing future flexibility.

 
 
 And these should in the library, not the language:
 array.sort
 array.reverse

 
 I think keeping reverse is OK, because its purpose is simple.
 sort can be moved in the std library (or improved a lot).

But with the implicit array property functions, we can do it in a 
library anyway. The current implementations of both those functions have 
bugs.

bearophile <bearophileHUGS lycos.com> writes:

Don:
 There seems to be no point in having a *single* integer value, shared 
 between the app and all libraries! It's just reducing future flexibility.

It doesn't reduce flexibility at all, because if you need something more
complex you don't use it and nothing bad happens. You can even ignore it.
You are thinking about 10000+ lines long apps; about scaling up. I am thinking
about single-module 500-lines long programs that replace some scripts; about
scaling down too.
A compilation constant avoids me to modify the source every time I need to
change the size of some static array/matrix. With that I just need a second
Python script that calls dmd/ldc with a different argument, instead of a little
more complex Python script that changes the source code of the D program, to
modify the constant.
A very modern language like Fortress, designed for physics, has that small
feature :-) (It's available in C too, only integer/symbol constants).

Bye,
bearophile

dsimcha <dsimcha yahoo.com> writes:

== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Don:
 There seems to be no point in having a *single* integer value, shared
 between the app and all libraries! It's just reducing future flexibility.

 It doesn't reduce flexibility at all, because if you need something more
complex

you don't use it and nothing bad happens. You can even ignore it.
 You are thinking about 10000+ lines long apps; about scaling up. I am thinking

about single-module 500-lines long programs that replace some scripts; about
scaling down too.
 A compilation constant avoids me to modify the source every time I need to

change the size of some static array/matrix. With that I just need a second
Python
script that calls dmd/ldc with a different argument, instead of a little more
complex Python script that changes the source code of the D program, to modify
the
constant.
 A very modern language like Fortress, designed for physics, has that small

feature :-) (It's available in C too, only integer/symbol constants).
 Bye,
 bearophile

I just have to say it:  Vote++ for the scaling down thing.  I think D is about
the
only language on the planet that cares about both scaling up to huge million
line
applications and scaling down to small 500-line scripts.  This is surprisingly
important to me because the small 500-line scripts are often the kind of code
where I (and probably other people, too) are less afraid to experiment with
things
and therefore to really learn some of the details of the language and standard
lib.  I actually got my start with D by writing very small programs that needed
to
be fast, faster than dynamic scripting languages could handle well.  If D were
as
unnecessarily verbose as, say, Java, for writing small programs I would likely
have blown it off as unnecessarily complex before I even learned it in any
depth.

Furthermore, trying to scale down to the 500 line script level really forces us
to
think about making simple things simple, as opposed to the Java way of having to
use 5 different classes just to read in a file line by line in the default
character encoding.

Lastly, I see the scaling down thing as valuable because you can write really
complicated libraries in D, and then call them from really simple scripts with
no
horribly messy glue layer or unnecessary complexity getting in the way.  I do
this
quite often.  Even for some fairly simple math stuff, I actually find D +
Phobos +
my dstats lib as easy or easier to use than DSLs like R or Matlab.

bearophile <bearophileHUGS lycos.com> writes:

dsimcha:
 I think D is about the
 only language on the planet that cares about both scaling up to huge million
line
 applications and scaling down to small 500-line scripts.

"Scala" means "scalable language", it's supposed to be designed to be able to
scale both up and down :-)
Removing the array.sort and moving complex numbers to the std lib is a little
against the scaling down, but I think it's acceptable.

In the Python std lib there's a module that's essentially designed for the
"scaling down", the fileinput module:
http://docs.python.org/library/fileinput.html
Phobos can grow a simple module that helps the creation of script-like
programs, its contents have to be chosen from practice. Some of its features
are just imported from other modules.

Bye,
bearophile

retard <re tard.com.invalid> writes:

Mon, 23 Nov 2009 12:37:27 -0500, bearophile wrote:

 dsimcha:
 I think D is about the
 only language on the planet that cares about both scaling up to huge
 million line applications and scaling down to small 500-line scripts.

 
 "Scala" means "scalable language", it's supposed to be designed to be
 able to scale both up and down :-) Removing the array.sort and moving
 complex numbers to the std lib is a little against the scaling down, but
 I think it's acceptable.

Have you any idea what you are talking about? In Scala arrays are 
completely defined in the stdlib and there is nothing array related built 
in to the language per se. This is how they are used:

$ scala

scala> Array(1,2,3).reverse
res0: Array[Int] = Array(3, 2, 1)

array.sort is missing but that's not a problem in a scalable language - 
let's define it!

scala> class Sorter(val a: Array[Int]) {
  def sort = { util.Sorting.quickSort(a); a }
}

scala> implicit def toSorter(a: Array[Int]) = new Sorter(a)

scala> Array(3,2,1).sort
res1: Array[Int] = Array(1, 2, 3)


Note that this is a statically typed compiled language unlike Python. 
It's really hard to see how D scales any better when programming in the 
small. Something like opening files with one liners is a library issue. 
It takes 5 minutes to build a wrapper on top of Java like stream zoo. You 
can reuse the wrappers later.

IMHO if you're writing max 500 LOC applications, it doesn't really matter 
what language is used.

retard <re tard.com.invalid> writes:

Mon, 23 Nov 2009 17:14:54 +0000, dsimcha wrote:

[snip]
 as opposed to the
 Java way of having to use 5 different classes just to read in a file
 line by line in the default character encoding.

That's a library issue. Has nothing to do with the language.

dsimcha <dsimcha yahoo.com> writes:

== Quote from retard (re tard.com.invalid)'s article
 Mon, 23 Nov 2009 17:14:54 +0000, dsimcha wrote:
 [snip]
 as opposed to the
 Java way of having to use 5 different classes just to read in a file
 line by line in the default character encoding.

 That's a library issue. Has nothing to do with the language.

I agree completely, but for all practical purposes basic parts of the standard
library that are used by almost everyone are part of the language.  Heck, in
many
languages (D being one of them) you can't even write a canonical hello world
program w/o the standard lib.

=?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:

dsimcha wrote:
 == Quote from retard (re tard.com.invalid)'s article
 Mon, 23 Nov 2009 17:14:54 +0000, dsimcha wrote:
 [snip]
 as opposed to the
 Java way of having to use 5 different classes just to read in a file
 line by line in the default character encoding.

 That's a library issue. Has nothing to do with the language.

 
 I agree completely, but for all practical purposes basic parts of the standard
 library that are used by almost everyone are part of the language.  Heck, in
many
 languages (D being one of them) you can't even write a canonical hello world
 program w/o the standard lib.

Sure you can!

extern (C) int puts(char *);
void main() {
     puts("Hello world!\0".dup.ptr);
}

Pretty!

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Nov 23, 2009 at 12:04 PM, Pelle M=E5nsson <pelle.mansson gmail.com>=
 wrote:
 dsimcha wrote:
 =3D=3D Quote from retard (re tard.com.invalid)'s article
 Mon, 23 Nov 2009 17:14:54 +0000, dsimcha wrote:
 [snip]
 as opposed to the
 Java way of having to use 5 different classes just to read in a file
 line by line in the default character encoding.

 That's a library issue. Has nothing to do with the language.

 I agree completely, but for all practical purposes basic parts of the
 standard
 library that are used by almost everyone are part of the language. =A0He=


ck,
 in many
 languages (D being one of them) you can't even write a canonical hello
 world
 program w/o the standard lib.

 Sure you can!

 extern (C) int puts(char *);
 void main() {
 =A0 =A0puts("Hello world!\0".dup.ptr);
 }

I think he means that the GC from the standard lib will still be there
to perform that .dup for you.
(You don't need the dup though, btw, string literals are null
terminated and can be passed to C funcs as-is).

Even without that, the GC doesn't get eliminated from executables just
because you don't use it.
There's still some hidden calls to gc init routines that go into any D exe.

--bb

=?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:

Bill Baxter wrote:
 On Mon, Nov 23, 2009 at 12:04 PM, Pelle M�nsson <pelle.mansson gmail.com>
wrote:
 dsimcha wrote:
 == Quote from retard (re tard.com.invalid)'s article
 Mon, 23 Nov 2009 17:14:54 +0000, dsimcha wrote:
 [snip]
 as opposed to the
 Java way of having to use 5 different classes just to read in a file
 line by line in the default character encoding.

 That's a library issue. Has nothing to do with the language.

 I agree completely, but for all practical purposes basic parts of the
 standard
 library that are used by almost everyone are part of the language. �Heck,
 in many
 languages (D being one of them) you can't even write a canonical hello
 world
 program w/o the standard lib.

 Sure you can!

 extern (C) int puts(char *);
 void main() {
 � �puts("Hello world!\0".dup.ptr);
 }

 
 I think he means that the GC from the standard lib will still be there
 to perform that .dup for you.
 (You don't need the dup though, btw, string literals are null
 terminated and can be passed to C funcs as-is).
 
 Even without that, the GC doesn't get eliminated from executables just
 because you don't use it.
 There's still some hidden calls to gc init routines that go into any D exe.
 
 --bb

Fair enough. :) I do think I need the dup, though, since the literal is 
immutable otherwise.

I lean more towards that the standard libs are a core part of the 
language anyway, and the possibility of writing your own simplifications 
doesn't help the usefulness of the language.

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Nov 23, 2009 at 12:34 PM, Pelle M=C3=A5nsson <pelle.mansson gmail.c=
om> wrote:
 Bill Baxter wrote:
 On Mon, Nov 23, 2009 at 12:04 PM, Pelle M=EF=BF=BDnsson <pelle.mansson g=


mail.com>
 wrote:
 dsimcha wrote:
 =3D=3D Quote from retard (re tard.com.invalid)'s article
 Mon, 23 Nov 2009 17:14:54 +0000, dsimcha wrote:
 [snip]
 as opposed to the
 Java way of having to use 5 different classes just to read in a file
 line by line in the default character encoding.

 That's a library issue. Has nothing to do with the language.

 I agree completely, but for all practical purposes basic parts of the
 standard
 library that are used by almost everyone are part of the language.
 =EF=BF=BDHeck,
 in many
 languages (D being one of them) you can't even write a canonical hello
 world
 program w/o the standard lib.

 Sure you can!

 extern (C) int puts(char *);
 void main() {
 =EF=BF=BD =EF=BF=BDputs("Hello world!\0".dup.ptr);
 }

 I think he means that the GC from the standard lib will still be there
 to perform that .dup for you.
 (You don't need the dup though, btw, string literals are null
 terminated and can be passed to C funcs as-is).

 Even without that, the GC doesn't get eliminated from executables just
 because you don't use it.
 There's still some hidden calls to gc init routines that go into any D
 exe.

 --bb

 Fair enough. :) I do think I need the dup, though, since the literal is
 immutable otherwise.

Ah, well, puts is usually declared
        int puts(const char*);
In C libs.  Maybe it's not wise for D to believe such a declaration
though, since it can be easily circumvented.  But it does currently.

--bb

"Denis Koroskin" <2korden gmail.com> writes:

On Mon, 23 Nov 2009 23:04:54 +0300, Pelle M=C3=A5nsson  =

<pelle.mansson gmail.com> wrote:

 dsimcha wrote:
 =3D=3D Quote from retard (re tard.com.invalid)'s article
 Mon, 23 Nov 2009 17:14:54 +0000, dsimcha wrote:
 [snip]
 as opposed to the
 Java way of having to use 5 different classes just to read in a fil=




e
 line by line in the default character encoding.

 That's a library issue. Has nothing to do with the language.

  I agree completely, but for all practical purposes basic parts of th=


e  =

 standard
 library that are used by almost everyone are part of the language.   =


 Heck, in many
 languages (D being one of them) you can't even write a canonical hell=


o  =

 world
 program w/o the standard lib.

 Sure you can!

 extern (C) int puts(char *);
 void main() {
      puts("Hello world!\0".dup.ptr);
 }

 Pretty!

Even simpler:

extern (C) int printf(const(char)* str, ...);

void main() {
    printf("Hello, World!");
}

retard <re tard.com.invalid> writes:

Tue, 24 Nov 2009 00:21:41 +0300, Denis Koroskin wrote:

 On Mon, 23 Nov 2009 23:04:54 +0300, Pelle MÃ¥nsson
 <pelle.mansson gmail.com> wrote:
 
 dsimcha wrote:
 == Quote from retard (re tard.com.invalid)'s article
 Mon, 23 Nov 2009 17:14:54 +0000, dsimcha wrote: [snip]
 as opposed to the
 Java way of having to use 5 different classes just to read in a file
 line by line in the default character encoding.

 That's a library issue. Has nothing to do with the language.

  I agree completely, but for all practical purposes basic parts of the
 standard
 library that are used by almost everyone are part of the language.
 Heck, in many
 languages (D being one of them) you can't even write a canonical hello
 world
 program w/o the standard lib.

 Sure you can!

 extern (C) int puts(char *);
 void main() {
      puts("Hello world!\0".dup.ptr);
 }

 Pretty!

 
 Even simpler:
 
 extern (C) int printf(const(char)* str, ...);
 
 void main() {
     printf("Hello, World!");
 }

Or even bettar

void print(string str) {
  void _(int addr, int len) {
    asm {
      mov EAX,0x4;
      mov EBX,0x1;
      mov ECX, addr;
      mov EDX, len;
      int 0x80;
    }
  }
  _(cast(int)str.ptr, str.length);
}

void main() {
  print("hello world");
}

My asm skills are a bit rusty, though..

In this case dmd2 produces 441x larger executables than nasm :)

dsimcha <dsimcha yahoo.com> writes:

== Quote from retard (re tard.com.invalid)'s article
 Tue, 24 Nov 2009 00:21:41 +0300, Denis Koroskin wrote:
 On Mon, 23 Nov 2009 23:04:54 +0300, Pelle MÃ¥nsson
 <pelle.mansson gmail.com> wrote:

 dsimcha wrote:
 == Quote from retard (re tard.com.invalid)'s article
 Mon, 23 Nov 2009 17:14:54 +0000, dsimcha wrote: [snip]
 as opposed to the
 Java way of having to use 5 different classes just to read in a file
 line by line in the default character encoding.

 That's a library issue. Has nothing to do with the language.

  I agree completely, but for all practical purposes basic parts of the
 standard
 library that are used by almost everyone are part of the language.
 Heck, in many
 languages (D being one of them) you can't even write a canonical hello
 world
 program w/o the standard lib.

 Sure you can!

 extern (C) int puts(char *);
 void main() {
      puts("Hello world!\0".dup.ptr);
 }

 Pretty!

 Even simpler:

 extern (C) int printf(const(char)* str, ...);

 void main() {
     printf("Hello, World!");
 }

 Or even bettar
 void print(string str) {
   void _(int addr, int len) {
     asm {
       mov EAX,0x4;
       mov EBX,0x1;
       mov ECX, addr;
       mov EDX, len;
       int 0x80;
     }
   }
   _(cast(int)str.ptr, str.length);
 }
 void main() {
   print("hello world");
 }
 My asm skills are a bit rusty, though..
 In this case dmd2 produces 441x larger executables than nasm :)

Notice the word canonical in my orig. post.  By this I meant a "regular" Hello,
world program, not one that uses hacks specifically to avoid the standard
library.

Don <nospam nospam.com> writes:

bearophile wrote:
 Don:
 There seems to be no point in having a *single* integer value, shared 
 between the app and all libraries! It's just reducing future flexibility.

 
 It doesn't reduce flexibility at all, 

I meant future D flexibility.

because if you need something more complex you don't use it and nothing 
bad happens. You can even ignore it.
 You are thinking about 10000+ lines long apps; about scaling up.

No, I'm not, actually. I've actually never worked on a large project. 
I'm not a computer scientist.

  I am thinking about single-module 500-lines long programs that replace 
some scripts; about scaling down too.
 A compilation constant avoids me to modify the source every time I need to
change the size of some static array/matrix. With that I just need a second
Python script that calls dmd/ldc with a different argument, instead of a little
more complex Python script that changes the source code of the D program, to
modify the constant.

 A very modern language like Fortress, designed for physics, has that small
feature :-) (It's available in C too, only integer/symbol constants).

Yes, but it has MORE THAN ONE.
Some specifics -- it'd be nice to have a Windows version specified as an 
integer. It'd be nice to have a DirectX version number. Can't do it.

version(int) is like a programming language with one variable. It's 
ridiculous.

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Nov 23, 2009 at 11:13 AM, Don <nospam nospam.com> wrote:

 Some specifics -- it'd be nice to have a Windows version specified as an
 integer. It'd be nice to have a DirectX version number. Can't do it.

 version(int) is like a programming language with one variable. It's
 ridiculous.

One variable, and one operator, >=.

To be fair, it was clearly intended to refer to the version of the
final user's app, not a library version or platform version or
anything else.

But to assume that only apps have versions, and that >= is the only
test you'd ever want to perform is, I agree, pretty silly.

--bb

Walter Bright <newshound1 digitalmars.com> writes:

Bill Baxter wrote:
 version(int) is like a programming language with one variable. It's
 ridiculous.

 
 One variable, and one operator, >=.
 
 To be fair, it was clearly intended to refer to the version of the
 final user's app, not a library version or platform version or
 anything else.
 
 But to assume that only apps have versions, and that >= is the only
 test you'd ever want to perform is, I agree, pretty silly.

The way to use it would be:

version (2)
{
     version = HasFeatureX;
     version = HasFeatureY;
     version = HasFeatureZ;
}

...

version (HasFeatureY)
{
     ...
}

Don <nospam nospam.com> writes:

Walter Bright wrote:
 Bill Baxter wrote:
 version(int) is like a programming language with one variable. It's
 ridiculous.

 One variable, and one operator, >=.

 To be fair, it was clearly intended to refer to the version of the
 final user's app, not a library version or platform version or
 anything else.

 But to assume that only apps have versions, and that >= is the only
 test you'd ever want to perform is, I agree, pretty silly.

 
 The way to use it would be:
 
 version (2)
 {
     version = HasFeatureX;
     version = HasFeatureY;
     version = HasFeatureZ;
 }
 
 ...
 
 version (HasFeatureY)
 {
     ...
 }

You cannot use version(int) inside libraries. You can only use it for 
the app. But it's fairly common to have multiple library versions.

Don <nospam nospam.com> writes:

Don wrote:
 Walter Bright wrote:
 Bill Baxter wrote:
 version(int) is like a programming language with one variable. It's
 ridiculous.

 One variable, and one operator, >=.

 To be fair, it was clearly intended to refer to the version of the
 final user's app, not a library version or platform version or
 anything else.

 But to assume that only apps have versions, and that >= is the only
 test you'd ever want to perform is, I agree, pretty silly.

 The way to use it would be:

 version (2)
 {
     version = HasFeatureX;
     version = HasFeatureY;
     version = HasFeatureZ;
 }

 ...

 version (HasFeatureY)
 {
     ...
 }

 
 You cannot use version(int) inside libraries. You can only use it for 
 the app. But it's fairly common to have multiple library versions.

And the other stupid case is when an API changes in a later version.
Eg, suppose FeatureZ only exists from version 2 to 8.
You end up with:
version(2)
{
     version(9)
     {
     }
     else
     {
     version = HasFeatureZ;
     }
}
Which can get very convoluted.
For this reason, it's usually easier to use version=Version2 than version=2.

bearophile <bearophileHUGS lycos.com> writes:

Don:

 I meant future D flexibility.

I am not talking about version(n) here, I am talking about a standard way to
give a constant number to the compiler that can be used as a constant inside
the code. This feature doesn't reduce future D flexibility.


 I'm not a computer scientist.

You seem one of the best programmers I've seen in tens of years, I'd like to be
1/3 as good as you :-)


 Yes, but it has MORE THAN ONE.
 Some specifics -- it'd be nice to have a Windows version specified as an 
 integer. It'd be nice to have a DirectX version number. Can't do it.
 version(int) is like a programming language with one variable. It's 
 ridiculous.

I agree. I think we have misunderstood, I was not talking about version(int), I
am sorry for confusing the matter.

Bye,
bearophile

bearophile <bearophileHUGS lycos.com> writes:

 I am not talking about version(n) here, I am talking about a standard way to
give a constant number to the compiler that can be used as a constant inside
the code.

I meant one of more constant numbers, of course :-)

Bye,
bearophile

Yigal Chripun <yigal100 gmail.com> writes:

Don wrote:
 bearophile wrote:
 Don:
 There seems to be no point in having a *single* integer value, shared 
 between the app and all libraries! It's just reducing future 
 flexibility.

 It doesn't reduce flexibility at all, 

 
 I meant future D flexibility.
 
 because if you need something more complex you don't use it and nothing 
 bad happens. You can even ignore it.
 You are thinking about 10000+ lines long apps; about scaling up.

 
 No, I'm not, actually. I've actually never worked on a large project. 
 I'm not a computer scientist.
 

IMO, computer scientists are over-rated. The only great (as in very 
large) thing about them is their egos.

  I am thinking about single-module 500-lines long programs that replace 
 some scripts; about scaling down too.
 A compilation constant avoids me to modify the source every time I 
 need to change the size of some static array/matrix. With that I just 
 need a second Python script that calls dmd/ldc with a different 
 argument, instead of a little more complex Python script that changes 
 the source code of the D program, to modify the constant.

 
 A very modern language like Fortress, designed for physics, has that 
 small feature :-) (It's available in C too, only integer/symbol 
 constants).

 
 Yes, but it has MORE THAN ONE.
 Some specifics -- it'd be nice to have a Windows version specified as an 
 integer. It'd be nice to have a DirectX version number. Can't do it.
 
 version(int) is like a programming language with one variable. It's 
 ridiculous.

The feature berophile speaks of in C, and such (and even in Java with 
properties) is IMO yet another special case with special syntax in other 
languages. If/When D gets proper macros, this would be trivial to 
implement. basic idea - the macro reads a properties file and defines a 
constant with the value specified in that file.

This is another reason why I prefer the two-phase compilation approach 
instead of D's CTFE - CTFE is limited to a small subset of D which can 
be reduced to constant-folding whereas in a Nemerle-like system you have 
the full power of the language: I/O, network, syscalls, whatever. For 
instance this is used to verify SQL queries on the DB engine at 
compile-time.