www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Few mixed things

reply bearophile <bearophileHUGS lycos.com> writes:
Few things I have collected in the last days.

Can RAND_MAX be added to std.c.stdlib of D1 too?

-----------------------

What is the advantage of having a separate /+ +/ nestable comment syntax?
Can't the /+ +/ be removed to make the normal /* */ syntax nestable?
(IS the different C semantics of /* */ a problem here? I don't think so.)

-----------------------

Using obj2asm to the .obj produced by D2 (v2.029) produced huge (like 100-600
KB!) asm files even for 10-lines long programs (The same asm files where very
small for D1). There's a very large amount of asm code inside there.

-----------------------

From the Python newsgroup:


Linden Lab, makers of Second LIfe virtual world, found it was good to create a
C++ class similar to a Python dictionary in order to leverage some of the
faster prototyping advantages of that Python type when converting to C++.<



LLSD is a proposed IETF standard so there's no licensing issues involved in
using the technique, and I believe there are implementations in C++ (GPL) and




Linden Lab Structured Data (LLSD) is an abstract type system intended to
provide a language-neutral facility for the representation of structured data. 
It provides a type system, a serialization system and an interface description
language.<


http://wiki.secondlife.com/wiki/LLSD
http://tools.ietf.org/id/draft-hamrick-llsd-00.txt

-----------------------

The std.intrinsic module may gain a standard way to perform a 64-bit by 32-bit
division, for the situations where you know the quotient will fit in 32 bits
('divl' instruction on X86).
CPUs that don't support such operation can use the normal 64-big division.

-----------------------

I don't like the way Ruby denotes intervals open/closed on the right.

The following is how you do it in the Groovy language (but I don't like it,
because I like intervals by default open on the right):

Loop on closed on the right range:
for (i in 0..n)

Loop on open on the right range:
for (i in 0..<n)


Two possible syntaxes for D, to represent intervals closed on the right, using



for (i; 0 ..> n)


But probably adding a +1 at the end is good enough too for D. Better keep
things simpler.

Later,
bearophile
Apr 21 2009
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to bearophile,


 Few things I have collected in the last days.
 
 What is the advantage of having a separate /+ +/ nestable comment
 syntax?
 Can't the /+ +/ be removed to make the normal /* */ syntax nestable?
 (IS the different C semantics of /* */ a problem here? I don't think
 so.)


you spotted the issue, code porting and principle of least surprise
Apr 21 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:

 you spotted the issue, code porting and principle of least surprise<


- Code porting: If you port C code to D, it uses /* */ in a non nested way, so
making /* */ nestable in D doesn't cause problems. The new semantic is backward
compatible.
- The principle of least surprise: a C programmer doesn't nest them. So if used
correctly there's no surprise. If he/she/shi tries to nest them (creating a bug
if it's C code) finds their increased semantic meaning. I don't think this can
lead to bugs. The new nesting semantic is natural, and quick to learn once you
read about it, see it, or try it once. My editor colorizes the code correctly
according to the nestable /+ +/ too.
- Complexity: every syntactic bit removed from the D language is a gain. Less
things to learn, to read about, to remember, etc.

So I'm for the removal of /+ +/ and making /* */ nestable.

Bye,
bearophile
Apr 21 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 BCS:

 you spotted the issue, code porting and principle of least surprise<


 
 - Code porting: If you port C code to D, it uses /* */ in a non nested way


No. This is valid C:

/* comment /* more comment */


 - The principle of least surprise: a C programmer doesn't nest them.


Nesting occurs often when various portions of code are commented.


 - Complexity: every syntactic bit removed from the D language is a gain.


I guess I agree with this.


 So I'm for the removal of /+ +/ and making /* */ nestable.


This can't work.


Andrei
Apr 21 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gsku34$29tn$1 digitalmars.com...

 bearophile wrote:

 BCS:

 you spotted the issue, code porting and principle of least surprise<


 - Code porting: If you port C code to D, it uses /* */ in a non nested 
 way


 No. This is valid C:

 /* comment /* more comment */


That seems like a rather trivial thing to be designing our language around. 
And regarding principle of least surprise, the current /**/ behavior is only 
least-surprise for people who are already familiar with that particular 
detail of /**/. From a fresher perspective, the /++/ behavior is vastly less 
surprising.

I can understand the desire not to cause too much trouble for porting, but 
sometimes I think D places far too much emphasis on that.
Apr 21 2009
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Nick,


 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gsku34$29tn$1 digitalmars.com...
 

 bearophile wrote:
 

 BCS:
 

 you spotted the issue, code porting and principle of least
 surprise<
 


 - Code porting: If you port C code to D, it uses /* */ in a non
 nested way
 


 No. This is valid C:
 
 /* comment /* more comment */
 


 That seems like a rather trivial thing to be designing our language
 around. And regarding principle of least surprise, the current /**/
 behavior is only least-surprise for people who are already familiar
 with that particular detail of /**/. From a fresher perspective, the
 /++/ behavior is vastly less surprising.
 
 I can understand the desire not to cause too much trouble for porting,
 but sometimes I think D places far too much emphasis on that.
 


I'd be fine depricating /**/.
Apr 21 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 21 Apr 2009 23:42:20 +0400, BCS <ao pathlink.com> wrote:


 Reply to Nick,


 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gsku34$29tn$1 digitalmars.com...


 bearophile wrote:


 BCS:


 you spotted the issue, code porting and principle of least
 surprise<


 - Code porting: If you port C code to D, it uses /* */ in a non
 nested way


 No. This is valid C:
  /* comment /* more comment */


 That seems like a rather trivial thing to be designing our language
 around. And regarding principle of least surprise, the current /**/
 behavior is only least-surprise for people who are already familiar
 with that particular detail of /**/. From a fresher perspective, the
 /++/ behavior is vastly less surprising.
  I can understand the desire not to cause too much trouble for porting,
 but sometimes I think D places far too much emphasis on that.


 I'd be fine depricating /**/.


You mean, deprecating /++/?

Personally, I rarely use /++/ because it feels uncommon and unstandard. I will
be glad if /**/ become nestable and /++/ go away.
Apr 21 2009
parent reply BCS <ao pathlink.com> writes:
Reply to Denis,


 I'd be fine depricating /**/.
 


 You mean, deprecating /++/?
 


No, I mean exactly what I said. 

/**/ has well defined semantics, changing it will cause problems that replacing 
it will not.
Apr 21 2009
next sibling parent BCS <ao pathlink.com> writes:
Reply to Benjamin,


 Reply to Denis,
 

 I'd be fine depricating /**/.
 


 You mean, deprecating /++/?
 


 No, I mean exactly what I said.
 
 /**/ has well defined semantics, changing it will cause problems that
 replacing it will not.
 


I'd also be fine with doing nothing. What I'd not be fine with is making 
/**/ nest.
Apr 21 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <ao pathlink.com> wrote in message 
news:78ccfa2d3e7918cb909fe7a39778 news.digitalmars.com...

 Reply to Denis,


 I'd be fine depricating /**/.


 You mean, deprecating /++/?


 No, I mean exactly what I said.
 /**/ has well defined semantics, changing it will cause problems that 
 replacing it will not.


Are there any problems you see with it other than porting code to D? (FWIW, 
I've never come across any code that had a /* in between a /* and */.)
Apr 21 2009
parent reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Nick Sabalausky Wrote:


 "BCS" <ao pathlink.com> wrote in message 
 news:78ccfa2d3e7918cb909fe7a39778 news.digitalmars.com...

 Reply to Denis,


 I'd be fine depricating /**/.


 You mean, deprecating /++/?


 No, I mean exactly what I said.
 /**/ has well defined semantics, changing it will cause problems that 
 replacing it will not.


 
 Are there any problems you see with it other than porting code to D? (FWIW, 
 I've never come across any code that had a /* in between a /* and */.) 
 
 


I've seen lots of code that did that.

Now, if you mean code that intentionally did that...


Paul
Apr 21 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Apr 21, 2009 at 2:24 PM, Paul D. Anderson
<paul.d.removethis.anderson comcast.andthis.net> wrote:

 Nick Sabalausky Wrote:


 "BCS" <ao pathlink.com> wrote in message
 news:78ccfa2d3e7918cb909fe7a39778 news.digitalmars.com...

 Reply to Denis,


 I'd be fine depricating /**/.


 You mean, deprecating /++/?


 No, I mean exactly what I said.
 /**/ has well defined semantics, changing it will cause problems that
 replacing it will not.


 Are there any problems you see with it other than porting code to D? (FWIW,
 I've never come across any code that had a /* in between a /* and */.)


 I've seen lots of code that did that.

 Now, if you mean code that intentionally did that...


I could see (and maybe have seen?) people using it in comments:

/******/
/*  big
/*  long
/*  comment
/*  box
/*******/

--bb
Apr 21 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.1179.1240349493.22690.digitalmars-d puremagic.com...

 On Tue, Apr 21, 2009 at 2:24 PM, Paul D. Anderson
 <paul.d.removethis.anderson comcast.andthis.net> wrote:

 Nick Sabalausky Wrote:


 "BCS" <ao pathlink.com> wrote in message
 news:78ccfa2d3e7918cb909fe7a39778 news.digitalmars.com...

 Reply to Denis,


 I'd be fine depricating /**/.


 You mean, deprecating /++/?


 No, I mean exactly what I said.
 /**/ has well defined semantics, changing it will cause problems that
 replacing it will not.


 Are there any problems you see with it other than porting code to D? 
 (FWIW,
 I've never come across any code that had a /* in between a /* and */.)


 I've seen lots of code that did that.

 Now, if you mean code that intentionally did that...


 I could see (and maybe have seen?) people using it in comments:

 /******/
 /*  big
 /*  long
 /*  comment
 /*  box
 /*******/

 --bb


Yea, but something like that would be trivial to notice and fix.

And come to think of it, even if it was commented-code instead of a doc 
block:

regular code
/*
commented code
/*
more commented code
*/
regular code that becomes accidentially commented

That would still be easily detectable because, assuming the original code 
was compiling in the original language (which would almost certainly be the 
case if you're actually bothering to port it), then there wouldn't be enough 
matching '*/'s and the rest of the file would be commented out. And that's 
something that I really can't imagine would ever cause a 
successfully-compiling logic error. What you'd get, if not a "block comment 
never closed" error, would be an error from a {}, (), or [] never being 
closed, or a symbol not defined error. If none of those errors occurr, then 
whatever had been accidentially-commented would have already been dead code 
to begin with.
Apr 21 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Apr 21, 2009 at 3:50 PM, Nick Sabalausky <a a.a> wrote:

 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.1179.1240349493.22690.digitalmars-d puremagic.com...

 On Tue, Apr 21, 2009 at 2:24 PM, Paul D. Anderson
 <paul.d.removethis.anderson comcast.andthis.net> wrote:

 Nick Sabalausky Wrote:


 "BCS" <ao pathlink.com> wrote in message
 news:78ccfa2d3e7918cb909fe7a39778 news.digitalmars.com...

 Reply to Denis,


 I'd be fine depricating /**/.


 You mean, deprecating /++/?


 No, I mean exactly what I said.
 /**/ has well defined semantics, changing it will cause problems tha=










t

 replacing it will not.


 Are there any problems you see with it other than porting code to D?
 (FWIW,
 I've never come across any code that had a /* in between a /* and */.)


 I've seen lots of code that did that.

 Now, if you mean code that intentionally did that...


 I could see (and maybe have seen?) people using it in comments:

 /******/
 /* =A0big
 /* =A0long
 /* =A0comment
 /* =A0box
 /*******/

 --bb


 Yea, but something like that would be trivial to notice and fix.

 And come to think of it, even if it was commented-code instead of a doc
 block:

 regular code
 /*
 commented code
 /*
 more commented code
 */
 regular code that becomes accidentially commented

 That would still be easily detectable because, assuming the original code
 was compiling in the original language (which would almost certainly be t=


he

 case if you're actually bothering to port it), then there wouldn't be eno=


ugh

 matching '*/'s and the rest of the file would be commented out. And that'=


s

 something that I really can't imagine would ever cause a
 successfully-compiling logic error. What you'd get, if not a "block comme=


nt

 never closed" error, would be an error from a {}, (), or [] never being
 closed, or a symbol not defined error. If none of those errors occurr, th=


en

 whatever had been accidentially-commented would have already been dead co=


de

 to begin with.


I agree that if Walter had chosen to just make /* */ nestable
originally it would have been a fine choice.
But now that D has had /+ +/ for ten years or so, I don't see much
point in changing it.  It will only break everyone's code for what is
a miniscule benefit at best, and a miniscule detriment at worst,
depending on who you ask.

--bb
Apr 21 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 21 Apr 2009 16:18:34 -0700, Bill Baxter wrote:



 I agree that if Walter had chosen to just make /* */ nestable
 originally it would have been a fine choice.
 But now that D has had /+ +/ for ten years or so, I don't see much
 point in changing it.  It will only break everyone's code for what is
 a miniscule benefit at best, and a miniscule detriment at worst,
 depending on who you ask.


Yes, this is the legacy we now must keep.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Apr 21 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Derek Parnell:

 Yes, this is the legacy we now must keep.


I am willing to modify the D2 code written by everyone before April 22 2009 to
remove the /+ +/ and replace it with the /* */, once the latter are nestable
:-) (Mostly it's Phobos2, I presume).

Bye,
bearophile
Apr 22 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 21 Apr 2009 20:55:03 +0000 (UTC), BCS wrote:


 /**/ has well defined semantics,


 ... in the C programming language ...


 changing it will cause problems that replacing it will not.


The "well defined semantics" are not god-given axioms, or to rephrase it,
because something is 'thus' in C does not mean that it must also be 'thus'
in any other programming language.

For something to be in a programming language, it needs to be justified on
its own terms rather than only using precedent as its rationale to exist.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Apr 21 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:hn975kl8v6wa.bjme1g5z2jj3$.dlg 40tude.net...

 On Tue, 21 Apr 2009 20:55:03 +0000 (UTC), BCS wrote:


 /**/ has well defined semantics,


 ... in the C programming language ...


 changing it will cause problems that replacing it will not.


 The "well defined semantics" are not god-given axioms, or to rephrase it,
 because something is 'thus' in C does not mean that it must also be 'thus'
 in any other programming language.

 For something to be in a programming language, it needs to be justified on
 its own terms rather than only using precedent as its rationale to exist.


I agree with you on this, however I think what they meant was that (unless 
I'm mistaken) /**/ also behaves the same way in every other language that 
actually uses /**/ for comments.
Apr 21 2009
next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 21 Apr 2009 18:52:48 -0400, Nick Sabalausky wrote:


 I think what they meant was that (unless 
 I'm mistaken) /**/ also behaves the same way in every other language that 
 actually uses /**/ for comments.


However, I regularly use the Progress language in which /* */ are nestable.
I know that it is a rather obscure language but it does indicate that /* */
can be nested successfully.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Apr 21 2009
prev sibling parent BCS <none anon.com> writes:
Hello Nick,


 "Derek Parnell" <derek psych.ward> wrote in message
 news:hn975kl8v6wa.bjme1g5z2jj3$.dlg 40tude.net...
 

 On Tue, 21 Apr 2009 20:55:03 +0000 (UTC), BCS wrote:
 

 /**/ has well defined semantics,
 


 ... in the C programming language ...
 




Yes, exactly my point.


 changing it will cause problems that replacing it will not.
 


 The "well defined semantics" are not god-given axioms, or to rephrase
 it, because something is 'thus' in C does not mean that it must also
 be 'thus' in any other programming language.
 
 For something to be in a programming language, it needs to be
 justified on its own terms rather than only using precedent as its
 rationale to exist.
 




Precedent is a good reason to exist in /some given form/ if it is to exist 
at all.


 I agree with you on this, however I think what they meant was that
 (unless I'm mistaken) /**/ also behaves the same way in every other
 language that actually uses /**/ for comments.
 


So, ditto Nick on that one.
Apr 22 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 21 Apr 2009 13:45:44 -0400, Nick Sabalausky wrote:


 I can understand the desire not to cause too much trouble for porting, but 
 sometimes I think D places far too much emphasis on that.


"sometimes" !?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Apr 21 2009
parent "Nick Sabalausky" <a a.a> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1w5qr20r0ro12.n5x2lan1yen4.dlg 40tude.net...

 On Tue, 21 Apr 2009 13:45:44 -0400, Nick Sabalausky wrote:


 I can understand the desire not to cause too much trouble for porting, 
 but
 sometimes I think D places far too much emphasis on that.


 "sometimes" !?


Well, I'm not always thinking about D! Sometimes I'm thinking about Stargate 
;)
Apr 21 2009
prev sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
bearophile wrote:

 What is the advantage of having a separate /+ +/ nestable comment syntax?
 Can't the /+ +/ be removed to make the normal /* */ syntax nestable?
 (IS the different C semantics of /* */ a problem here? I don't think so.)


Sometimes it's handy to have non-nesting comments.

For example, when debugging something, I sometimes use:
---
foo();
/*
bar();
/*
baz();
//*/
---
So I can quickly remove the first '/*' (by prepending '/') to uncomment bar() 
but not baz().

Also, Walter may feel differently about the C-compatibility thing than you do
:).


 The std.intrinsic module may gain a standard way to perform a 64-bit by 32-bit
division, for the situations where you know the quotient will fit in 32 bits
('divl' instruction on X86).
 CPUs that don't support such operation can use the normal 64-big division.


That just sounds like a possible compiler optimization for
---
ulong L;
uint I;
// initialize L & I
auto result = cast(uint)(L / I);
---
Apr 22 2009