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