The language specifications look very good to me (I do mostly Java coding right now but I've also done a fair amount of C and just a tad of C++). Lets get a compiler for this thing (alpha level, beta level, whatever) to starve off all the 'vaporware' shouters that will surely come.

Michael Gaskins wrote:

> The language specifications look very good to me (I do mostly Java coding right now but I've also done a fair amount of C and just a tad of C++). Lets get a compiler for this thing (alpha level, beta level, whatever) to starve off all the 'vaporware' shouters that will surely come.

Of possibly greater importance is a language test suite, usable both for regression testing of the real compiler, and for uncovering and explaining thorny language issues by using *real* examples (rather than guesstimates of what the D language spec *really* means).

And to make such a suite useful useful, we need a tool that will recognize valid D programs, even if we can't compile them to machine code and execute them.

Is D LALR?  If so, then let's use LEX/YACC (or Flex/Bison) to whip up a quick parser that simply outputs state information (and possibly some crude C equivalents instead of machine code).  At a minimum, the parser could be a binary function that accepts text, where the return value would simply indicate parse success (a valid program).  Semantic actions could be used to handle many non-LALR language features, as well as documenting violations.

Such a tool would allow everyone to learn and write D (and develop regression suites) long before anything close to a full D compiler is ready.  It may even help if code generation is postponed until after the grammar and feature set has stabilized.

I remember writing a compiler for the VAX (yes, decades ago) for an obscure proprietary language.  Our 4 person team focused on getting the grammar parsing right first.  When we finally knew we were properly handling all the key test cases, the team then split to implement code generation, modularity, compiler options, proper error handling, and many related items.  After spending two months as a team on the parser, I was then able to write an optimized code generator on my own in a little over a month. (Well, the VAX instruction set and machine architecture was a dream to work with - the best of the CISC CPUs.)

With a known-good parser, everything else seems vastly easier.


-BobC

Michael Gaskins wrote in message <9li9i4$o6j$1@digitaldaemon.com>...
>The language specifications look very good to me (I do mostly Java coding right now but I've also done a fair amount of C and just a tad of C++). Lets get a compiler for this thing (alpha level, beta level, whatever) to starve off all the 'vaporware' shouters that will surely come.


The compiler does exist, but it is too embarassingly buggy to post right now <g>.

D is designed to be easy to parse. The semantic routines are a little trickier.

The only real trick in the parser is distinguishing a cast from a
parenthesized expression,
and a declaration from a statement.

I considered an alternate syntax for these to make them easier to parse, but it just doesn't look right. I'm too used to C, I guess. For example:

    cast(int) expr

instead of:

    (int) expr

and:

    var int foo;

instead of:

    int foo;

-Walter

Robert W. Cunningham wrote in message <3B7CB19C.D1C766B1@yahoo.com>...
>Michael Gaskins wrote:
>
>> The language specifications look very good to me (I do mostly Java coding right now but I've also done a fair amount of C and just a tad of C++). Lets get a compiler for this thing (alpha level, beta level, whatever) to starve off all the 'vaporware' shouters that will surely come.
>
>Of possibly greater importance is a language test suite, usable both for regression testing of the real compiler, and for uncovering and explaining thorny language issues by using *real* examples (rather than guesstimates
of
>what the D language spec *really* means).
>
>And to make such a suite useful useful, we need a tool that will recognize valid D programs, even if we can't compile them to machine code and execute them.
>
>Is D LALR?  If so, then let's use LEX/YACC (or Flex/Bison) to whip up a quick parser that simply outputs state information (and possibly some crude C equivalents instead of machine code).  At a minimum, the parser could be
a
>binary function that accepts text, where the return value would simply indicate parse success (a valid program).  Semantic actions could be used
to
>handle many non-LALR language features, as well as documenting violations.
>
>Such a tool would allow everyone to learn and write D (and develop regression suites) long before anything close to a full D compiler is ready.  It may even help if code generation is postponed until after the grammar and feature set has stabilized.
>
>I remember writing a compiler for the VAX (yes, decades ago) for an obscure proprietary language.  Our 4 person team focused on getting the grammar parsing right first.  When we finally knew we were properly handling all
the
>key test cases, the team then split to implement code generation, modularity, compiler options, proper error handling, and many related items.  After spending two months as a team on the parser, I was then able to write an optimized code generator on my own in a little over a month. (Well, the VAX instruction set and machine architecture was a dream to work with - the best of the CISC CPUs.)
>
>With a known-good parser, everything else seems vastly easier.
>
>
>-BobC
>
>

> 
>     cast(int) expr
> 
> instead of:
> 
>     (int) expr
> 

How about:
 <int> expr

Greater-lesser brackets are widly accepted to surrong types. This not only eases parsing for the compiler, for my eyes it also eases reading the source for humans.

Axel Kittenberger wrote:

> >
> >     cast(int) expr
> >
> > instead of:
> >
> >     (int) expr
> >
>
> How about:
>  <int> expr
>
> Greater-lesser brackets are widly accepted to surrong types. This not only eases parsing for the compiler, for my eyes it also eases reading the source for humans.

<sarcastic>Oh, yes, let's do the same mistake with angle brackets that was done in C++, angle bracket just look so great.</sarcastic>

Now, please parse for me:

    if (x < < v > <o> 3)

and compare it to

    if (x << v > <o> 3)

Oh, and what if o is a type? Is not a type?


Right, so readable :-)


Christophe

scarcasm is not good, no need to dig that out early.

>     if (x < < v > <o> 3)
x is smaller than 3 casted to o casted to v.

> and compare it to
>     if (x << v > <o> 3)
x shifter right by v is greater then 3 casted to o.

Leaving away brackets is no way where they are supposed is no way to argue languages. I could talk very wiered english too thats still has valid grammar, that doesn't make english a bad language.

We could also start to discuss what a = b+++c; yields, or if a = b++++c is
valid syntax, same with the old tangling else problem.
-

     if (x < (<v><o> 3))
is better.

and so is:
     if ((x << v) > (<o> 3))

I see this at least as good as it would be tradionally:
     if (x < ((v)(o) 3))
and
     if ((x << v) > ((o) 3))

And honestly typecasts and comperasion is not something you'll encounter every day in the same line. Normally one casts objects and compares integer types. Yes, I know there are cases where you have to compare signed with unsigned integers, there you need a typecast in the same line, but normally if you decide types right this can be avoided.

> Oh, and what if o is a type? Is not a type?

I don't understand this.

- Axel

Hey guys,

As an aside, did you know that Walter once won an 'obfuscated c' contest?

We don't want 'D' to be a language for which such contests are held<g>! -- Rajiv

Axel Kittenberger <axel@dtone.org> wrote in message news:9ll905$7vl$1@digitaldaemon.com...
> scarcasm is not good, no need to dig that out early.
>
> >     if (x < < v > <o> 3)
> x is smaller than 3 casted to o casted to v.
>
> > and compare it to
> >     if (x << v > <o> 3)
> x shifter right by v is greater then 3 casted to o.
>
> Leaving away brackets is no way where they are supposed is no way to argue languages. I could talk very wiered english too thats still has valid grammar, that doesn't make english a bad language.
>
> We could also start to discuss what a = b+++c; yields, or if a = b++++c is
> valid syntax, same with the old tangling else problem.
> -
>
>      if (x < (<v><o> 3))
> is better.
>
> and so is:
>      if ((x << v) > (<o> 3))
>
> I see this at least as good as it would be tradionally:
>      if (x < ((v)(o) 3))
> and
>      if ((x << v) > ((o) 3))
>
> And honestly typecasts and comperasion is not something you'll encounter every day in the same line. Normally one casts objects and compares
integer
> types. Yes, I know there are cases where you have to compare signed with unsigned integers, there you need a typecast in the same line, but
normally
> if you decide types right this can be avoided.
>
> > Oh, and what if o is a type? Is not a type?
>
> I don't understand this.
>
> - Axel

Rajiv Bhagwat wrote in message <9llau3$99d$1@digitaldaemon.com>...
>Hey guys,
>
>As an aside, did you know that Walter once won an 'obfuscated c' contest?


My dirty secret is out!


>We don't want 'D' to be a language for which such contests are held<g>!


As one wag once said, you can write FORTRAN in any language.

Walter wrote:
> The only real trick in the parser is distinguishing a cast from a
> parenthesized expression,
> and a declaration from a statement.
> 
> I considered an alternate syntax for these to make them easier to parse, but it just doesn't look right. I'm too used to C, I guess. For example:
> 
>     cast(int) expr
> 
> instead of:
> 
>     (int) expr
> 

This I could live with.

Is the C++ style cast of the form:

   int(expr)

difficult to parse?

> and:
> 
>     var int foo;
> 
> instead of:
> 
>     int foo;

This one hurts my C-brain a bit more. :)