Hi,

D seems to be a really nice idea -- I've been looking for a language which has these features.  I have some suggestions for the few places where (I think) I have different ideas or preferences:


Multiple Inheritance:
   There are some advantages to multiple inheritance.  Note that the problems
   normally occur when you try to inherit a class in more than one way,
   so that you have inherited twice from an ancestor; we could call this
   "incest" and disallow it but allow other multiple inheritance.  This
   also makes the language syntax a bit simpler (since you don't need
   "interface").


Potentially dangerous C features:
   Since the language is not directly C-compatible, it would be nice to
   remove some common problems with C:
      - Accidental fallthoughs in switches:   these could be prevented using
        a goto (like C#) or a compulsory continue or fallthrough statement.
      - Forgetting { } around a code block:   braces could be made
        compulsory, or a style more like Ada's blocking could be used.
      - Side-effects:  using side-effects is regarded as confusing and could be
        disallowed.


Possible new features:
   Similarly, it might be worth adding some features from other languages
   such as Python:
      - Tuples are quite nice, for example to return more than one value from
        a function.  It would be OK to say that the type has to be
        determinable at runtime.
      - Lists would be useful for operations such as appending and slicing.
        It would be OK for the type to be the same, like an array.  (Perhaps
        the dynamic array type could have these properties?)
      - Ranges are an idea I have which I haven't seen implemented but which
        might prevent off-by-one errors.  It would be a type derived from a
        base type (int, float, char,...) which has a start, an end and a
        length; its value depends on any two of these since the third is then
        fixed.  Then any of the three could be used (e.g., x = range.length).
      - It would be nice to be able to say "foreach i in set" where set is
        a range, list or array.


Does the order of declarations in a file matter?  In C it does, but in Java it doesn't; I think it would be nicer if D didn't.  For example, in C if you define a function foo() which calls function bar(), but bar() is defined later in the same file, then you have to give a prototype.


Can variables in D be declared in the middle of code blocks (like Java) or
only at the start (like C)?  I am not sure which is preferable.


Being able to use C libraries is great -- one of the fundamental things I wanted in the language.  However, how do you plan to deal with importing the C include files?  Is there any easy way to handle this?


If the name is a problem, other corny variants on C are possible such as
Object-Improved C, or Seymour;)  (Sequel is also OK but is taken, sort of.)


Ben.

"Ben Cohen" <bc@skygate.co.uk> wrote in message news:9lgtfa$2g90$1@digitaldaemon.com...
> Hi,
> D seems to be a really nice idea -- I've been looking for a language which
> has these features.  I have some suggestions for the few places where (I
> think) I have different ideas or preferences:

Fire away.

> Multiple Inheritance:
>    There are some advantages to multiple inheritance.  Note that the
problems
>    normally occur when you try to inherit a class in more than one way,
>    so that you have inherited twice from an ancestor; we could call this
>    "incest" and disallow it but allow other multiple inheritance.  This
>    also makes the language syntax a bit simpler (since you don't need
>    "interface").

Experience suggests that single inheritance with interfaces will cover nearly all the bases. I know some people really do want MI, but my eyes always glaze over trying to understand it, and I think I'll just stay away!

> Potentially dangerous C features:
>    Since the language is not directly C-compatible, it would be nice to
>    remove some common problems with C:
>       - Accidental fallthoughs in switches:   these could be prevented
using
>         a goto (like C#) or a compulsory continue or fallthrough
statement.

This keeps coming up. I happen to use the fallthrough thing a lot, and just don't want to give it up! I also suspect that removing it may make for a difficult transition from C to D, since one can get soooo used to the fallthrough.

>       - Forgetting { } around a code block:   braces could be made
>         compulsory, or a style more like Ada's blocking could be used.

This is already true in some cases, you can't do:

    while (...) ;

since that is likely a typo. Instead, use:

    while (...) { }

for an empty loop.

>       - Side-effects:  using side-effects is regarded as confusing and
could be
>         disallowed.

This is a good idea, and it can be approached with the compiler, but not absolutely solved.


> Possible new features:
>    Similarly, it might be worth adding some features from other languages
>    such as Python:
>       - Tuples are quite nice, for example to return more than one value
from
>         a function.  It would be OK to say that the type has to be
>         determinable at runtime.

Tuples are a great idea, but the D way is to use out parameters.

>       - Lists would be useful for operations such as appending and
slicing.
>         It would be OK for the type to be the same, like an array.
(Perhaps
>         the dynamic array type could have these properties?)

I think the dynamic array will cover these uses.

>       - Ranges are an idea I have which I haven't seen implemented but
which
>         might prevent off-by-one errors.  It would be a type derived from
a
>         base type (int, float, char,...) which has a start, an end and a
>         length; its value depends on any two of these since the third is
then
>         fixed.  Then any of the three could be used (e.g., x =
range.length).

That looks like it might be a reasonable extension to enums.

>       - It would be nice to be able to say "foreach i in set" where set is
>         a range, list or array.

> Does the order of declarations in a file matter?  In C it does, but in
Java
> it doesn't; I think it would be nicer if D didn't.  For example, in C if
> you define a function foo() which calls function bar(), but bar() is
> defined later in the same file, then you have to give a prototype.

The order does not matter. It is surprising how liberating that is.


> Can variables in D be declared in the middle of code blocks (like Java) or
> only at the start (like C)?  I am not sure which is preferable.

In the middle. I think it makes for more readable code as you can locate the declaration next to where it is used.


> Being able to use C libraries is great -- one of the fundamental things I wanted in the language.  However, how do you plan to deal with importing the C include files?  Is there any easy way to handle this?

I've been thinking of writing a tool to convert a .h file into an import file. Having a C compiler, this would not be too difficult. The trouble comes from attempting to convert macro constants into enums. It's unlikely the tool would do a perfect job, it'd require some hand editting of the result.


> If the name is a problem, other corny variants on C are possible such as Object-Improved C, or Seymour;)  (Sequel is also OK but is taken, sort
of.)

The name "D" started out as a joke from my friends, but it just kinda stuck. Finally, I just gave in and search & replaced the name to "D" in the documentation. Funny how things work out <g>.

In article <9lh4a4$2ok1$1@digitaldaemon.com>, "Walter" <walter@digitalmars.com> wrote:

>> Potentially dangerous C features:
>>    Since the language is not directly C-compatible, it would be nice to
>>    remove some common problems with C:
>>       - Accidental fallthoughs in switches:   these could be prevented
> using
>>         a goto (like C#) or a compulsory continue or fallthrough
> statement.
> 
> This keeps coming up. I happen to use the fallthrough thing a lot, and just don't want to give it up! I also suspect that removing it may make for a difficult transition from C to D, since one can get soooo used to the fallthrough.
> 
>>       - Forgetting { } around a code block:   braces could be made
>>         compulsory, or a style more like Ada's blocking could be used.
> 
> This is already true in some cases, you can't do:
> 
>     while (...) ;
> 
> since that is likely a typo. Instead, use:
> 
>     while (...) { }
> 
> for an empty loop.

I also think that changes from C to D should be minimised, and should be limited to useful extensions, simplifying the language, and making the language safer.  So, for example, your alteration to struct's namespace is great (I would have done that) since it simplifies the language; while In, Out, InOut make the language safer and even simplify it a bit (since you don't then need pointers so much).

You want D to be for people who "routinely use lint..." and "compile with maximum warning levels...", so I would think that one of the language's aims would be to be as safe as possible to program in.  I think the two problems above are two of the most common C pitfalls which you haven't already addressed.

I like the suggestion for treatment of switches by Mark Shackelford ("Suggestions: switch, case, also, elsif syntax").  Incidentally, can you do a ``break label'' out of a switch?

I agree that enforcing {} rather than just ; for an empty while is good. Enforcing {} for a single statement looks messy and would be irritating at first because C programmers aren't used to it, but it might be worth it. The alternative would be having something like Ada:

if ...
    statements
    statements
endif

This has the disadvantage that it no longer looks like C (and is slower to type).  I am not sure which I prefer here.

>> Possible new features:
>>    Similarly, it might be worth adding some features from other
>>    languages such as Python:
>>       - Tuples are quite nice, for example to return more than one
>>       value
> from
>>         a function.  It would be OK to say that the type has to be
>>         determinable at runtime.
> 
> Tuples are a great idea, but the D way is to use out parameters.

Or structs/objects (if you want to plug several return values from one
function into another)...  OK.

>>       - Lists would be useful for operations such as appending and
> slicing.
>>         It would be OK for the type to be the same, like an array.
> (Perhaps
>>         the dynamic array type could have these properties?)
> 
> I think the dynamic array will cover these uses.

That's what I was hoping -- so the dynamic array can change its length even when it is instantiated and has values.

>>       - Ranges are an idea I have which I haven't seen implemented but
> which
>>         might prevent off-by-one errors.  It would be a type derived
>>         from
> a
>>         base type (int, float, char,...) which has a start, an end and
>>         a length; its value depends on any two of these since the third
>>         is
> then
>>         fixed.  Then any of the three could be used (e.g., x =
> range.length).
> 
> That looks like it might be a reasonable extension to enums.

That looks like a sensible way to do it.

>>       - It would be nice to be able to say "foreach i in set" where set
>>       is
>>         a range, list or array.

Is there a way to do this?

>> Does the order of declarations in a file matter?  In C it does, but in
> Java
>> it doesn't; I think it would be nicer if D didn't.  For example, in C
>> if you define a function foo() which calls function bar(), but bar() is
>> defined later in the same file, then you have to give a prototype.
> 
> The order does not matter. It is surprising how liberating that is.

That's really good.

>> If the name is a problem, other corny variants on C are possible such as Object-Improved C, or Seymour;)  (Sequel is also OK but is taken, sort
> of.)
> 
> The name "D" started out as a joke from my friends, but it just kinda stuck. Finally, I just gave in and search & replaced the name to "D" in the documentation. Funny how things work out <g>.

Yes, D (or P;) is a much more `traditional' sequel to C!  What would you
have called it?

 A couple of comments.

Walter wrote:

> "Ben Cohen" <bc@skygate.co.uk> wrote in message news:9lgtfa$2g90$1@digitaldaemon.com...
>
> >       - Tuples are quite nice, for example to return more than one value
> from
> >         a function.  It would be OK to say that the type has to be
> >         determinable at runtime.
>
> Tuples are a great idea, but the D way is to use out parameters.
>

Tuples are available in C++ via the Lambda Library. (See http://lambda.cs.utu.fi/ but it won't run with DM unfortunately.) There is also a version from the same stable in the Boost collection. I don't see how out parameters can be made to nest in the same way as a return value.

>
> I've been thinking of writing a tool to convert a .h file into an import file. Having a C compiler, this would not be too difficult. The trouble comes from attempting to convert macro constants into enums. It's unlikely the tool would do a perfect job, it'd require some hand editting of the result.

Havve you looked at the work of SWIG (http://www.swig.org/) which while designed to generate an interface to C or C++ from another language, certainly can parse a reduced form of a header file. It is extensible via language modules (I haven't looked into this) so might be a way to interface code to D.

John Fletcher

> > This keeps coming up. I happen to use the fallthrough thing a lot, and just don't want to give it up! I also suspect that removing it may make for a difficult transition from C to D, since one can get soooo used to the fallthrough.
> >
> >>       - Forgetting { } around a code block:   braces could be made
> >>         compulsory, or a style more like Ada's blocking could be used.
> >
> > This is already true in some cases, you can't do:
> >
> >     while (...) ;
> >
> > since that is likely a typo. Instead, use:
> >
> >     while (...) { }
> >
> > for an empty loop.

I see a problem with the reasoning here: "I make that mistake, so I remove it from the language (while {}), but I use the other feature, so I keep it even if it's a common mistake for others."

I personally tend to use the semi-colon 'for' and 'while' forms regularly. Typically:

    for (list = first; list && !condition(list); list = list->next);

On the other hand, I tend to "document" that, as well as fall throughs:

    for (list = first; list && !condition(list); list = list->next) /* nop
*/;
    if (list)
        switch (list->data)
        {
        case BIG:
            list->bigflag = true;
            /* fallthrough */
        case SMALL:
            ...
        }


> I agree that enforcing {} rather than just ; for an empty while is good. Enforcing {} for a single statement looks messy and would be irritating at first because C programmers aren't used to it, but it might be worth it. The alternative would be having something like Ada:
>
> if ...
>     statements
>     statements
> endif
>
> This has the disadvantage that it no longer looks like C (and is slower to type).  I am not sure which I prefer here.

Or you can use intend-based syntax, as in LX or Python. It's remarkable how much "clutter" it removes from code:

    if condition then statements; statements
    if condition then
        statement
        statement
    statement // not in the if


>
>
> >> Possible new features:
> >>    Similarly, it might be worth adding some features from other
> >>    languages such as Python:
> >>       - Tuples are quite nice, for example to return more than one
> >>       value
> > from
> >>         a function.  It would be OK to say that the type has to be
> >>         determinable at runtime.
> >
> > Tuples are a great idea, but the D way is to use out parameters.
>
> Or structs/objects (if you want to plug several return values from one
> function into another)...  OK.

Tuples actually are not the same thing as structs, and they are often more readable than out parameters (but not always, so having both is good.)

    (A, B, C) = foo(1, 2, 3)
    foo(1, 2, 3, A, B, C)
    foo(1, 2, 3, out A, out B, out C)

LX doesn't support tuples as a language feature, but only because you can implement them in the library.


>
> >>       - Lists would be useful for operations such as appending and
> > slicing.
> >>         It would be OK for the type to be the same, like an array.
> > (Perhaps
> >>         the dynamic array type could have these properties?)
> >
> > I think the dynamic array will cover these uses.
>
> That's what I was hoping -- so the dynamic array can change its length even when it is instantiated and has values.

Dynamic arrays and lists have very different performance characteristics. That's why the STL has both. As I said in other threads, BUILT-IN TYPES ARE EVIL.


>
>
> >>       - Ranges are an idea I have which I haven't seen implemented but
> > which
> >>         might prevent off-by-one errors.  It would be a type derived
> >>         from
> > a
> >>         base type (int, float, char,...) which has a start, an end and
> >>         a length; its value depends on any two of these since the third
> >>         is
> > then
> >>         fixed.  Then any of the three could be used (e.g., x =
> > range.length).
> >
> > That looks like it might be a reasonable extension to enums.
>
> That looks like a sensible way to do it.

Same thing: your language ought to be able to DEFINE range objects, rather than have to build them in.

In article <3B7D2DDC.C631FFE1@earthlink.net>, "Christophe de Dinechin" <descubes@earthlink.net> wrote:

> I see a problem with the reasoning here: "I make that mistake, so I remove it from the language (while {}), but I use the other feature, so I keep it even if it's a common mistake for others."
> 
> I personally tend to use the semi-colon 'for' and 'while' forms regularly. Typically:
> 
>     for (list = first; list && !condition(list); list = list->next);
> 
> On the other hand, I tend to "document" that, as well as fall throughs:
> 
>     for (list = first; list && !condition(list); list = list->next) /*
>     nop
>  */;

Python uses the "pass" statement which is explicit like this, but {} might be good enough.


>     if (list)
>         switch (list->data)
>         {
>         case BIG:
>             list->bigflag = true;
>             /* fallthrough */
>         case SMALL:
>             ...
>         }

Yes, I'm basically asking that the language requires this comment, but makes it a keyword rather than a comment :)


>> might be worth it. The alternative would be having something like Ada:
>>
>> if ...
>>     statements
>>     statements
>> endif
>>
>> This has the disadvantage that it no longer looks like C (and is slower to type).  I am not sure which I prefer here.
> 
> Or you can use intend-based syntax, as in LX or Python. It's remarkable how much "clutter" it removes from code:
> 
>     if condition then statements; statements if condition then
>         statement
>         statement
>     statement // not in the if

This is less cluttered but how often do lines accidentally not get indented enough?  The Ada form is a bit more secure here since you can't get the indent wrong by mistake and you can't miss the endif out by mistake as it's required.


>> >> Possible new features:
>> >>    Similarly, it might be worth adding some features from other
>> >>    languages such as Python:
>> >>       - Tuples are quite nice, for example to return more than one
>> >>       value
>> > from
>> >>         a function.  It would be OK to say that the type has to be
>> >>         determinable at runtime.
>> >
>> > Tuples are a great idea, but the D way is to use out parameters.
>>
>> Or structs/objects (if you want to plug several return values from one
>> function into another)...  OK.
> 
> Tuples actually are not the same thing as structs, and they are often more readable than out parameters (but not always, so having both is good.)

Yes, I meant that if you needed to get some values from one function to place into another, assuming you'd designed them yourself, it could be more appropriate to define a struct instead.

I'd envisaged tuples as a grouping notation, rather than as an actual language type; it would be determined at compile time (oops, I meant that, not runtime) as if you had defined a struct, but you don't have to as a convenience.

"Walter" <walter@digitalmars.com> wrote in message news:9lh4a4$2ok1$1@digitaldaemon.com...
> "Ben Cohen" <bc@skygate.co.uk> wrote in message news:9lgtfa$2g90$1@digitaldaemon.com...

<snip>

> Experience suggests that single inheritance with interfaces will cover nearly all the bases. I know some people really do want MI, but my eyes always glaze over trying to understand it, and I think I'll just stay
away!

A few years ago I did about 12 months worth of Java development. I didn't come across a single problem that couldn't be solved by interfaces. It's my opinion that most times when people want to use multiple inheritance, they're just plain wrong (eg., mistaking has-a relationships for is-a relationships) and the rest of the time what they *really* need is Java-style interfaces rather than MI.

Regards,
John Carney.

Ben Cohen wrote in message <9limv6$14q5$1@digitaldaemon.com>...
>I also think that changes from C to D should be minimised, and should be limited to useful extensions, simplifying the language, and making the language safer.

Yes, absolutely. I want it to feel like C and be comfortable for C programmers to use.

>So, for example, your alteration to struct's namespace is
>great (I would have done that) since it simplifies the language;

I proposed that to the C++ people way back in 88. I still think not fixing that was a massive mistake for C++.

>I like the suggestion for treatment of switches by Mark Shackelford ("Suggestions: switch, case, also, elsif syntax").  Incidentally, can you do a ``break label'' out of a switch?


Yes.


>Yes, D (or P;) is a much more `traditional' sequel to C!  What would you
>have called it?

The original name was the "Mars" language. Note the company name <g>.

John Fletcher wrote in message <3B7D0E76.D3EED485@aston.ac.uk>...
>> I've been thinking of writing a tool to convert a .h file into an import file. Having a C compiler, this would not be too difficult. The trouble comes from attempting to convert macro constants into enums. It's
unlikely
>> the tool would do a perfect job, it'd require some hand editting of the result.
>Havve you looked at the work of SWIG (http://www.swig.org/) which while
designed
>to generate an interface to C or C++ from another language, certainly can
parse
>a reduced form of a header file. It is extensible via language modules (I haven't looked into this) so might be a way to interface code to D.



The big thing to convert is windows.h. It takes a lot of development work to successfully parse it. Since I've got that already, I just have to build something to walk the symbol table and output a D import.

John Carney wrote:
> ...
> A few years ago I did about 12 months worth of Java development. I didn't
> come across a single problem that couldn't be solved by interfaces. It's my
> opinion that most times when people want to use multiple inheritance,
> they're just plain wrong (eg., mistaking has-a relationships for is-a
> relationships) and the rest of the time what they *really* need is
> Java-style interfaces rather than MI.
> 
> Regards,
> John Carney.
> 
But it would be nice to be able to declare, after the fact, that "that (precompiled & I don't have source code) class supports my brand new interface.  Particularlly if you could also indicate:  But what it calls rutabagas() are elsewhere called turnips(), and that's how I'm referring to them.

The feature that "Jamie" (a Java preprocessor) called delegation would also be useful.  I would agree that these two features in combination would essentially eliminate the need for multiple inheritance.  But without them simple things sometimes take an alarming amount of code, as you write by hand a large number of methods of, e.g., the form:
int A(p : Parameter)
{  return p.A();  }