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 in common with C#, MS-CLR, go-mono and portable.net. As a language, I like 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.

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

"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
> in common with C#, MS-CLR, go-mono and portable.net. As a language, I like 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

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

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.

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.