|Are there "compiler generators"? email@example.com (Roger L Costello) (2022-05-28)|
|Re: Are there "compiler generators"? firstname.lastname@example.org (Thomas Koenig) (2022-05-29)|
|Re: Are there "compiler generators"? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2022-05-30)|
|Re: Are there "compiler generators"? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2022-05-31)|
|Re: Are there "compiler generators"? email@example.com (gah4) (2022-05-31)|
|RE: Are there compiler generators? firstname.lastname@example.org (Christopher F Clark) (2022-06-01)|
|From:||Christopher F Clark <email@example.com>|
|Date:||Wed, 1 Jun 2022 14:07:46 +0300|
|References:||22-05-054 22-05-058 22-05-063 22-05-065 22-05-066|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="18088"; mail-complaints-to="firstname.lastname@example.org"|
|Posted-Date:||01 Jun 2022 13:17:41 EDT|
Although there are many wonderful examples in replies already. I want
to mention the Eli "system"
It was (is) an attempt to do exactly that. It did so by cobbling
together different tools that different parts of a compiler. One in
particular is worth mentioning (Oil) which handled static type systems
and which types were compatible and when coercions were applicable. I
never found the overall system to be that usable because it didn't
really unify the tools to work well together, so that the notations
tended to stay divergent.
In fact, that is partially why in our (Compiler Resources) version of
Yacc++ we integrated the lexer and used Yacc-like notation for it. We
actually did it, because using one notation simply makes sense, but
seeing a tool which used multiple non-integrated notations simply
reinforced that opinion.
But, the main point is that compilers are a big area with lots of
little parts, some of them have tools and others don't. More
importantly, much of the development in compilers since 1991 has been
in hand-written parts. I don't think there is a single production
quality compiler for C++ using anything but a hard-written parser.
That to me is a shame. What we have instead of tools are more
"frameworks" e.g. gcc and the gnu-compiler-collection, CLANG, even the
MIPS suite (Chow's work). LLVM (and possiblu MLIR) are bright spots
that the trend might be reversing. It's a pendulum, swinging one way
than the other.
And finally to Dr Dietrich's and our moderators point. I think that
compilers hand-written or tool generated are all appropriate,
including things like TeX and HTML etc. That would also include IDEs.
However, AI systems that aren't self explanatory and which we don't
know exactly what they recognize are probably not. That's a different
technology. Fortunately, it sounds like there are AI researchers
attempting to make AI systems that do "explain" what their reasoning
is. I might include them especially if they help us advance our own
understanding. The following article talks about it:
Sorry, that I glommed three replies into one. It's just that I am
still in a rush to get some software finished for my "day" job
(despite having once retired but then un-retired to do interesting
stuff and some not so interesting) and taking time to write these
replies definitely impacts that.
Chris Clark email: email@example.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
Return to the
Search the comp.compilers archives again.