Re: Compiler writers will love this language

ericmuttta@email.com (Eric) schreibt:


>Hmm. To me, "designing" a language, is thinking about problems that
>need to be solved and then crafting a tool (ie the language) that is
>suited to solving those problems.


If I understand you correctly, then you care more about features than
about grammars. In this case you'd have to concentrate on the
algorithms which are useful in the area of interest, what data
structures are used by these algorithms, and how and which algorithms
can work together. These considerations almost go into the design of
objects (data types and structures) and a library of procedures and a
runtime system, not into the design of an compiler.


As to the runtime system, this can be more or less efficient. But IMO
this is a more a matter of optimization than of design. I'm not a
compiler writer myself, so I can give only some obvious hints, as to
consider the order (complexity) of the required algorithms. Some
keywords just come into mind, like OO, polymorphism, indirection,
globals, aliasing, and memory management. I'll not dig deeper into
these topics now, as long as I'm not sure whether they are of concern
to you. Only some general statements:


Object Orientation IMO is good, even if invisible to the user of a
language. Every data type with multiple members should become an
object, with related methods, so that it's clear to the user,
compiler, and to all procedures, how the information in such an object
can be accessed, interpreted and modified. Here I consider OO as a
design technique, with no implications on the concrete implementation.


Polymorphism and indirection is okay, as long as the objects
themselves are unambigous, so that it's possible to invoke their
methods without much guessing about the exact type of a given
object. Calling method X of interface Y of an object is not a very
complex operation, as long as the type of the interface(s) and the
pertaining methods are obvious from any given object.


IMO it's a good idea to force the user to explicitly define all
required interfaces of his objects, not only for the sake of a good
runtime behaviour, but also for a good application design. Allow for
compile time checks wherever possible, every check at compile time
prevents checks and errors at runtime.


Memory management can be implemented with or without garbage
collection, and with implicit or explicit initialization and
finalization of local objects. I'll leave it to more experienced
contributors to discuss these points, as well as the problems with
global variables and aliasing.


DoDi

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