Good day, all.


I will go through the D spec section by section, and list my comments.


First of, I believe the creation of D requires a specific goal of exactly where the language sits over top of the machine, what capabilities are necessary, and then throw the rest away.

This will prevent the mess that C++ is, in regards to trying to be 'everything to everyone', but rather have things done the right way.

I think your specification actually quite well nearly embodies Java, and I doubt that is your goal!

I'll repeat that I think that it is very important to decide right early on exactly what level the language will be based about.

The spec right now just looks like a load of loosely strung together ideas. That's nice - except to put together something real, you need to have a clear definition of your *design philosophy* before deciding much else. Your future decisions about what features to include/drop, and how they are to be implemented should definitely be based on that philosophy.

One of the reasons why C++ is such a pain in the arse to learn is because it had no clear objective for following a design philosophy, and tried to appease everyone.  _I_ like C++ (it's my preferred general purpose programming language), but it is huge, unwieldy, and a lot of concepts don't fill well together -- because they weren't designed with the same level of abstraction and general design in mind.

Which makes it a pain in the arse to learn, and implement.

My last general comment is about how you say, "There is no VM.", "It is compiled", and other comments along those lines.  This is a -language- specification, not an -implementation- specification, right?  If we get too specific here, and we don't think ahead, then there WON'T be a virtual machine or embedded scripting language.  That is short sighted.


Things have to be designed in a general enough fashion that is well ** thought out.  It should be easily implementable and flexible enough to be implemented in any which way - as an embeddable scripting language, or a native compiler.

That is the only way you will have success.  There are already enough languages that are too inflexible that only work in one environment.  One language (that you also seemed to have "borrowed" quite a bit of your spec ideas from) to look at for inspiration is Java.  It works well as a native compiled language, or byte code. This is a good thing.  The language has to take these generalities into account.



OK, now on to the bickering about featurism.


Excerpt:
         Exception handling. More and more experience with exception
         handling shows it to be a superior way to handle errors than the C
         traditional method of using error codes and errno globals.

Comment:

         Definitely.  When I am writing bog standard C code, I typically
         engage in the practise of creating my own exception handling-ish
         sort of routines by creating an "error stack".

         I have a struct that looks somewhat like this:

         struct error_s
         {
                 char *file, *function;
                 char error[ ERROR_MESSAGE_SIZE ];
                 int xerrno;
         };

         Then, I create an an array of these, and manipulate it as a stack.

         I have my macro to push an error on to the stack:

         #define ERROR( fmt, args... ) {                         \
                es_push( );                                     \
                error_sp->error[ERROR_MESSAGE_SIZE - 1] = '\0'; \
                snprintf( error_sp->error, ERROR_MESSAGE_SIZE - 1,\
			fmt, ## args ); \
                error_sp->file = __FILE__;                      \
                error_sp->function = __FUNCTION__;              \
                error_sp->line = __LINE__;                      \
                error_sp->xerrno = errno;                       \
                }

         To read all of the errors, I simply call es_pop() until it returns
         null (no more errors).  This works very well.  It means I can have
         a function -- say, create_listening_socket() -- which calls a few
         other functions that I have written (like create_socket(),
         bind_socket()?).  bind_socket() may have a syscall error, call the
         ERROR() macro right away saying "bind() failed".
         create_listening_socket() sees this, pushes its own error message
         on the stack ("Unable to bind socket"), and returns.

         The result?  The calling function can do something like this:

         void print_errors( void )
         {
            error_t *e;


            while( (e = es_pop() )
            {
               if ( e->xerrno )
                  printf( "%s <%s:%d>: %s (%s)\n",
                     e->file, e->function, e->line, e->error,
                     strerror(e->xerrno) );
               else
                  printf( "5s <%s:%d> %s\n",
                     e->file, e->function, e->line, e->error );
            }
         }

         Which prints something like this:

         rawsocket.c <create_listening_socket:321>:  bind_socket failed
         rawsocket.c <bind_socket:21>:  bind() failed (Address in use)

         (or something to that effect)

         Perhaps the language should incorporate some thing like this.


Excerpt:
         C source code compatibility. Extensions to C that maintain source
         compatibility have already been done (C++ and ObjectiveC). Further
         work in this area is hampered by so much legacy code it is unlikely
         that significant improvements can be made.

Comment:
         In fact, it would probably be easiest to, at first, write the
         compiler to simply compile down to C code.


Excerpt:
         Templates. Templates are a way to implement generic programming.
         Other ways are using macros, or having a variant data type. Using
         macros is out.  Variants are straightforward, but the loss of type
         checking is a problem.  The difficulties with C++ templates are
         their complexity, they don't fit well into the syntax of the
         language, all the various rules for conversions and overloading
         fitted on top of it, etc. What's needed is a smoother way to
         integrate them into the language, so they have a much more natural
         and obvious feel to them. I am searching for this solution.

Comment:
         I agree that the syntax doesn't fit well, and things can get
         clouded dead quick with the various rules you're speaking about.

         D *must* have some sort of templates, however.  It is probably wise
         to look at the way Ada does generics - very smoothly done there.


Excerpt:
         On arrays...

Comment:
         In Ada, the array length is actually part of the *array type
         information*.  This makes for efficient array block copying
         routines.  It makes sense.


Excerpt:
        String manipulation is so common, and so clumsy in C and C++, that
        it needs direct support in the language. Modern languages handle
        string concatenation, copying, etc., and so does D.

Comment:
        Have match operators on strings for various string matching
        algorithms, and have the standard library have a regexp state
        machine (!!)

        Do not make the mistake of releasing it with the standard library
        not having one!


Excerpt:
        The fundamental data type is the bit, and D has a bit data type.
        This is most useful in creating arrays of bits:

Comment:
        For implementation, pack this in memory, round off (up) to native
        integer size?


Excerpt:
        D supports simple C style struct's, both for compatibility with C
        data structures and because they're useful when the full power of
        classes is overkill.

Comment:
        Support for packing structs should definitely be native.


Excerpt:
        Assignments do not yield boolean results

Comment:
        Assignments in C don't.  (x = 5) emits the value of 5.



On the subject of identifiers, I believe you should use international English, not American English.  For example, 'synchronized' should be 'synchronised'.  At least have _both_ - that's a pet peeve of mine (and would probably be a pet peeve for Americans if we made them use proper English spellings!).


I've already written too much for one email.  More to follow later.


Cheers,
	Matt


-- 
Nature, to be commanded, must be obeyed. -- Sir Francis Bacon

"Matt Busigin" <mbusigin@helios.spang.org.uk> wrote in message news:9lhi4r$5u3>
>
>
> I'll repeat that I think that it is very important to decide right early
on
> exactly what level the language will be based about.
>
> The spec right now just looks like a load of loosely strung together
ideas.
> That's nice - except to put together something real, you need to have a clear definition of your *design philosophy* before deciding much else. Your future decisions about what features to include/drop, and how they
are
> to be implemented should definitely be based on that philosophy.

The philsophy seems obvious to me: C++ but better.

> My last general comment is about how you say, "There is no VM.", "It is compiled", and other comments along those lines.  This is a -language- specification, not an -implementation- specification, right?  If we get
too
> specific here, and we don't think ahead, then there WON'T be a virtual machine or embedded scripting language.  That is short sighted.

You wanted a philosophy?  Here is a system level programming language.
Personally, as a game programmer I couldn't care less about embedding
scripting-D or compiled-to-bytecode-D.
I would say treating that stuff as afterthoughts is absolutely the right
answer - make D a better C++ and let Java be Java and Perl be Perl.

> Excerpt:
>          Exception handling. More and more experience with exception
>          handling shows it to be a superior way to handle errors than the
C
>          traditional method of using error codes and errno globals.
>
> Comment:
(error stack described)

Why use an error stack?  Catch the exception, output the error, throw the exeption and catch it again at the next level to output the next level of error messages.  Otherwise you must clean up after the error at every level and finally output each level's errors at the top level which makes no sense to me.

> Excerpt:
>          C source code compatibility. Extensions to C that maintain source
>          compatibility have already been done (C++ and ObjectiveC).
Further
>          work in this area is hampered by so much legacy code it is
unlikely
>          that significant improvements can be made.
>
> Comment:
>          In fact, it would probably be easiest to, at first, write the
>          compiler to simply compile down to C code.

Walter is saying you cannot compile C code in a D compiler, and you reply that you should be able to compile D _into_ C?  The two are not related in any way.

> Excerpt:
>         String manipulation is so common, and so clumsy in C and C++, that
>         it needs direct support in the language. Modern languages handle
>         string concatenation, copying, etc., and so does D.
>
> Comment:
>         Have match operators on strings for various string matching
>         algorithms, and have the standard library have a regexp state
>         machine (!!)
>
>         Do not make the mistake of releasing it with the standard library
>         not having one!

I agree.  And since Digital Mars' C/C++ compilers have regular expressions, I imagine D would too.


> (arrays of bits should be packed, structs should be packed)

As a man with decades of experience writing compilers, I wonder whether Warren needs handholding with the simplest of implementation issues.

Angus Graham

Angus Graham wrote:
> 
> "Matt Busigin" <mbusigin@helios.spang.org.uk> wrote in message news:9lhi4r$5u3>
> > Comment:
> >          In fact, it would probably be easiest to, at first, write the
> >          compiler to simply compile down to C code.
> 
> Walter is saying you cannot compile C code in a D compiler, and you reply that you should be able to compile D _into_ C?  The two are not related in any way.

A common trend for new languages is to make the early implementations compile to C, and then use C as a "portable assembly language" to avoid having to write an optimizing compiler back-end. I assume this is what Matt meant.

The initial implementation of C++, in fact, was a C++-to-C compiler (not a simple translator) called Cfront. See Stroustrup's _The Design and Evolution of C++_ for more details.

-Russell B

> The initial implementation of C++, in fact, was a C++-to-C compiler (not a simple translator) called Cfront. See Stroustrup's _The Design and Evolution of C++_ for more details.

Yes, and Cfront was one reason why C++ got a really bad reputation in the early days as the compilation speeds very dismal (used to be a big concern over at Apple, compile times of 15, 30 minutes or more...). A big problem was the amount of C code generated, but the again at those times memory was tight and CPU cycles slow, so eventually this problem is no longer there. But in general, if the first taste of a new compiler is slowness, how good the language itself is, it will be rejected (and hard to repair the image long term). --Kent

Kent Sandvik wrote:
> 
> > The initial implementation of C++, in fact, was a C++-to-C compiler (not a simple translator) called Cfront. See Stroustrup's _The Design and Evolution of C++_ for more details.
> 
> Yes, and Cfront was one reason why C++ got a really bad reputation in the early days...

This seems like less of an issue today than it would have been in the early days of C++.

> But in general, if the first taste of a new compiler is slowness, how good the language itself is, it will be rejected (and hard to repair the image long term).

Doesn't seem to have hurt C++'s acceptance all that much in the long term, but it may have been a factor in the persistent "C++ is bloated" meme.

At any rate, given who's implementing this, I doubt that D's backend will be a complete C compiler. :)

-Russell B

Angus Graham wrote:

> 
> The philsophy seems obvious to me: C++ but better.
> 


Just like C++ was 'C, but better' (or C, with classes, ore accurately), and look what a mess it became!  I think you need more clearly defined and thought out ideas about where you want to go - and take a look at Ada as a very good example of a language that did this.


> You wanted a philosophy?  Here is a system level programming language.
> Personally, as a game programmer I couldn't care less about embedding
> scripting-D or compiled-to-bytecode-D.
> I would say treating that stuff as afterthoughts is absolutely the right
> answer - make D a better C++ and let Java be Java and Perl be Perl.


Of course.  But as a control systems programmer, for my non-realtime systems, scriptable procedures written in the same language as the caller would be excellent.

Writing various things as modules is one thing, but a lot of things suit the scripted VM paradigm, too.  Especially if it were machine independent with the standard libraries .. (not that I would expect an implementation like this within a short period of time ;)

What I am saying, is that part of the philosophy also should be thinking about flexibility and portability to other applications.  (applications, in a general sort of way)


> Why use an error stack?  Catch the exception, output the error, throw > the
> exeption and catch it again at the next level to output the next level > of
> error messages.  Otherwise you must clean up after the error at every > level
> and finally output each level's errors at the top level which makes no > sense
> to me.

Excuse the crap quoting. The reason is output management.  One of the weakest parts of almost any code.  Yes, easily implementable in host code.


Errors and exceptions generally queue up . You generally have to handle them that way.  Why not make a nice clean interface to do it?

> Walter is saying you cannot compile C code in a D compiler, and you  reply
> that you should be able to compile D _into_ C?  The two are not related in
> any way.


Right that does it, I'm going to tin tomorrow.

No, sorry, not directly related.  I'll blame tiredness on my rather unrelated comment.

> I agree.  And since Digital Mars' C/C++ compilers have regular >expressions,
> I imagine D would too.

Excellent.


>>(arrays of bits should be packed, structs should be packed)
>>
> 
> As a man with decades of experience writing compilers, I wonder whether
> Warren needs handholding with the simplest of implementation issues.

Not all structs should be packed, unless explicitely stated.  Perhaps he has other ideas for that.


Cheers,
Matt

Russell Bornschlegel wrote:
> Kent Sandvik wrote:
> 
>>>The initial implementation of C++, in fact, was a C++-to-C compiler
>>>(not a simple translator) called Cfront. See Stroustrup's _The Design
>>>and Evolution of C++_ for more details.
>>>
>>Yes, and Cfront was one reason why C++ got a really bad reputation in the
>>early days...
>>
> 
> This seems like less of an issue today than it would have been in the early days of C++.
> 

Quite true.  Writing a backend to GCC would probably be the best (and I believe I read that he wanted this done eventually?)

Im Artikel <9lhi4r$5u3$1@digitaldaemon.com> schrieb "Matt Busigin" <mbusigin@helios.spang.org.uk>:

> On the subject of identifiers, I believe you should use international English, not American English.  For example, 'synchronized' should be 'synchronised'.  At least have _both_ - that's a pet peeve of mine (and would probably be a pet peeve for Americans if we made them use proper English spellings!).

You are making a worse mistake by assuming that your preferred spelling
is "international". It isn't. American spelling is taught as standard
is many countries. In any case, it's ridiculous to gripe about this.
As least the words are in your language. Think of all the people who
don't have english as a native language that have to put up with english
words as programming language reserved words. By your argument there
should be different reserved words for each natural language, or perhaps
thousands upon thousands of reserved words from every natural language
to make sure that no one feels left out.

-- 
Sheldon Simms / sheldon@semanticedge.com

"Sheldon Simms" <sheldon@semanticedge.com> wrote in message news:9lirlg$181d$1@digitaldaemon.com...
> Im Artikel <9lhi4r$5u3$1@digitaldaemon.com> schrieb "Matt Busigin" <mbusigin@helios.spang.org.uk>:
>
> > On the subject of identifiers, I believe you should use international English, not American English.  For example, 'synchronized' should be 'synchronised'.  At least have _both_ - that's a pet peeve of mine (and would probably be a pet peeve for Americans if we made them use proper English spellings!).
>
> You are making a worse mistake by assuming that your preferred spelling
> is "international". It isn't. American spelling is taught as standard
> is many countries. In any case, it's ridiculous to gripe about this.
> As least the words are in your language. Think of all the people who
> don't have english as a native language that have to put up with english
> words as programming language reserved words. By your argument there
> should be different reserved words for each natural language, or perhaps
> thousands upon thousands of reserved words from every natural language
> to make sure that no one feels left out.

I think that the English might have a valid claim that they were speaking English first - and that it spread to a number of countries across the world prior to the advent of American English.  There really are a lot of countries that don't do English the way America does.

Personally, as a New Zealander who is a programmer, I'm used to using both interchangably (International English in everyday life, American English in software APIs).  Would it really hurt to support both spellings?

Peter.

Im Artikel <9lj2tp$1cdf$3@digitaldaemon.com> schrieb "kaffiene" <kaffiene@xtra.co.nz>:

> "Sheldon Simms" <sheldon@semanticedge.com> wrote in message news:9lirlg$181d$1@digitaldaemon.com...
>> Im Artikel <9lhi4r$5u3$1@digitaldaemon.com> schrieb "Matt Busigin" <mbusigin@helios.spang.org.uk>:
>>
>> > On the subject of identifiers, I believe you should use international English, not American English.  For example, 'synchronized' should be 'synchronised'.  At least have _both_ - that's a pet peeve of mine (and would probably be a pet peeve for Americans if we made them use proper English spellings!).
>>
>> You are making a worse mistake by assuming that your preferred spelling is "international". It isn't. American spelling is taught as standard is many countries. In any case, it's ridiculous to gripe about this. As least the words are in your language. Think of all the people who don't have english as a native language that have to put up with english words as programming language reserved words. By your argument there should be different reserved words for each natural language, or perhaps thousands upon thousands of reserved words from every natural language to make sure that no one feels left out.
> 
> I think that the English might have a valid claim that they were speaking English first - and that it spread to a number of countries across the world prior to the advent of American English.  There really are a lot of countries that don't do English the way America does.
> 
> Personally, as a New Zealander who is a programmer, I'm used to using both interchangably (International English in everyday life, American English in software APIs).  Would it really hurt to support both spellings?

My point is just that there is no international/american dichotomy. American spelling is used internationally as well.

And my point about speakers of other languages stands.

-- 
Sheldon Simms / sheldon@semanticedge.com