www.digitalmars.com         C & C++   DMDScript  

D - some thoughts on D

reply "Steven Shaw" <steven_shaw iprimus.com.au> writes:
Hi everyone,

I just read through the D website and I made some notes as I went. In
general I like the idea of D. As a project I think it may have a market much

the way it combines modules, gc and C syntax and interoperability.

* Macros aren't all bad. Textual preprocessing is bad. Symbolic preprocess
might be worth looking at. "Symbolic macros"
   or maybe "safe" macros. There is talk of "symbolic processing" but I
don't think that refers to "symbolic macros".
   Might be useful to look at "hygenic macros" from Scheme and how macros
were done for Dylan (I've started
   looking but I don't get it yet).

* DBC. I don't think Meyer invent it. Good to see it in D, though.

* all function are virtual. How can the compiler tell when they are not
overridden? It seems incomputable in the face of
   separate compilation and dynamic loading (.dll/.so).

* compiler decides based on flag which functions should be inlined. Sounds
good. What I want to know is: are
   inlined functions inlinable only within a module or across modules? I
would like to see them inlinable across
   modules (like you can do with C macros and C++ inline functions in header
files). I guess the inline function would
   need to be stored in the "symbol" file. This means that when you change
the level of optimisation, you can change
   the "symbol" file (the "private" interface to the module). This will
require recompiling all dependent modules, won't it?
   What does the current implementation do?

* "debug" statement may not be flexible enough. Are __FILE__ and __LINE__
supported? I find these useful
   in C and C++ for trace statements and when constructing exceptions.

* sychronisation model looks the same as Java. Java's model has been
critised (sorry I have no reference).
   I no expert on it. Isn't it better to sychronise on data rather than
methods?
   One thing that is generally considered a poor design for Java was the
choice of having a lock for every object.
    I pretty sure someone had this opinion in one of these talks (the middle
one I think):
        http://www.ai.mit.edu/projects/dynlangs/wizards-panels.html   (all
really worth a listen)
    Is there any chance of changing the synchronisation model for D?

* resource release using finally. This is one area where I think "symbolic
macros" would be very useful.
   This would give a syntactic abstraction for releasing the resource. It
would mean that releasing the resource
   was guanteed like with C++ "resource acquisition is initialisation" but
without the need to create a separate
   class and stack-based object. The macro would just expand into
acquire...try...finally...release. This is
   how it's done in CL.

* unit testing built into language. This doesn't feel right to me. Sorry to
be so vague. These seem to be
   specified at the class level. What about the module level? If the unit
tests dwarf the module itself, don't
   you want it in a separate file?

* circular import allowed. Don't most modula-style languages prevent
circular import?
   Why is it that you can get run-time errors when using circular imports?

* typedef. I think it might be nicer to use "type" since D's "typedef" is
different to C and C++. This might ease
   porting.

* I've always disliked how typedef's are back to front. This is just a
personal rant. I'd prefer something like:
            type Width = int;
            type alias int32 = int;

you're still reading? Thanks :-)

and cheers,
Steve.
Jul 03 2002
next sibling parent andy <acoliver apache.org> writes:
 * sychronisation model looks the same as Java. Java's model has been
 critised (sorry I have no reference).


**everything** has been criticized.


    I no expert on it. Isn't it better to sychronise on data rather than
 methods?


you can do such.  synchronize (myObject) { /* ... */ } is the syntax if 
I recall.  It doesn't work as great in my opinion, but to each his own.


    One thing that is generally considered a poor design for Java was the
 choice of having a lock for every object.
     I pretty sure someone had this opinion in one of these talks (the middle
 one I think):
         http://www.ai.mit.edu/projects/dynlangs/wizards-panels.html   (all
 really worth a listen)
     Is there any chance of changing the synchronisation model for D?
 


Change it to what?

Something that is:
1. relatively easy to use, most threading problems aren't because a 
threading model isn't *good* enough or well-designed enough so to speak, 
its because its difficult to use or even more difficult to get right 
often enough.

2. powerful

3. straightforward

4. semi-univeral - makes sense on most platforms.

If you can come up with an alternative that meets those objectives, I'm 
sure it will be taken seriously.  I'm not sure I've seen something I 
like significantly better that meets those objectives.


 without the need to create a separate
    class and stack-based object. The macro would just expand into
 acquire...try...finally...release. This is
    how it's done in CL.


read back in the archive, walter has addressed that issue.



 * unit testing built into language. This doesn't feel right to me. Sorry to
 be so vague. These seem to be
    specified at the class level. What about the module level? If the unit
 tests dwarf the module itself, don't
    you want it in a separate file?
 


I don't think there is anything to prevent you from doing that per-say.
I could be wrong.

-Andy
Jul 03 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
news:afv1m7$1rjp$1 digitaldaemon.com...

 Hi everyone,

 I just read through the D website and I made some notes as I went. In
 general I like the idea of D. As a project I think it may have a market


much


 the way it combines modules, gc and C syntax and interoperability.

 * Macros aren't all bad. Textual preprocessing is bad. Symbolic preprocess
 might be worth looking at. "Symbolic macros"
    or maybe "safe" macros. There is talk of "symbolic processing" but I
 don't think that refers to "symbolic macros".
    Might be useful to look at "hygenic macros" from Scheme and how macros
 were done for Dylan (I've started
    looking but I don't get it yet).


Do you have an idea for how it would work?


 * compiler decides based on flag which functions should be inlined. Sounds
 good. What I want to know is: are
    inlined functions inlinable only within a module or across modules? I
 would like to see them inlinable across
    modules (like you can do with C macros and C++ inline functions in


header

 files). I guess the inline function would
    need to be stored in the "symbol" file. This means that when you change
 the level of optimisation, you can change
    the "symbol" file (the "private" interface to the module). This will
 require recompiling all dependent modules, won't it?
    What does the current implementation do?


D should (eventually) have the compiler and linker integrated enough
together that cross-module inlining should be possible.


 * "debug" statement may not be flexible enough. Are __FILE__ and __LINE__
 supported? I find these useful
    in C and C++ for trace statements and when constructing exceptions.


There is no __FILE__ or __LINE__ equivalent in D, but they might be useful.
More for logging and such than anything else.  Some general way to keep
track of the call stack might be nice too.  (so a debugging function could
walk up the stack and find out who is calling it)


 * resource release using finally. This is one area where I think "symbolic
 macros" would be very useful.
    This would give a syntactic abstraction for releasing the resource. It
 would mean that releasing the resource
    was guanteed like with C++ "resource acquisition is initialisation" but
 without the need to create a separate
    class and stack-based object. The macro would just expand into
 acquire...try...finally...release. This is
    how it's done in CL.


How would you inject code into the middle to actually use the resource?


 * unit testing built into language. This doesn't feel right to me. Sorry


to

 be so vague. These seem to be
    specified at the class level. What about the module level? If the unit
 tests dwarf the module itself, don't
    you want it in a separate file?


It may be nice to be able to split a big module up into several source
files.  I see no real reason to limit modules to one actual disk file.  But
then we'd need some kind of module declaration block in the language.


 * circular import allowed. Don't most modula-style languages prevent
 circular import?
    Why is it that you can get run-time errors when using circular imports?


Circular imports will burn you, but sometimes they're just plain necessary.


 * typedef. I think it might be nicer to use "type" since D's "typedef" is
 different to C and C++. This might ease porting.


I agree that typedef, having a different meaning from C's typedef, should be
renamed.  But not sure to what.


 * I've always disliked how typedef's are back to front. This is just a
 personal rant. I'd prefer something like:
             type Width = int;
             type alias int32 = int;


I miss Pascal too sometimes.  I find C type specifiers totally backward.
Walter seems to want to keep the style similar for D though.  Currently it's
mostly backward compatible with C.


 you're still reading? Thanks :-)

 and cheers,
 Steve.


Sean
Jul 05 2002
parent reply "Steven Shaw" <steven_shaw iprimus.com.au> writes:
----- Original Message -----
From: "Sean L. Palmer" <seanpalmer earthlink.net>
Newsgroups: D
Sent: Friday, July 05, 2002 9:59 PM
Subject: Re: some thoughts on D



 "Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
[snip]

 * Macros aren't all bad. Textual preprocessing is bad. Symbolic




preprocess

 might be worth looking at. "Symbolic macros"
    or maybe "safe" macros. There is talk of "symbolic processing" but I
 don't think that refers to "symbolic macros".
    Might be useful to look at "hygenic macros" from Scheme and how




macros

 were done for Dylan (I've started
    looking but I don't get it yet).


 Do you have an idea for how it would work?
[snip]



 * resource release using finally. This is one area where I think




"symbolic

 macros" would be very useful.
    This would give a syntactic abstraction for releasing the resource.




It

 would mean that releasing the resource
    was guanteed like with C++ "resource acquisition is initialisation"




but

 without the need to create a separate
    class and stack-based object. The macro would just expand into
 acquire...try...finally...release. This is
    how it's done in CL.


 How would you inject code into the middle to actually use the resource?


This is from an email I got from a Common Lisp proponent:

---------------
      (with-file-open (F "foo.bar")
          (do-stuff-with F)
          (do-more-stuff-with F)
          (loop while (some-condition)
                   do (again-more-stuff-with F)))

This completely looks and feels like CL code.

The macro essentially (I am leaving a lot of details out) "expands"
into something like

      (let ((F (open "foo.bar")))
        (unwind-protect
            (block nil
                 (do-stuff-with F)
                 (do-more-stuff-with F)
                 (loop while (some-condition)
                          do (again-more-stuff-with F)))
          (close F)))
----------

The unwind-protect thing is essentially a try..finally. Of course, CL is
nothing like C. However, Dylan does have a infix syntax and so that's why
it'd be good to see what their macros are like. Hopefully this shows the
point - though it's too many brackets for my eyes :-).


 * unit testing built into language. This doesn't feel right to me. Sorry


 to

 be so vague. These seem to be
    specified at the class level. What about the module level? If the




unit

 tests dwarf the module itself, don't
    you want it in a separate file?


 It may be nice to be able to split a big module up into several source
 files.  I see no real reason to limit modules to one actual disk file.


But

 then we'd need some kind of module declaration block in the language.


I still feel that having a unit test feature in the language just isn't
right...
What about other kinds of tests - do you add a feature for them, too?


 [snip]


cheers,
Steve.
Jul 05 2002
next sibling parent "Steven Shaw" <steven_shaw iprimus.com.au> writes:
Here's a page with an example of macros in Dylan:

http://www.gwydiondylan.org/fragments/macros.phtml

Luckily it's a relevant example of using a mutex lock.
Jul 05 2002
prev sibling parent "Steven Shaw" <steven_shaw iprimus.com.au> writes:
Here's a link to the Dylan Reference manual on macros:

http://www.gwydiondylan.org/drm/drm_76.htm#HEADING76-0

I'm afraid I don't know how the dylan macro system works exactly (i.e. I
couldn't implement it). I just think it looks like a good idea.

cheers,
Steve.
Jul 05 2002