Re: Infinite look ahead required by C++?

"Chris F Clark" <cfc@shell01.TheWorld.com> wrote in message
> "ng2010" <ng2010@att.net> writes:
>
>> // var declaration
>> var mystruct x
>
> If you are going to go that route, follow the footsteps of a languqage
> that was designed to be (relatively} easily parseable, Pascal.
> Seriously, Pascal was designed to be almost entirely LL(1).
> Syntactically, there are relatively few goofs in Pascal. Playing
> around trying to re-invent that on your own is a recipe for failure.


Adding one keyword to solve a specific problem sounds more reasonable
than redesigning a language and compiler...


I had pretty much the same problem (where I didn't know that
'mystruct' for example was a type name and therefore the start of a
type-spec), I had to resort to some immediate name resolution (and
always have the usertypes declared in advance) instead of leaving that
until a later pass.


A related problem was with the ambiguity between:


[10]int x #an array declaration, and :
[10] #a set constructor in an expression


Sometimes, array declarations can occur in expressions (type conversions for
example), so I introduced an 'array' keyword:


a := array[]int(y)


which however is optional and only needed in rare circumstances.


> Sticking a var keyword on the beginning of C declarations, that
> declare a variable is only a poor bandage that doesn't solve many
> (much less most) of the ambiguities in C.


When C lets you write:


static const long long unsigned int x


then a 'var' keyword would get lost in the noise.. And I think C requires a
'struct' keyword when declaring a struct variable, so that is little
different from requiring 'var' when declaring a variable of a user type
(assuming 'var' would be optional otherwise).


(Although I've never quite grasped why C treats typedef names, and struct
names, separately)


> You will need a func keyword to introduce function declarations
> also. Perhaps a type keyword to introduce type declarations.


Like 'typedef'? Type and function declarations aren't as ubiquitous as
variables, and are more special, so can do with the keyword to help them
stand out.


>> I'm trying to avoid lex/parse generators. I want to do it by hand
>> and bootstrap from C/C++ until my language can compile itself.
>
> Again, wrong approach. The purpose of generators is to make your life
> easier and to prevent you from making foolish mistakes. The language
> of most generators is a variation on BNF and is relatively simple to
> learn.


It seems like that just offloads the work of a writing parser, to that
of writing the BNF (which in my projects would never work as they are
full of ambiguities). And there are still bits of code to fill in, if
my memory serves me correctly.


As BGB has said a few times, parsing is nothing compared with some of the
other bits of a compiler.


> simply make more mistakes and quite probably define an ad-hack
> language--an inconsistent language whose only definition is the source
> code used to compile it.


Point taken..


--
Bartc

Return to the comp.compilers page.
Search the comp.compilers archives again.