www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D is awesome, my situation, questions

reply mike.benfield gmail.com writes:
I just read the D reference manual and downloaded the GCD D implementation and
I've been playing 
with it for a couple hours. D is great. Very very cool. 

(If anyone doesn't want to read my little anecdote, skip down a little.)

I learned about D's existence about a year or a year and a half ago. I pretty
much dismissed it - more 
C++-like stuff was not what I was after. I'm mostly into functional programming
- ML, Scheme, etc 
(although don't get me wrong, I've certainly done plenty of coding in C and
C++). Fast forward a bit, 
and I was getting frustrated with those languages (well, not so much the
languages themselves, but 
rather the supporting environment for writing portable application code in those
languages) for various 
reasons - most notably the pain it was to interact with C. I kept thinking "If
only there was a language 
like C++, but as a clean design instead of as kludge upon kludge - and with
GARBAGE COLLECTION." 
And I was thinking "And if only it had built in support for Design by Contract
and unit testing." I kid you 
not. And then I vaguely remembered D, and went to check it out.

Anyway, I've played with D for a couple hours, and it's awesome, but inevitably
there are features I miss 
from the FP world (ahem, variant types, pattern matching, real closures...). I
wrote some tuple templates 
- any chance tuples could go in the standard library? (hey, even C++ is getting
tuples now).

Can someone explain to me the difference between delegates and functions?

Any chance of D getting an incremental garbage collector? 

Are there any contingency plans for D if Walter gets abducted by Martians or
decides to abandon 
language design and compiler implementation and take up knitting instead? I'm a
little scared of the 
prospect of using tools that depend almost entirely on a single wizard.
Jun 03 2006
next sibling parent BCS <BCS_member pathlink.com> writes:
In article <e5tact$2htp$1 digitaldaemon.com>, mike.benfield gmail.com says...

Anyway, I've played with D for a couple hours, and it's awesome, 



Welcome. Glad you like it.



Can someone explain to me the difference between delegates and functions?


The difference is most notable with delegates and function _pointers_. The
difference is that a function pointer is just like in C but a delegate caries a
bit more context with it. 

In the simple case a delegate is formed from an object and method. Then without
the object reference, some other code can call the given method with the given
object. 

In the more complex case, the context that is carried along is something else,
often another function's local variables. In this case, rather than put an
object pointer in the delegate, the other functions stack pointer is used.

In any case, the code that uses the delegate doesn't need to know what the
context is and as a result the varius types are interchangeable.



Any chance of D getting an incremental garbage collector? 


That is one of a lot of peoples pet peeves. So, sooner or later, but don't hold
your breath


Are there any contingency plans for D if Walter gets abducted by Martians or
decides to abandon language design and compiler implementation and take up 
knitting instead? I'm a little scared of the prospect of using tools that 
depend almost entirely on a single wizard.


Ah... Not that I known of. Anyone have a spare UFO D-fence system laying around?

In the more complex case, the context that is carried along is something else,
often another function's local variables. In this case, rather than put an
object pointer in the delegate, the other functions stack pointer is used.

In any case, the code that uses the delegate doesn't need to know what the
context is and as a result the varius types are interchangeable.


That is one of a lot of peoples pet peeves. So, sooner or later, but don't hold
your breath


Ah... Not that I known of. Anyone have a spare UFO D-fence system laying around?

But seriously, there are several projects (GDC  et.al.), not run by Walter, that
have working D compilers that could be maintained without him.
Jun 03 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
<mike.benfield gmail.com> wrote in message 
news:e5tact$2htp$1 digitaldaemon.com...


 variant types, pattern matching, real closures...


Hehe, pattern matching.  Funny you mention that, as there was a brief (read: 
2-week) period when D had built-in regexp operators (~~ for match and !~ for 
not match), but it was determined that something like that doesn't belong in 
the core language, and was also too dependent upon the implementation of the 
standard library.  You can still do regular expressions, though, using 
std.regexp.  And there's also a template (!) version of regexps floating 
around somewhere.

And funny that you mention real (static) closures as well - check out the 
"Suggestion "new delegate"" thread, for Walter's view on the issue (kind of 
unfortunate, but I know where's he's coming from on the issue).

And lastly, variant types - I suppose if you're still thinking in 
"dynamically typed" terms, you'd miss them, but I've never needed anything 
like them; when thinking in object-oriented terms, anyway, polymorphism is 
usually more than enough, and when you need something that can accept 
multiple types, there's templates.  You might also want to look into 
std.boxer - the Box type is basically a typesafe variant.
Jun 03 2006
parent reply mike.benfield gmail.com writes:
In article <e5te5l$2l63$1 digitaldaemon.com>, Jarrett Billingsley says...



Hehe, pattern matching.  Funny you mention that, as there was a brief (read: 
2-week) period when D had built-in regexp operators 


Actually I was thinking about ML-style pattern matching on constructors
rather than regexps (regexps are cool too but yeah, it makes sense for
them to be in a library).


And lastly, variant types - I suppose if you're still thinking in 
"dynamically typed" terms, you'd miss them, but I've never needed anything 
like them; when thinking in object-oriented terms, anyway, polymorphism is 
usually more than enough, and when you need something that can accept 
multiple types, there's templates.  You might also want to look into 
std.boxer - the Box type is basically a typesafe variant. 


I think we may mean different things by variant types also. The variant types
I'm talking about are a feature of statically typed languages like ML, Haskell,
and Scala. They're somewhat like unions but are type safe and very convenient
to use (in conjunction with pattern matching). Flying Frog Consultancy has a
comparison of a ray tracer implementation in OCaml vs. C++:

http://www.ffconsultancy.com/free/ray_tracer/comparison.html

See how much more verbose the C++ is, partially because of the necessity
to use the C++ object oriented features to express what variant types
express more concisely.

(They also have the same comparison, but with Standard ML vs. C++:

http://www.ffconsultancy.com/free/ray_tracer/comparison_cpp_vs_sml.html

SML trounces the C++ program in performance too, but that's not really
fair since they compiled with it with mlton, a whole program optimizing
compiler.)

Scala does a good job of implementing variant types and pattern matching
in a language that looks more like C++ than ML.



 Jun 03 2006



 next sibling parent  "Jarrett Billingsley" <kb3ctd2 yahoo.com>  writes:


<mike.benfield gmail.com> wrote in message 
news:e5tsjs$70p$1 digitaldaemon.com...


 I think we may mean different things by variant types also. The variant 
 types
 I'm talking about are a feature of statically typed languages like ML, 
 Haskell,
 and Scala. They're somewhat like unions but are type safe and very 
 convenient
 to use (in conjunction with pattern matching). Flying Frog Consultancy has 
 a
 comparison of a ray tracer implementation in OCaml vs. C++:

 http://www.ffconsultancy.com/free/ray_tracer/comparison.html

 See how much more verbose the C++ is, partially because of the necessity
 to use the C++ object oriented features to express what variant types
 express more concisely.


Hmm.  Well, coming from a purely procedural background, I can say right away 
that the OCaml is certainly more _cryptic_ than the equivalent, more 
verbose, C++ (I especially don't get the 'in' at the end of every other 
line).  But reading the step-by-step comparison underneath helped somewhat.

I think the core of the issue was in the "type scene" line, and in the 
"intersect" function.  The writers tout the ability of OCaml to define a 
type which can be one of several types, and then use a function which 
automatically chooses the correct implementation based on the type of the 
variant.  I really don't see how this is at all elegant - I don't know what 
kinds of capabilities OCaml has for dynamic dispatch (I know it's 'O' for 
'object' but I don't know how it implements that), but what if you had 
twenty types that "derived" from scene?  The "type scene" would then become 
humongous, as well as the implementation of the "intersect" function.  That, 
to me, looks more like tagged unions, which are a poor approximation of OO 
at best.

As I stated in another post, I'm also keen on using up a little more space 
in the name of clarity.  While the C++ is more verbose, it's (in general) 
more readable.  I mean, I saw _this_:

let level = match Sys.argv with [| _; l |] -> int_of_string l | _ -> 6 in

I don't know what to do with that.  It probably translates into several 
lines of C++ code, but at least I'd (and other, newer programmers as well) 
be able to read it and know what it does very quickly.  But this, I think, 
is just more of a consequence of the differences between functional and 
procedural languages. 



 Jun 04 2006



prev sibling  parent  Dave <Dave_member pathlink.com>  writes:


mike.benfield gmail.com wrote:

 
 (They also have the same comparison, but with Standard ML vs. C++:
 
 http://www.ffconsultancy.com/free/ray_tracer/comparison_cpp_vs_sml.html
 
 SML trounces the C++ program in performance too, but that's not really
 fair since they compiled with it with mlton, a whole program optimizing
 compiler.)


Using an easy and common C++ optimization (passing return value byref 
for the highly recursive intersect methods):

MLTON version:
user    0m10.037s

Old CPP version:
user 0m14.665s

New CPP version:
user 0m6.960s


compiler flags.



 Jun 05 2006



prev sibling next sibling parent  Dave <Dave_member pathlink.com>  writes:


mike.benfield gmail.com wrote:

 I just read the D reference manual and downloaded the GCD D implementation and
 I've been playing 
 with it for a couple hours. D is great. Very very cool. 
 
 (If anyone doesn't want to read my little anecdote, skip down a little.)
 
 I learned about D's existence about a year or a year and a half ago. I pretty
 much dismissed it - more 
 C++-like stuff was not what I was after. I'm mostly into functional programming
 - ML, Scheme, etc 
 (although don't get me wrong, I've certainly done plenty of coding in C and
 C++). Fast forward a bit, 
 and I was getting frustrated with those languages (well, not so much the
 languages themselves, but 
 rather the supporting environment for writing portable application code in
those
 languages) for various 
 reasons - most notably the pain it was to interact with C. I kept thinking "If
 only there was a language 
 like C++, but as a clean design instead of as kludge upon kludge - and with
 GARBAGE COLLECTION." 
 And I was thinking "And if only it had built in support for Design by Contract
 and unit testing." I kid you 
 not. And then I vaguely remembered D, and went to check it out.
 
 Anyway, I've played with D for a couple hours, and it's awesome, but inevitably
 there are features I miss 
 from the FP world (ahem, variant types, pattern matching, real closures...). I
 wrote some tuple templates 
 - any chance tuples could go in the standard library? (hey, even C++ is getting
 tuples now).
 
 Can someone explain to me the difference between delegates and functions?
 


http://digitalmars.com/d/function.html

Look about 3/4 of the way down the page.


 Any chance of D getting an incremental garbage collector? 
 


There's been some talk of at least a compacting collector of some sort 
that would probably be quite a bit faster for most things.



 Jun 03 2006



prev sibling  parent reply Johan Granberg <lijat.meREM OVEgmail.com>  writes:


mike.benfield gmail.com wrote:

 from the FP world (ahem, variant types, pattern matching, real closures...). I
 wrote some tuple templates 
 - any chance tuples could go in the standard library? (hey, even C++ is getting
 tuples now).


I to would like tuples (and the other things to) but I realy thing 
tuples should bee an Built in type.

Syntax proposal: tuple(type,type,type)

I don't know if that is ambigous but I realy think that wee should have 
tuple in D.

ps. deprecate the , (comma) operator wee would all bee better of for that



 Jun 04 2006



  parent reply mike.benfield gmail.com  writes:


In article <e5u46f$hbe$1 digitaldaemon.com>, Johan Granberg says...

I to would like tuples (and the other things to) but I realy thing 
tuples should bee an Built in type.

Syntax proposal: tuple(type,type,type)


Why would you prefer tuples to be built in? 

I wrote struct templates like this:

struct Tuple(T1, T2) {
T1 _1;
T2 _2;
};

and function templates like this:

template tuple(T1, T2) {
Tuple!(T1, T2) tuple(T1 t1, T2 t2) {
Tuple!(T1, T2) tu;
tu._1 = t1;
tu._2 = t2;
return tu;
}
}

I made templates like this for between 2 and 10 elements.
And you get the same effect. Refer to a tuple type by
Tuple(Type1, Type2) and create one by calling
tuple(value1, value2).



 Jun 04 2006



  parent reply Johan Granberg <lijat.meREM OVEgmail.com>  writes:


mike.benfield gmail.com wrote:

 In article <e5u46f$hbe$1 digitaldaemon.com>, Johan Granberg says...

 I to would like tuples (and the other things to) but I realy thing 
 tuples should bee an Built in type.

 Syntax proposal: tuple(type,type,type)


 
 Why would you prefer tuples to be built in? 
 


Because I feel tuple is an fundsmental building block much like arrays 
and as such should bee built in. An additional advantage is that if it 
is a built in type their is no restriction on the number of elements in 
the tuple.

/Just my personal preference by the way



 Jun 04 2006



  parent  Kirk McDonald <kirklin.mcdonald gmail.com>  writes:


Johan Granberg wrote:

 mike.benfield gmail.com wrote:
 

 In article <e5u46f$hbe$1 digitaldaemon.com>, Johan Granberg says...


 I to would like tuples (and the other things to) but I realy thing 
 tuples should bee an Built in type.

 Syntax proposal: tuple(type,type,type)



 Why would you prefer tuples to be built in?


 
 Because I feel tuple is an fundsmental building block much like arrays 
 and as such should bee built in. An additional advantage is that if it 
 is a built in type their is no restriction on the number of elements in 
 the tuple.
 
 /Just my personal preference by the way


This is similarly true if we ever get variadic templates.

-Kirk McDonald



 Jun 04 2006