View mode: basic / threaded / horizontal-split · Log in · Help
August 16, 2001
Comments
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
August 17, 2001
Re: Comments
"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
August 17, 2001
Re: Comments
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
August 17, 2001
Re: Comments
> 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
August 17, 2001
Re: Comments
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
August 17, 2001
Re: Comments
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
August 17, 2001
Re: Comments
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?)
August 17, 2001
Re: Comments
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
August 17, 2001
Re: Comments
"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.
August 17, 2001
Re: Comments
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home