www.digitalmars.com         C & C++   DMDScript  

D - Project looks very promising - Lets get a compiler out fast :)

reply "Michael Gaskins" <mbgaski clemson.edu> writes:
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.
Aug 16 2001
next sibling parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
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
Aug 16 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
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
Aug 18 2001
next sibling parent reply Axel Kittenberger <axel dtone.org> writes:
 
     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.
Aug 18 2001
parent reply Christophe de Dinechin <descubes earthlink.net> writes:
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
Aug 18 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
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
Aug 18 2001
parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
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
Aug 18 2001
parent reply "Walter" <walter digitalmars.com> writes:
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.
Aug 18 2001
parent John Fletcher <J.P.Fletcher aston.ac.uk> writes:
Walter wrote:


 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.


One of my research students wrote a FORTRAN program which wrote FORTRAN.

John
Aug 21 2001
prev sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
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. :)
Aug 18 2001
parent reply "Walter" <walter digitalmars.com> writes:
Russell Bornschlegel wrote in message <3B7EC050.A74713DA estarcion.com>...

Is the C++ style cast of the form:

   int(expr)

difficult to parse?



Yes, because the grammar is too ambiguous. A goal of D is to make parsing
independent of the symbol table. Can't do that and support C++ style casts.
Aug 18 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
The only other problem with C++ style casts is that it requires making
typedefs, without them you can't cast to int* for example.  Pascal had the
same problem.  Not a huge problem, admittedly.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:9lml51$10vj$3 digitaldaemon.com...

 Russell Bornschlegel wrote in message <3B7EC050.A74713DA estarcion.com>...

Is the C++ style cast of the form:

   int(expr)

difficult to parse?



 Yes, because the grammar is too ambiguous. A goal of D is to make parsing
 independent of the symbol table. Can't do that and support C++ style


casts.
Nov 03 2001
parent reply "Walter" <walter digitalmars.com> writes:
I'm still in a bit of a quandary about casts. Should casting be:

    (type)expression

or:

    cast(type)expression

? The latter is far easier to parse. I'm so used to the former I am
reluctant to give it up. A kludgy compromise might be allowing the former
only for types that start with a keyword, not a typedef.

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9s2cep$1ved$1 digitaldaemon.com...

 The only other problem with C++ style casts is that it requires making
 typedefs, without them you can't cast to int* for example.  Pascal had the
 same problem.  Not a huge problem, admittedly.

 Sean

 "Walter" <walter digitalmars.com> wrote in message
 news:9lml51$10vj$3 digitaldaemon.com...

 Russell Bornschlegel wrote in message




<3B7EC050.A74713DA estarcion.com>...

Is the C++ style cast of the form:

   int(expr)

difficult to parse?



 Yes, because the grammar is too ambiguous. A goal of D is to make




parsing

 independent of the symbol table. Can't do that and support C++ style


 casts.
Dec 15 2001
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9vhegn$1l01$1 digitaldaemon.com...


 I'm still in a bit of a quandary about casts. Should casting be:

     (type)expression

 or:

     cast(type)expression

 ? The latter is far easier to parse. I'm so used to the former I am
 reluctant to give it up. A kludgy compromise might be allowing the former
 only for types that start with a keyword, not a typedef.


Personally, I've found myself using the cast() form.
But the compromise you've mentioned of seems fine as
well.
Dec 16 2001
prev sibling next sibling parent reply Axel Kittenberger <axel dtone.org> writes:
Walter wrote:


 I'm still in a bit of a quandary about casts. Should casting be:
 
     (type)expression
 
 or:
 
     cast(type)expression


My I brainstorm a bit?

personally I like the:
<type> expression

Syntax, and it is easy parseable in a LALR syntax, as it requires only one 
look ahead. However I've seen people having feelings against it.

How about using the right apostrophe? Is it used it already by something 
different?
`type` expression

Well however I thing trying to see pure, type casting can best be viewed as 
a kind of function or? It gets one input value, and returns another output 
value, sometimes different as the input. Then the above expression should 
be look like this better:

cast(type, expression)

or the pascal form 
type(expression)

But types cannot normally be function paramteres, they are something 
different. I think type casting should use the same syntax as generic 
programming in the same language should do. It's the same paradigm, calling 
a function whose implementation is dependant on the type you specify.
How about then:

cast<type>(expression)

?
Dec 16 2001
parent "Pavel Minayev" <evilone omen.ru> writes:
"Axel Kittenberger" <axel dtone.org> wrote in message
news:9vhomg$1re4$1 digitaldaemon.com...

 Walter wrote:



 I'm still in a bit of a quandary about casts. Should casting be:

     (type)expression

 or:

     cast(type)expression


 My I brainstorm a bit?

 personally I like the:
 <type> expression

 Syntax, and it is easy parseable in a LALR syntax, as it requires only one
 look ahead. However I've seen people having feelings against it.


It's also hard to distinguish from normal expression containing
< and > operands.


 How about using the right apostrophe? Is it used it already by something
 different?
 `type` expression

 Well however I thing trying to see pure, type casting can best be viewed


as

 a kind of function or? It gets one input value, and returns another output
 value, sometimes different as the input. Then the above expression should
 be look like this better:

 cast(type, expression)


It doesn't seem "right" to me =)


 or the pascal form
 type(expression)


This is, IMHO, acceptable, since there's no temporaries in D,
so the syntax is unused.


 But types cannot normally be function paramteres, they are something
 different. I think type casting should use the same syntax as generic
 programming in the same language should do. It's the same paradigm,


calling

 a function whose implementation is dependant on the type you specify.
 How about then:

 cast<type>(expression)


Back to C++ days...
I just hate angle brackets!

And anyhow, what's the problem with the way it's done now?
Dec 16 2001
prev sibling next sibling parent reply la7y6nvo shamko.com writes:
"Walter" <walter digitalmars.com> writes:


 I'm still in a bit of a quandary about casts. Should casting be:
 
     (type)expression
 
 or:
 
     cast(type)expression
 
 ? The latter is far easier to parse. I'm so used to the former I am
 reluctant to give it up. A kludgy compromise might be allowing the former
 only for types that start with a keyword, not a typedef.


Please let D abandon the abominable syntax that C uses for casts.
I know, I know, people are used to it, but this is one case where
compatibility should be given second place to forward progress.

On the compromise idea - If a new syntax is introduced then the old
syntax should be eliminated.  C++ made the mistake of adding a new
syntax for casting while also retaining the old, and that's been
a source of confusion.  Also, having two forms which are sometimes
but not always interchangeable is asking for trouble.  Again, I
know about the compatibility arguments, but let's try to make some
forward progress with D in this area.  

As for what syntax to use..  One thing about C that's always seemed
rather poorly thought out is the funny way that prefix operators and
postfix operators interact.  (Incidentally, C++ retains these problems
and makes them worse with a prefix 'new' operator.  But I digress.)
If one thinks of casting as a kind of operator - admittedly one that
doesn't usually execute any instructions - I think it makes more sense
to put the cast operator after the operand, as for example

    operand.as(type)

or if necessary

    (expression).as(type)

If the syntax for expressions were expanded to include a syntax for
types, with semantics allowing some run-time representation for values
of type Type (which seems like a good idea independent of casting),
then no special syntax is needed for casting.  Indeed if this were so
then the only difference between the casting 'as' operators and
regular (method) functions is that 'as' is overloaded on return type.

Note how nicely this functional form cascades:

    x[i].as(Window).redraw()

Compare that to:

    (cast(Window) x[i]).redraw()

Perhaps it's my many years of using object-oriented programming
languages, but the first form seems much easier to understand
than the second.

Let me add a couple of disclaimers as anti-flame insurance :)

    (1) There is a fundamental and important difference between the notion
    of type and the notion of class.  The comments above gloss over that
    distinction.  It's important that some implementation along these
    lines not do that.

    (2) C uses the same syntax for "casting" (like changing one pointer
    type into another with no bit changes) and "conversion" (changing an
    integer value into a floating point value, bits definitely change).
    It seems obvious that these notions, although related, are different
    operations and should have distinct syntaxes.  Or at least different
    operator names.

Hopefully the comments and suggestions made above find some resonance
amongst the readers of the newsgroup and potential users of D.
Dec 16 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
 
     (2) C uses the same syntax for "casting" (like changing one pointer
     type into another with no bit changes) and "conversion" (changing an
     integer value into a floating point value, bits definitely change).
     It seems obvious that these notions, although related, are different
     operations and should have distinct syntaxes.  Or at least different
     operator names.


True, in fact there are 4 casts I know of, conversion cast, upcast, 
downcast and reinterpret cast. C++ decides in after the context what to use 
that can be very error prone. Where a const cast is only a finer issue I do 
not count as a seperate cast form.

class Borg b* = (Corg) a*;

Can have different code results dependant that you included #include 
"Corg.h" and defined the class with it. Took me once several days to find a 
bug, where the code did an upcast (pointer should decrement by casting) but 
the class defintion was not included in that file, so he did a reinterpred 
cast, pointing at nonsense at the end.

- Axel
Dec 16 2001
parent "Walter" <walter digitalmars.com> writes:
"Axel Kittenberger" <axel dtone.org> wrote in message
news:9vj699$2l18$1 digitaldaemon.com...

 True, in fact there are 4 casts I know of, conversion cast, upcast,
 downcast and reinterpret cast. C++ decides in after the context what to


use

 that can be very error prone. Where a const cast is only a finer issue I


do

 not count as a seperate cast form.

 class Borg b* = (Corg) a*;

 Can have different code results dependant that you included #include
 "Corg.h" and defined the class with it. Took me once several days to find


a

 bug, where the code did an upcast (pointer should decrement by casting)


but

 the class defintion was not included in that file, so he did a reinterpred
 cast, pointing at nonsense at the end.


D shouldn't suffer from that problem, as there shouldn't be any forward
referenced class names.

D will just use one cast form, not the 4 different ones. (There is no const
cast in D, because there is no const type modifier.) To do a type paint,
cast it to void* first and then cast the result.
Dec 16 2001
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9vhegn$1l01$1 digitaldaemon.com...

 I'm still in a bit of a quandary about casts. Should casting be:

     (type)expression

 or:

     cast(type)expression

 ? The latter is far easier to parse. I'm so used to the former I am
 reluctant to give it up. A kludgy compromise might be allowing the former
 only for types that start with a keyword, not a typedef.


There's a related issue for declarations, is:

    a * b;

a declaration or an expression? Currently, the ambiguity is resolved with
the rule "if it will parse as a declaration, it is a declaration". I'm not
particularly thrilled with that, as it requires lookahead in the parser. One
solution is to require a "var" keyword in front of declarations. But to my
eyes, typing all those var's in is annoying:

    void func()
    {    var int i,j;
         var X* y;
        ....
    }
Dec 16 2001
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9vj9l0$2n1j$2 digitaldaemon.com...

 There's a related issue for declarations, is:

     a * b;

 a declaration or an expression? Currently, the ambiguity is resolved with
 the rule "if it will parse as a declaration, it is a declaration". I'm not
 particularly thrilled with that, as it requires lookahead in the parser.


One

If "a" is type in current scope, it's a declaration;
If "a" is something else, it's an expression, so:

    class Apple { }

    int main()
    {
        Apple * x;    // x is pointer to apple
        int Apple;
        Apple * y;    // multiply Apple by y
    }
Dec 16 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:9vk5gl$4hk$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:9vj9l0$2n1j$2 digitaldaemon.com...

 There's a related issue for declarations, is:

     a * b;

 a declaration or an expression? Currently, the ambiguity is resolved




with

 the rule "if it will parse as a declaration, it is a declaration". I'm




not

 particularly thrilled with that, as it requires lookahead in the parser.


 One

 If "a" is type in current scope, it's a declaration;
 If "a" is something else, it's an expression, so:

     class Apple { }

     int main()
     {
         Apple * x;    // x is pointer to apple
         int Apple;
         Apple * y;    // multiply Apple by y
     }


The trouble there is I am trying to separate the syntactic from the
semantic. Recognizing that an identifier is a type requires semantic
analysis (i.e. building a symbol table). The separation of the two functions
will make it easy to write things like source code formatters and analyzers.
Dec 17 2001
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
I guess you can't have everything.  Either that or you have the coder
specify 'var' in front of all declarations.  I for one wouldn't mind that,
since it clears up so many other things.  I did just that in fact when
programming Pascal for all those years.  I was far more upset about having
to type 'begin' and 'end' and 'then' and 'do' all over the place than I ever
was about telling the compiler I'm about to do a variable declaration.

If you ask me, anyone writing a source code analyzer or formatter can easily
check for variable declarations and typedefs so it knows what symbols are
what at current scope.  It doesn't even really need to keep track of the
exact type, just that a variable or type has been declared there with that
name.  Source beautifiers builtin to the IDE is something I'd really love to
see, so if doing that means the IDE has to keep track of declarations, well,
that's nothing VB or VC hasn't been doing for many years now already.  Hell,
Instant Pascal way back on the Apple II did that.  So did Think Pascal on
the Mac.  Then again Pascal used the var keyword.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:9vk9nj$8eq$3 digitaldaemon.com...

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:9vk5gl$4hk$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:9vj9l0$2n1j$2 digitaldaemon.com...

 There's a related issue for declarations, is:

     a * b;

 a declaration or an expression? Currently, the ambiguity is resolved




 with

 the rule "if it will parse as a declaration, it is a declaration". I'm




 not

 particularly thrilled with that, as it requires lookahead in the






parser.

 One

 If "a" is type in current scope, it's a declaration;
 If "a" is something else, it's an expression, so:

     class Apple { }

     int main()
     {
         Apple * x;    // x is pointer to apple
         int Apple;
         Apple * y;    // multiply Apple by y
     }


 The trouble there is I am trying to separate the syntactic from the
 semantic. Recognizing that an identifier is a type requires semantic
 analysis (i.e. building a symbol table). The separation of the two


functions

 will make it easy to write things like source code formatters and


analyzers.
Dec 17 2001
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9vke8m$amq$1 digitaldaemon.com...

 I guess you can't have everything.  Either that or you have the coder
 specify 'var' in front of all declarations.  I for one wouldn't mind that,
 since it clears up so many other things.  I did just that in fact when
 programming Pascal for all those years.  I was far more upset about having
 to type 'begin' and 'end' and 'then' and 'do' all over the place than I


ever

 was about telling the compiler I'm about to do a variable declaration.


Having the "if it parses as a declaration, it is a declaration" rule does
seem to work.


 If you ask me, anyone writing a source code analyzer or formatter can


easily

 check for variable declarations and typedefs so it knows what symbols are
 what at current scope.  It doesn't even really need to keep track of the
 exact type, just that a variable or type has been declared there with that
 name.  Source beautifiers builtin to the IDE is something I'd really love


to

 see, so if doing that means the IDE has to keep track of declarations,


well,

 that's nothing VB or VC hasn't been doing for many years now already.


Hell,

 Instant Pascal way back on the Apple II did that.  So did Think Pascal on
 the Mac.  Then again Pascal used the var keyword.


VC has had millions of man-hours of development in it - and with access to a
full blown compiler, you can tell if an identifier is a type or not. To do
so in D, you'd have to find all the imports, parse them all, etc., just like
in a full blown compiler to be able to tell with certainty if it's a type or
not. You can fake it and work 93% of the time, but getting that last 7%
right requires the whole thing. Most C beautifers that aren't hooked into a
full blown compiler get it right about 93% of the time. Heck, many of them
don't even handle the \ line splice completely correctly.

With D, the idea is it can be gotten 100% correct with only a modest effort
by one person.
Dec 17 2001
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9vk9nj$8eq$3 digitaldaemon.com...


 The trouble there is I am trying to separate the syntactic from the
 semantic. Recognizing that an identifier is a type requires semantic
 analysis (i.e. building a symbol table). The separation of the two


functions

 will make it easy to write things like source code formatters and


analyzers.

Yes, I see. Personally, I woudln't mind typing "var" here and
there, got quite used to it in Pascal and then UnrealScript...
Dec 17 2001
prev sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Pavel Minayev" <evilone omen.ru> ha scritto nel messaggio
news:9vk5gl$4hk$1 digitaldaemon.com...

 If "a" is type in current scope, it's a declaration;
 If "a" is something else, it's an expression, so:

     class Apple { }

     int main()
     {
         Apple * x;    // x is pointer to apple
         int Apple;
         Apple * y;    // multiply Apple by y
     }


Please, save me from this! ;-)
Dec 17 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:9vkbg9$9d5$1 digitaldaemon.com...

 "Pavel Minayev" <evilone omen.ru> ha scritto nel messaggio
 news:9vk5gl$4hk$1 digitaldaemon.com...

 If "a" is type in current scope, it's a declaration;
 If "a" is something else, it's an expression, so:

     class Apple { }

     int main()
     {
         Apple * x;    // x is pointer to apple
         int Apple;
         Apple * y;    // multiply Apple by y
     }


 Please, save me from this! ;-)


Currently, D issues the following error message for the Apple*y:

symbol 'Apple' is not a type
Dec 17 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
Walter wrote:


 
 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:9vkbg9$9d5$1 digitaldaemon.com...

 "Pavel Minayev" <evilone omen.ru> ha scritto nel messaggio
 news:9vk5gl$4hk$1 digitaldaemon.com...

 If "a" is type in current scope, it's a declaration;
 If "a" is something else, it's an expression, so:

     class Apple { }

     int main()
     {
         Apple * x;    // x is pointer to apple
         int Apple;






In my opinion 'int Apple' should better raise an error if Apple is defined 
as type. Shadowing is nice in theory, and looks cool in compiler 
implementation, but is bad in practice, as it is error prone for the 
programmer who easy mismatches a variable/type when it's understanding 
differes from context.
Dec 17 2001
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Hear, hear.

Axel Kittenberger wrote:


 Walter wrote:


 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:9vkbg9$9d5$1 digitaldaemon.com...

 "Pavel Minayev" <evilone omen.ru> ha scritto nel messaggio
 news:9vk5gl$4hk$1 digitaldaemon.com...

 If "a" is type in current scope, it's a declaration;
 If "a" is something else, it's an expression, so:

     class Apple { }

     int main()
     {
         Apple * x;    // x is pointer to apple
         int Apple;






 In my opinion 'int Apple' should better raise an error if Apple is defined
 as type. Shadowing is nice in theory, and looks cool in compiler
 implementation, but is bad in practice, as it is error prone for the
 programmer who easy mismatches a variable/type when it's understanding
 differes from context.


--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Dec 17 2001
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Think, Russ!  Think, then speak!

I do want to say that I agree with Axel that "shadowing" is not a good
thing...maybe even a Bad Thing.  But now that I've thought about it, I've
realized that it still doesn't solve the parser problem...the parser has no way
of knowing if it's a valid statement or not.

For that, what about just making no-effect lines to be syntax errors (except for
null statements)?  Then any thing that *could* be a declaration (regardless of
context) *must* be one.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Dec 17 2001
next sibling parent "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C1E6A51.E60BF91A deming-os.org...

 For that, what about just making no-effect lines to be syntax errors


(except for

 null statements)?  Then any thing that *could* be a declaration


(regardless of

 context) *must* be one.


Hmm. That is a good thought. The no effect error is an irritant in C++, as I
use macros that depend on the compiler optimizing away no effect
expressions, as in:

    #define printf 1 || printf

and:

    #define assert(e)    0

but in D these become irrelevant, so maybe no effect errors are practical.
Dec 17 2001
prev sibling parent reply Axel Kittenberger <axel dtone.org> writes:
Russ Lewis wrote:


 Think, Russ!  Think, then speak!
 
 I do want to say that I agree with Axel that "shadowing" is not a good
 thing...maybe even a Bad Thing.  But now that I've thought about it, I've
 realized that it still doesn't solve the parser problem...the parser has
 no way of knowing if it's a valid statement or not.
 
 For that, what about just making no-effect lines to be syntax errors
 (except for
 null statements)?  Then any thing that *could* be a declaration
 (regardless of context) *must* be one.


Not necessarly true, the lexer can do type lookups, and return differnt 
tokens as i.e. mine did. That how I solved the grammatical problem how to 
differentiate ie.

asdf[2][2] a;
asdf[2][2] = a;

Is "asdf" meant to be the type (declaring an 2x2 array of it) or a 
identifier accessing the 2/2th element of it? Yes, it is technically 
distinguishable but not with 1 token lookahead, or with any definitive size 
of lookahead. To distingish "asdf" between type or variable you need 3 * 
field dimenions look ahead, where the dimension is normally unlimited.

- Axel
Dec 18 2001
parent "Walter" <walter digitalmars.com> writes:
"Axel Kittenberger" <axel dtone.org> wrote in message
news:9voc5a$2vrg$1 digitaldaemon.com...

 Not necessarly true, the lexer can do type lookups, and return differnt
 tokens as i.e. mine did. That how I solved the grammatical problem how to
 differentiate ie.

 asdf[2][2] a;
 asdf[2][2] = a;

 Is "asdf" meant to be the type (declaring an 2x2 array of it) or a
 identifier accessing the 2/2th element of it? Yes, it is technically
 distinguishable but not with 1 token lookahead, or with any definitive


size

 of lookahead. To distingish "asdf" between type or variable you need 3 *
 field dimenions look ahead, where the dimension is normally unlimited.

 - Axel


That's why I wound up implementing arbitrary lookahead. -Walter
Dec 18 2001
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Axel Kittenberger" <axel dtone.org> wrote in message
news:9vlm2o$1389$1 digitaldaemon.com...


 In my opinion 'int Apple' should better raise an error if Apple is defined
 as type. Shadowing is nice in theory, and looks cool in compiler
 implementation, but is bad in practice, as it is error prone for the
 programmer who easy mismatches a variable/type when it's understanding
 differes from context.


This might be true if Apple was a local class. But what if it
resides in other module? In this case, disallowing shadowing
would result in breaking code in one module when other gets
new type in it - definitely unacceptable...
Dec 17 2001
prev sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:9vj9l0$2n1j$2 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:9vhegn$1l01$1 digitaldaemon.com...

 I'm still in a bit of a quandary about casts. Should casting be:

     (type)expression

 or:

     cast(type)expression

 ? The latter is far easier to parse. I'm so used to the former I am
 reluctant to give it up. A kludgy compromise might be allowing the




former

 only for types that start with a keyword, not a typedef.




I prefer the keyword way. It's always easier to find a cast in a
million-operand expression
(like one of my co-workers does ever and ever) if the editor highlight the
keyword in the
middle of it.
As for the syntax, I once thougth about it for days, without finding a good
solution.
I think the type should be separated from the expression for clearity.
So (type)cast(expression) is better for me (though ugly...), or
cast[type](expression) or



 There's a related issue for declarations, is:

     a * b;

 a declaration or an expression? Currently, the ambiguity is resolved with
 the rule "if it will parse as a declaration, it is a declaration". I'm not
 particularly thrilled with that, as it requires lookahead in the parser.


One

 solution is to require a "var" keyword in front of declarations. But to my
 eyes, typing all those var's in is annoying:

     void func()
     {    var int i,j;
          var X* y;
         ....
     }


This is another thing I always thought of. Again, I found no better way.
The fact is that typing 'var' or something at every declaration is abig
waste of
typing. But:

var {
    int i;
    X* j;
}                // <-- this should not limit the scope :-(

i : int;
j : X*;                // good ole Pascal! But
a : int = 6 * K;   // where's the initializer? after the type :-(



 An operator is not always better than a keyword :-(

Anything anyone?
Dec 17 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
I just thought of something.  Yes, typing var is kinda annoying.  But how
about if one could type the keyword 'var' fairly infrequently, such as:

var:
   int a;
   int b;
   Foo myfoo;

Or perhaps:

var
{
   int a;
   int b;
   Foo myfoo;
}

Or even perhaps this (I think I like this one best):

var int a, int b, Foo myfoo; // can declare multiple vars of different types
with one var keyword

or

var int a, b, Foo myfoo, c; // b is also an int, but myfoo and c are both
Foo's

Whaddya think?  Maybe we could subsitute 'public' or 'private' for the 'var'
keyword instead?

public  // statements can't go inside public blocks.
{
  int a, b;
  Foo myfoo;
}

public:  // begin a public declara
  int i, j;
for (i=0; i<5; ++i)   // this statement terminates the previous public
section.  However here we run into the original problem again.  Perhaps
disallow the 'label:' style attribute format?
{
   j += i;
}
public:
  int c;

Sean


 There's a related issue for declarations, is:

     a * b;

 a declaration or an expression? Currently, the ambiguity is resolved




with

 the rule "if it will parse as a declaration, it is a declaration". I'm




not

 particularly thrilled with that, as it requires lookahead in the parser.


 One

 solution is to require a "var" keyword in front of declarations. But to




my

 eyes, typing all those var's in is annoying:

     void func()
     {    var int i,j;
          var X* y;
         ....
     }


 This is another thing I always thought of. Again, I found no better way.
 The fact is that typing 'var' or something at every declaration is abig
 waste of
 typing. But:

 var {
     int i;
     X* j;
 }                // <-- this should not limit the scope :-(

 i : int;
 j : X*;                // good ole Pascal! But
 a : int = 6 * K;   // where's the initializer? after the type :-(



  An operator is not always better than a keyword :-(

 Anything anyone?
Dec 17 2001
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9vkeno$b0s$1 digitaldaemon.com...


 Or perhaps:

 var
 {
    int a;
    int b;
    Foo myfoo;
 }


Sounds good.


 Or even perhaps this (I think I like this one best):

 var int a, int b, Foo myfoo; // can declare multiple vars of different


types

 with one var keyword

 or

 var int a, b, Foo myfoo, c; // b is also an int, but myfoo and c are both
 Foo's


Yeah... looks somewhat like VB.NET declarations, but I like
the idea. And should have no problem being parsed.


 Whaddya think?  Maybe we could subsitute 'public' or 'private' for the


'var'

 keyword instead?


"local"?
Dec 17 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
It's an intriguing idea. The : version won't work, though, as you'd need
some other keyword to turn it off when the statements begin.

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9vkeno$b0s$1 digitaldaemon.com...

 I just thought of something.  Yes, typing var is kinda annoying.  But how
 about if one could type the keyword 'var' fairly infrequently, such as:

 var:
    int a;
    int b;
    Foo myfoo;

 Or perhaps:

 var
 {
    int a;
    int b;
    Foo myfoo;
 }

 Or even perhaps this (I think I like this one best):

 var int a, int b, Foo myfoo; // can declare multiple vars of different


types

 with one var keyword

 or

 var int a, b, Foo myfoo, c; // b is also an int, but myfoo and c are both
 Foo's

 Whaddya think?  Maybe we could subsitute 'public' or 'private' for the


'var'

 keyword instead?

 public  // statements can't go inside public blocks.
 {
   int a, b;
   Foo myfoo;
 }

 public:  // begin a public declara
   int i, j;
 for (i=0; i<5; ++i)   // this statement terminates the previous public
 section.  However here we run into the original problem again.  Perhaps
 disallow the 'label:' style attribute format?
 {
    j += i;
 }
 public:
   int c;

 Sean


 There's a related issue for declarations, is:

     a * b;

 a declaration or an expression? Currently, the ambiguity is resolved




 with

 the rule "if it will parse as a declaration, it is a declaration". I'm




 not

 particularly thrilled with that, as it requires lookahead in the






parser.

 One

 solution is to require a "var" keyword in front of declarations. But






to

 my

 eyes, typing all those var's in is annoying:

     void func()
     {    var int i,j;
          var X* y;
         ....
     }


 This is another thing I always thought of. Again, I found no better way.
 The fact is that typing 'var' or something at every declaration is abig
 waste of
 typing. But:

 var {
     int i;
     X* j;
 }                // <-- this should not limit the scope :-(

 i : int;
 j : X*;                // good ole Pascal! But
 a : int = 6 * K;   // where's the initializer? after the type :-(



  An operator is not always better than a keyword :-(

 Anything anyone?
Dec 17 2001
prev sibling next sibling parent a <a b.c> writes:
Walter wrote:

 
 I'm still in a bit of a quandary about casts. Should casting be:
 
     (type)expression
 
 or:
 
     cast(type)expression
 
 ? The latter is far easier to parse. I'm so used to the former I am
 reluctant to give it up. A kludgy compromise might be allowing the former
 only for types that start with a keyword, not a typedef.


	If you ever allow any form of generic programming (templates, etc.)
this could come back and haunt you.  Also, it may cause unnecessary
breakage if some one switches code from using int to some FOO_t sort of
datatype.  You've gone to such extremes to do things one way (at least
in the first release) that is seems odd to have two ways for this.  
	I don't like the way the second form looks like a function call
followed by an expression, but I can't give a good justification for the
identifier in parens followed by an expression either.  Go with the cast
keyword and keep it clean.

Dan
Dec 16 2001
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:


 I'm still in a bit of a quandary about casts. Should casting be:
 
     (type)expression
 
 or:
 
     cast(type)expression
 
...


Casts are one of my least liked features of C and C++.  Better 
is a language design that, to the greatest extent possible, 
eliminates the need for casts.  Still, given the occasional 
need, I prefer the form:
      cast(type, expression)
Or even:
      cast("type", expression)
though that seems a bit strange.  But so does the idea of 
passing a type as an argument (unless the language should be 
extended to make that a "normal" activity).  The thing that 
bothers me about it is that in this expression the type appears 
to be a parameter, but normally types aren't allowed to be 
parameters, and this feels ... unnatural.
Jan 02 2002
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Charles Hixson wrote:


 Walter wrote:
 

 I'm still in a bit of a quandary about casts. Should casting be:

     (type)expression

 or:

     cast(type)expression

 ...





On reading other posts I encountered the proposal to use the syntax:
expression.as(type)

This syntax would be quite clear, but seems to be problematic as 
it would require that a method be allowed to return a variable 
type, e.g.:
     (e.as(int) < e.as(Point))
clearly this is somewhat problematical.  OTOH, this same problem 
is exhibited when one examines an alternate syntax, e.g.:
     (cast (int, e) < cast (Point, e) )
but I suppose that cast may more clearly be considered a 
"special form".  I dislike special forms, but perhaps they are 
necessary unless type is a "first class" entity in the language.

Now clearly either of the examples that I used should cause an 
error (the types int and Point being incommensurate), and this 
would be true no matter what the syntax.  The inconsistency 
arises because one can usually depend on methods and functions 
to return one particular type (or at least a descendant of some 
particular type).  So it "feels wrong" to have the syntax used 
in a contrary manner.

The "cleanest way" around this that occurs to me is to eliminate 
the cast operation, and require the creation of a union for each 
dually accessed entity.  But for this to be acceptable the 
frequency with which a cast had to be used would need to be 
quite low.
Jan 02 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Charles Hixson" <charleshixsn earthlink.net> wrote in message
news:3C335780.6070609 earthlink.net...


 This syntax would be quite clear, but seems to be problematic as
 it would require that a method be allowed to return a variable
 type, e.g.:
      (e.as(int) < e.as(Point))


I don't see any problem e.as(int) returns a value of type int.
e.as(Point) returns a value of type Point. Of course, as() is
a built-in method then.


 The "cleanest way" around this that occurs to me is to eliminate
 the cast operation, and require the creation of a union for each
 dually accessed entity.  But for this to be acceptable the
 frequency with which a cast had to be used would need to be
 quite low.


Man have you ever tried to code staight WinAPI programs like that?
Besides, D (as I understand it) is not a "cleanest" language -
it's a _practical_ language. Which means that it tries to make
our live easier rather than "cleaner" (the latter is important as
well, of course!). Forbidding casts is definitely not the right
step in this direction...
Jan 02 2002
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 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.


If it's at all possible, I'd recommend making D have an LL(k) grammar for
some small k, as this will vastly simplify the parser needed and allow alot
more tools to manipulate D code.  Please don't force people to use LEX/YACC
to parse D.  My script languages have always been LL(2) or LL(1) and I can
get away with coding the parser by hand.  I think Antlr generates LL(k)
parsers too.

Sean
Nov 03 2001
next sibling parent reply Axel Kittenberger <axel dtone.org> writes:
 If it's at all possible, I'd recommend making D have an LL(k) grammar for
 some small k, as this will vastly simplify the parser needed and allow
 alot
 more tools to manipulate D code.  Please don't force people to use
 LEX/YACC
 to parse D.  My script languages have always been LL(2) or LL(1) and I can
 get away with coding the parser by hand.  I think Antlr generates LL(k)
 parsers too.


Do you know any OpenSource LL(n) parser generators for C?

- Axel
-- 
|D) http://www.dtone.org
Nov 04 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
Antlr is evidently Public Domain:

http://www.antlr.org/rights.html

Sean

"Axel Kittenberger" <axel dtone.org> wrote in message
news:9s5d02$11j9$1 digitaldaemon.com...

 If it's at all possible, I'd recommend making D have an LL(k) grammar




for

 some small k, as this will vastly simplify the parser needed and allow
 alot
 more tools to manipulate D code.  Please don't force people to use
 LEX/YACC
 to parse D.  My script languages have always been LL(2) or LL(1) and I




can

 get away with coding the parser by hand.  I think Antlr generates LL(k)
 parsers too.


 Do you know any OpenSource LL(n) parser generators for C?

 - Axel
 --
 |D) http://www.dtone.org
Nov 05 2001
parent brucedickey micron.com writes:
FYI:

My favorite parser-generator is ProGrammar from http://www.programmar.com/. It's
not open source or free, but it is inexpensive, LL(n), and can examine the 
parse tree in productions, making it a linear bounded automata! Alas, it does
not generate source, but a proprietary grammar file. You have to link to a
supplied .lib or use the ActiveX. Currently available for Windows, but I have an
alpha for Linux that works fine. This one builds a parse tree and provides an
API to walk it and extract data. Its for C/C++, VB, Delphi.

I've used an LALR parser-generater in the past. I would never consider using
Bison or anything that's not LL(n) again.

Bruce

In article <9s6s97$2bem$1 digitaldaemon.com>, Sean L. Palmer says...

Antlr is evidently Public Domain:

http://www.antlr.org/rights.html

Sean

"Axel Kittenberger" <axel dtone.org> wrote in message
news:9s5d02$11j9$1 digitaldaemon.com...

 If it's at all possible, I'd recommend making D have an LL(k) grammar




for

 some small k, as this will vastly simplify the parser needed and allow
 alot
 more tools to manipulate D code.  Please don't force people to use
 LEX/YACC
 to parse D.  My script languages have always been LL(2) or LL(1) and I




can

 get away with coding the parser by hand.  I think Antlr generates LL(k)
 parsers too.


 Do you know any OpenSource LL(n) parser generators for C?

 - Axel
 --
 |D) http://www.dtone.org
Jul 18 2002
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
I can never remember the definitions of those grammars. The current D
parser, however, is pretty simple and is implemented as recursive descent. I
have little use for LEX/YACC. The code output always seems to require a
little hand editting, and then automating the build process doesn't work.

Lexers are so simple anyway I can't see a reason to use LEX.


"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9s2c77$1v6e$1 digitaldaemon.com...

 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.

 If it's at all possible, I'd recommend making D have an LL(k) grammar for
 some small k, as this will vastly simplify the parser needed and allow


alot

 more tools to manipulate D code.  Please don't force people to use


LEX/YACC

 to parse D.  My script languages have always been LL(2) or LL(1) and I can
 get away with coding the parser by hand.  I think Antlr generates LL(k)
 parsers too.

 Sean
Dec 15 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
Walter wrote:


 I can never remember the definitions of those grammars. The current D
 parser, however, is pretty simple and is implemented as recursive descent.
 I have little use for LEX/YACC. The code output always seems to require a
 little hand editting, and then automating the build process doesn't work.


Well the today active GNU projects are called "flex" and "bison". Bison 
requires hand editting? Thats not true in my eyes. First primary bison 
creates only the parser tables, not much more not much less. If you want to 
make changes in the parser, you can change the bison.simple template. Once 
for all. There are some limits in bison, as it doesn't allow you to specify 
how the actions are coded, which is interesting if you are doing non-C 
parsers.

However I agree that hand writing a parser can have it's advantages. It's 
only too complicated for a small brain like mine :o) I personally never got 
unary operators right this way, the miny languages I once wrote the parser 
by hand quickly came out of my control, while bison parsers seems to be 
pretty easy you got it, however sometimes configuring out how to resolve 
some shift/reduce conflicuts can be as tedious.
 

 Lexers are so simple anyway I can't see a reason to use LEX.


I totally agree on that. However it personally confuses me somewhat why 
there are all two different tools for spelling and for grammar, after all 
it is in principle the same or? Only once your tokens are the alphabet and 
once your tokens are the words outputed by the lexer grammar.

- Axel
Dec 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Axel Kittenberger" <axel dtone.org> wrote in message
news:9vho6a$1rdg$1 digitaldaemon.com...

 Walter wrote:

 I can never remember the definitions of those grammars. The current D
 parser, however, is pretty simple and is implemented as recursive




descent.

 I have little use for LEX/YACC. The code output always seems to require




a

 little hand editting, and then automating the build process doesn't




work.

 Well the today active GNU projects are called "flex" and "bison". Bison
 requires hand editting? Thats not true in my eyes. First primary bison
 creates only the parser tables, not much more not much less. If you want


to

 make changes in the parser, you can change the bison.simple template. Once
 for all. There are some limits in bison, as it doesn't allow you to


specify

 how the actions are coded, which is interesting if you are doing non-C
 parsers.


My experience with GNU bison under Win32 is the output generated many
warnings from the compiler. The port of it to Win32 was incomplete. I didn't
want to rely on a decent port of bison existing on each platform I wanted to
port the product to. Even worse, in the end it didn't save any time.

Ok, so I'm not remotely a bison expert, and perhaps these are non-issues to
someone who has taken the time to thoroughly learn it.


 However I agree that hand writing a parser can have it's advantages. It's
 only too complicated for a small brain like mine :o) I personally never


got

 unary operators right this way, the miny languages I once wrote the parser
 by hand quickly came out of my control, while bison parsers seems to be
 pretty easy you got it, however sometimes configuring out how to resolve
 some shift/reduce conflicuts can be as tedious.


A hand-tuned parser can be very fast as well <g>.



 Lexers are so simple anyway I can't see a reason to use LEX.


 I totally agree on that. However it personally confuses me somewhat why
 there are all two different tools for spelling and for grammar, after all
 it is in principle the same or? Only once your tokens are the alphabet and
 once your tokens are the words outputed by the lexer grammar.


In principle they are the same, in practice not. You're not really after a
data graph being built by the lexer, just a token stream. Whereas with a
parser, a syntax graph is the desired result.

Also, despite what compiler textbooks imply, lexing and parsing are only
minor parts of a compiler. The real work is in the semantic analysis,
optimization, and code generation. For example, the lexer in D is 1400 lines
and the parser is 2600. Of course, the goal was to make them simple <g>.
Dec 16 2001
parent Axel Kittenberger <axel dtone.org> writes:
Walter wrote:


 My experience with GNU bison under Win32 is the output generated many
 warnings from the compiler. The port of it to Win32 was incomplete. I
 didn't want to rely on a decent port of bison existing on each platform I
 wanted to port the product to. Even worse, in the end it didn't save any
 time.
 
 Ok, so I'm not remotely a bison expert, and perhaps these are non-issues
 to someone who has taken the time to thoroughly learn it.


I had no problems whatever compiling and running bison with MSVC++ (back at 
the times I still have used it)

- Axel
Dec 16 2001
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"Sean L. Palmer" wrote:


 If it's at all possible, I'd recommend making D have an LL(k) grammar for
 some small k, as this will vastly simplify the parser needed and allow alot
 more tools to manipulate D code.  Please don't force people to use LEX/YACC
 to parse D.  My script languages have always been LL(2) or LL(1) and I can
 get away with coding the parser by hand.  I think Antlr generates LL(k)
 parsers too.


I don't think that LL(k) is possible (without hacks).  The problem is the
following:

    <identifier> ****...*** <identifier>

Note that there could be any number of *'s.  At this point, a parser CANNOT
determine how to parse it.  Is it the beginning of a declaration, or it is an
expression?  If it is a type, then it should be parsed as:
    (((((...((<identifier> *) *) ... *) *) *) *) *) <identifier>
but if it is an expression, then the first * is a multiplication, and the rest
are dereferencing operators:
    ( <identifier> * (* (* (* ... (* (* <identifier> ))...))))

Obviously, it is legal for that string of *'s to be arbitrarily long.  Thus, in
order to write an LL(k) parser, you have to parse a rule that matches an
arbitrarily long string of *'s, and then use that either in an expression or a
declaration.  It's conceivable, but ugly.

I proposed an alternate declaration syntax (move the *'s to the left) that would
eliminate this problem.  I think that it might make D LALR(2)...

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jul 22 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
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>.
Aug 18 2001