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.

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

> 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

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.

> 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

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
>

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.
>
>
>

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
>
>
>

"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.

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