Re: Looking for new language features (re-elaboration)

lingolanguage@hotmail.com (William Rayer) wrote (abridged):
> Thanks for all the ideas and feedback. What I am really after, and the
> fault is mine for not being more detailed in my original post, is
> higher level features / semantics / control structures / data types /
> language elements or whatever that make it "easier to program".


An old idea which is often underrated: static data. A lot of problems
are best solved by writing the answer in by hand - by tables of static
data.


One of C's great strengths is that it is very good at expressing these
efficiently. This facility got somewhat lost in C++ and thrown away
completely in Java (admittedly there it is largely a linker issue).


A basic problem is that your data is now supposed to be an "object",
which means it has to satisfy its class invariants, which means you
have to run some class-specific code called a "constructor" to set it
up. You can't just specify the final answer directly as that would
by-pass the constructor and let you express invalid objects.


An approach which is taken in some flavours of Smalltalk (eg Dolphin)
amounts to compile-time evaluation. For example, you can write:


        colors
                ^##(Dictionary new
                        at: 'red' put: Color red;
                        at: 'blue' put: Color blue;
                        at: 'green' put: Color green;
                        yourself)


The stuff inside the ##() brackets gets executed at compile time. It
has 4 statements which create then populates a dictionary. The
compiler stores the result - the dictionary - in the method's
constants table directly. The code emitted just fetches the object
from the constants table and returns.


Smalltalk has a funny linker model, but if it were compiled into C we
could imagine the compiler emitting static data representing the
result of running the constructor. The constructor would not need to
be run at load- or run-time. Obviously this could make the emitted
code non-portable; eg it may depend on platform-specific hash values.


That's an extreme approach to think about. Eiffel uses "once"
functions that are evaluated at runtime, but only once. I'm not sure
its syntax is expressive enough to make tables really easy to work
with.


    Dave Harris, Nottingham, UK
            brangdon@cix.co.uk

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