OpenEuphoria

Re: Preprocessors

• Posted by kbochert at copper.net Aug 25, 2002
• 526 views

-------Phoenix-Boundary-07081998-

You wrote on 8/25/02 11:51:53 AM:


>It seems that when a preprocessor provides enough inovative features,
>it reaches the level of complexity of compilers.
>
>jbrown

The more ambitious, the closer it gets.

I think the hardest part of a pre-processor is the error reporting.

My Goo preprocessor (a year old now!) added classes, slicing shorthands,
trinary expressions and variable initializations, and managed to do it
1:1 to minimize error reporting problems. Even then, I found that a
Euphoria error in my generated code was still a problem to fix,
requiring a little knowledge of why Goo generated the code it did.
By contrast, Bach has more features, better error reporting and
higher speed, and was easier to write, test and modify  besides!


I keep thinking that the only reasonable goal for a preprocessor
is to handle simple, one-to-one transformations such as:
   foo[3..]     =3D=3D> foo[3..length(foo)]
or
   append(&MyString, "txt")  =3D=3D> MyString =3D append (MyString, "text")
i.e. syntax changes.

As soon as the preprocessor tries to handle symantic features like
goto, continue, exceptions, etc. it rapidly becomes more complex
and much harder to have good error detection.

C's preprocessor is completely syntactic, as are nearly all
others. (I think - is it Dylan that has a symantic preprocessor=3F

Symantic preprocessors may or may not be as complex as
compilers, but I think compilers are better understood and therefore
easier to write.

Karl Bochert











Much more, and the preprocessor has too do most of the semantic
analysis on its own, and might just as easily output C  as Euphoria.

The hard part of the job is to generate clear and helpful error
messages, especially when your audience is used to those
of Euphoria!

Karl Bochert 

-------Phoenix-Boundary-07081998---