[fpc-devel] Alternative parsers

[Marco van de Voort]

In our previous episode, Juha Manninen (gmail) said:
> > Moreover I think the goals of such project can be much easier accomplished
> > by having a C compiler that outputs (FPC) pascal source.
> 
> True. DoDi must have some idea to solve it with the frontend.

I only heard him about mapping the C frontend to FPC's backend. I had some
concerns about that, but HP answered that plausible enough (on an high
level).  This is more or less because that operates mostly on C AFTER
preprocessing.  Afaik the interoperability question is still open (or I
didn't buy the answer)

> Automatic header conversion as part of the frontend maybe?

If this was feasible, it would be here. Unless somebody really _shows_ me
otherwise, I think that what is here, is as much as we are going to get.

I personally think that fully automated C header conversion is not possible.
 
> > in the module handling (but that work can be recycled for other pascal
> > dialects that were inspired by that, like ISO Pascal too), but the main
> > problem is the lexer/parser, because M2 is case sensitive and has a
> > different block structure (which goes beyond merely being a pascal
> > dialect).
> 
> So that requires changes also to compiler internals and not only to frontend?
> Ok then.

Yes of course. But that part (unit/module handling) is already destined to
be written sooner or later. It is one of the parts that wasn't rewritten
after the 1.0.x->2.0.x transition.

The lexer/parser stuff is more about why you probably can't treat Modula2 as
yet another Pascal dialect and keep it as a configurable option in the
current parser.

And keep in mind that modula2 is about as little intrusive as they come. It
basically is Pascal, with slightly different syntax and unsigned arithmetic,
and e.g.  the whole unit system is a backport from Modula2 to pascal.

> > mess that nothing can be said about that without specification of what
> > dialect you mean.  I can only image VB here, but VB is very complex
> > internally, and the existing codebases are horribly windows specific).
> > Moreover when it finally would be production ready, VB6 would probably be
> > near extinction.
> 
> I have to agree. A frontend can't solve those.  Fortran would be the most
> realistic I guess but only few people would need it.

That is the main problem. The main people that want fortran are people
shopping for easy to use codebases. They are not interested in Fortran
themselves.

The actualy Fortran crowd is scientifically oriented and extremely
conservative, and unlikely to use a fortran compiler that is ducktaped on to
a pascal compiler.

The question is not just what is possible, but also who is going to do it
(both separately for the initial effort and maintenance/expansion)

The problem is that the only sane target (C/C++) are so different that
interoperability is a bitch, and if you "just" want a C compiler, grab gcc.
(interoperability would be the reason to add it to FPC, I don't really
expect for C users to drop gcc in droves and flock to FPC).

People constantly try to pooh-pooh these problems with workarounds ( macros,
subsets and auto conversion), but these do not fix the problem.  Moreover
some of these solutions (like auto-conversion) are Loch Ness monsters, in
the sense that quite often people say that they saw it, but somehow never in
circumstances that can be replicated :-)

If the workarounds start changing the input, and it is not essentially:

- download C code. (e.g. zlib)
- compile C part with FPC/C
- compile own program with FPC/Pascal that uses C compiled part.

then one should wonder what it is actually good for.