www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - removal of cruft from D

reply 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.
Nov 20 2009
next sibling parent 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,];
Nov 20 2009
prev sibling next sibling parent reply "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.
Nov 20 2009
next sibling parent "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
Nov 20 2009
prev sibling next sibling parent reply 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
Nov 20 2009
next sibling parent 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.

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).
Nov 20 2009
prev sibling next sibling parent 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
Nov 20 2009
prev sibling parent 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.
Nov 20 2009
prev sibling next sibling parent 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.
Nov 20 2009
prev sibling next sibling parent reply 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
Nov 20 2009
parent reply "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...?
Nov 21 2009
parent reply 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!

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
Nov 21 2009
parent reply 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
Nov 21 2009
parent 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 &amp; 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.
Nov 21 2009
prev sibling next sibling parent reply 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>
Nov 20 2009
parent reply 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.

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
Nov 20 2009
next sibling parent 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.

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
Nov 20 2009
prev sibling parent reply 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.

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
Nov 20 2009
next sibling parent reply 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?
Nov 20 2009
next sibling parent 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!
Nov 21 2009
prev sibling parent reply =?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?

that is any radix from 2 to 36; for example 2r101010, 8r52, 36r16, and 42 are all the same Integer." http://clojure.org/reader
Nov 21 2009
parent 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?

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.
Nov 21 2009
prev sibling parent reply 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.

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?
Nov 21 2009
next sibling parent "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?
Nov 21 2009
prev sibling parent reply 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.
 

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.

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

Andrei

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


Base 13 is useful in literature.
Nov 24 2009
parent "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.
Nov 25 2009
prev sibling next sibling parent reply "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
Nov 20 2009
next sibling parent reply 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! :-)
Nov 20 2009
parent 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/
Nov 20 2009
prev sibling parent reply 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.

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

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
Nov 20 2009
next sibling parent 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.

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

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

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

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
Nov 20 2009
prev sibling parent reply 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.

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

Nov 20 2009
parent "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
Nov 21 2009
prev sibling next sibling parent 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=



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



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



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



 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=


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


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


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


 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
Nov 20 2009
prev sibling next sibling parent 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.

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=




 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=




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




 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
Nov 20 2009
prev sibling next sibling parent 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=







 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=







 other features/craft should be removed/deprecated?

 I suggest reverse_foreach and c style function pointers

 please add your candidates for removal.

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=






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






 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=





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





 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
Nov 20 2009
prev sibling next sibling parent 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.

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
Nov 20 2009
prev sibling next sibling parent 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, =




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

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



 logical that octal should be 0o10.

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



 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=


 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
Nov 20 2009
prev sibling next sibling parent 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, =




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




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




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




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




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




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

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




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

ced to a rule. =A0Hope this doesn't sound like a false choice :-) No problem! charToUse =3D basename[ floor(log2(log2(base))) ]; --bb
Nov 20 2009
prev sibling next sibling parent 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=


 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=






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

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





 logical that octal should be 0o10.

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





 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=




 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
Nov 20 2009
prev sibling parent 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=


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




 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=








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

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







 logical that octal should be 0o10.

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







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






 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=




 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
Nov 20 2009
prev sibling next sibling parent reply 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).
Nov 20 2009
next sibling parent reply "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!
Nov 21 2009
next sibling parent 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.

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'.
Nov 21 2009
prev sibling next sibling parent reply 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.
Nov 21 2009
next sibling parent reply "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.
Nov 21 2009
parent 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.
Nov 21 2009
prev sibling parent 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 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).
Nov 21 2009
prev sibling parent 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…
Nov 21 2009
prev sibling parent "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
Nov 23 2009
prev sibling next sibling parent 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
Nov 20 2009
prev sibling next sibling parent 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
Nov 20 2009
prev sibling next sibling parent 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
Nov 20 2009
prev sibling next sibling parent 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)
Nov 20 2009
prev sibling next sibling parent 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?
Nov 20 2009
prev sibling next sibling parent 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
Nov 21 2009
prev sibling next sibling parent 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
Nov 21 2009
prev sibling parent reply 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
Nov 23 2009
next sibling parent reply 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
Nov 23 2009
next sibling parent reply 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.
Nov 23 2009
parent reply 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
Nov 23 2009
next sibling parent reply 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.


 You are thinking about 10000+ lines long apps; about scaling up. I am thinking

scaling down too.
 A compilation constant avoids me to modify the source every time I need to

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

 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.
Nov 23 2009
next sibling parent 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
Nov 23 2009
prev sibling parent reply 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.


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.
Nov 23 2009
parent reply =?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.


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.

extern (C) int puts(char *); void main() { puts("Hello world!\0".dup.ptr); } Pretty!
Nov 23 2009
next sibling parent =?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.


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.

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

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.
Nov 23 2009
prev sibling parent 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.


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.

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!"); }

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.
Nov 23 2009
prev sibling parent reply 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.
Nov 23 2009
next sibling parent reply 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
Nov 23 2009
parent 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
Nov 23 2009
prev sibling next sibling parent reply 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) { ... }
Nov 25 2009
parent reply 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.
Nov 25 2009
parent 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.
Nov 25 2009
prev sibling parent 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.
Nov 25 2009
prev sibling parent 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=


 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
Nov 23 2009
prev sibling next sibling parent 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.
Nov 23 2009
prev sibling next sibling parent 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.
Nov 23 2009
prev sibling next sibling parent 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
Nov 23 2009
prev sibling next sibling parent 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=


 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
Nov 23 2009
prev sibling next sibling parent "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=




 line by line in the default character encoding.




 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=


 world
 program w/o the standard lib.

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!"); }
Nov 23 2009
prev sibling parent 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.


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.

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 :)
Nov 23 2009