🚀 go-pugleaf

orion@grun.is (Halfdan Ingvarsson) writes:


>Hiya folks...

>  Erm. I was thinking of writing a (sort of :) compiler using
>my own language (a weirdo mixture of C, Pascal etc.. ) and I
>am getting a little short of ideas. As I don't want to describe
>it in whole, I'm gonna give you a general idea of what it shall
>be..
>  I'm going to make it very neat, small, fast and clean and
>make it produce code that lives up to that. It's probably going
>to be very Archimedes (yeah, yeah Ax000 too) specific, that is
>not portable code. The reason for that is that I'm going to
>implement SWI calls like procedure calls eg.
...

>So.. If anyone has some cool ideas or something dreamthings they'd like to
>see in a compiler I'd be glad to hear from them.
                                                      -Journal of Misfacts
>P.S. If I had some idea about what (blush) Object Oriented code was like
>(and no, I'm not talking about C++. It's crap) I'd also try to make this
>language OO... So be it.. And no flame wars please >:-)

How about letting every statement also define a value, so that it can
be used as an expression. For assignments, the obvious result is the
assigned value. For if-then-elses the result of the succeeding branch
is fine. For blocks, the result of the last statement, for procedure
calls the value of the body etc.

This would get the effect of C's special expressions: a=e, (p ? q : r)
(p , q) etc. and avoid the need for a return statement for functions.

The problems are if-then (without else) and while, as they might not
execute their bodies at all. One could force else-branches to all if
statements and add an else-branch to while, which will be used if the
test fails initially. Alternatively, one could have a "null" value
that would be returned in case the body is not executed.

Afeature I have sorely missed in compilers for C etc. is a cheap
tail-call: if the last thing you do in a procedure or function is to
call a procedure or function, this can be implemented as a goto rather
than a general procedure/function call. Also, the local variables of
the calling procedure need not be saved before the call, as they will
never be used again. Note that this is not a laguage feature, but a
compiler feature. This requires a callee-saves-registers strategy, but
that is often the simplest anyway.

OO features can be (and has been) added in myriad ways. I prefer the
original idea, where every object carries its own methods.
Essentially, an object is a record of values (fields) and procedures
(methods). To save space, the methods can be collected in a record
that is referred to by a pointer in the object record. This allows the
methods record to be shared by all objects in the class. A class
consists of a methods record and a "make" procedure that takes some
initial arguments and returns an object by setting the fields
according to the arguments and setting the method pointers to the
class' own method record.

Apart from typing problems, OO can be easily simulated if you allow
procedures as general values that can be stored and passed as
arguments. If you (like C) have no nested procedure definitions, a
pointer to the execution address is enough to represent a procedure.
If you have nested procedure definitions, you need also the
environment in which the procedure is defined. Pascal does this, but
only allows procedures as parameters, not as stored objects etc. The
reason is that the environment that a procedure value refers to might
not exist at the time it is called.

OO is interesting for the Arc mainly for desktop programming: you can
define a window-class that has methods for the messages that the
desktops returns from a polling call. In the broadest class all the
mask bits are set and most methods are null methods. When defining a
subclass, some mask bits are unset and the corresponding methods
defined. The remaining methods are inherited from the superclass.