|Incomplete compiler? Uwe.Uta.Altenburg@t-online.de (Uwe Altenburg) (2002-04-24)|
|Re: Incomplete compiler? firstname.lastname@example.org (2002-04-29)|
|Re: Incomplete compiler? email@example.com (2002-05-01)|
|Re: Incomplete compiler? firstname.lastname@example.org (Bernhard Pfahringer) (2002-05-01)|
|Re: Incomplete compiler? email@example.com (2002-05-03)|
|Re: Incomplete compiler? Martin.Ward@durham.ac.uk (2002-05-03)|
|Re: Incomplete compiler? firstname.lastname@example.org (Ira D. Baxter) (2002-05-03)|
|Re: Incomplete compiler? tfb@apocalypse.OCF.Berkeley.EDU (2002-05-04)|
|Re: Incomplete compiler? email@example.com (2002-05-04)|
|From:||"Ira D. Baxter" <firstname.lastname@example.org>|
|Date:||3 May 2002 16:03:43 -0400|
|Posted-Date:||03 May 2002 16:03:43 EDT|
"Hans Aberg" <email@example.com> wrote in message
> "Uwe Altenburg" <Uwe.Uta.Altenburg@t-online.de> wrote:
> >I would like to know, if there is a compiler (and a language) where I
> >tell the compiler in the source-code how to compile the source?
> ... computers are now so powerful, that there is no problem
> adding complex computer languages. It becomes more reasonable to have
> different syntax for different contexts.
> Another applicable context might be computer languages that have a wide
> range of applicability: I followed the development of Haskell somewhat,
> and there they had the problem of which syntax shortcuts to allow -- they
> tend to clash. This clash is then a consequence of insisting on using only
> one syntax for the whole language.
The standard phrase for this is "Domain Specific Language (DSL)". The
usual argument is that you should let designers write down their
problem/solution in a familiar notation to minimize errors and
maximize productivity. The issue then becomes, how to implement such?
One model is the "standalone DSL". This amounts to (hopefully an
interesting) choice of notation with a code generator.
A second model is the directly extensible language idea. If you
believe that DSLs are useful, then they ought to be useful in this
context, too. That the extensible language idea died out I think is a
consequence of the fact that extending a language grammar a little bit
to get a DSL is awkward and really fails to achieve the desired goal
of having a DSL: notational conciseness. It is tough to extend the
C++ syntax directly to include a real differential equation notation.
A very interesting experiment along these lines was done by Microsoft
in the form of a research tool call "Intentional Programming". The
notion here was a program was represented essentially by an abstract
syntax tree, having a per-node customizable presentation/editing front
end so that user could see any desired syntax and directly-manipulate
("edit") in a graphical sense that notation in a way that was
notation-specific. After investing 10 years of development into IP,
Microsoft has, as far as know, cancelled it so we won't ever know how
effective this idea really was in practice.
We are trying to walk a middle road with our DMS Reengineering
Toolkit. It enables the definition of arbitrary DSLs (presently
string based, but in theory arbitary graphical notations) and eases
the construction of generators as translators between the DSL and
another more conventional "DSL" such as C/Java/... So a DMS
application consists of an array of specifications written in a set of
different DSLs, all of which cooperate to achieve the end effect.
It turns out that the specification of such translators is nicely done
by yet another set of DSLs, including ones we all know and love like
regular expressions for lexers, BNF for grammars, attribute evaluators
for analysis. Perhaps the most interesting "DSL" we use are
source-to-source rewrite rules. Here's a language which is extended
(automatically) to include other languages as part of its notation.
Back to the original question, if you count all the separate inputs to
DMS as "the program source", then in fact you exactly specify how to
compile your program "in the source".
Arguably, the GNU GCC sources can be viewed the same way, so you might
not think this is that big a win :-}
Ira D. Baxter, Ph.D. CTO Semantic Designs, Inc.
Return to the
Search the comp.compilers archives again.