Re: [zzdev] Re: [zzdev] A plan: Geek Clang

[Antti-Juhani Kaijanaho <gaia@xxxxxx>]

On 20000812T142456+0300, Tuomas Lukka wrote:
> You do realize that if there are enough of these and you develop them to a
> great enough depth, that this would probably be sufficient material for a
> PhD thesis? One such language would probably suffice for an excellent Pro
> Gradu... If you want to do these, the department would love you: they need
> graduates more than anything else.

I was afraid of that :-)

> Everything: what about the primitive cells, and their joinage with Java?
> Simply put them on a rank, nameless again, and 

Is there a way to make the "magic connection" between a cell and a Java
callback persistent, without resorting to an associated string that
magically binds them together; since if all primitives are cell clones,
I would not want to have the meaning of all programs to change (or worse:
the programs themselves to become broken) when somebody edits the texts
that binds the cells to the callbacks.

I can easily make that binding in a new space (eg. hash the cell object
or cell id and the callback in a Java Hashtable), but it'd have to
be persistent.

> - eventually we want some version of clang to
>   be compilable to C-like speed (either JIT or explicitly)

Yes.

> - need a good mechanism for specifying which language a script is in

My current idea is to use a namespace-like mechanism for the Greek Clang
"magic dimensions", so that for example we'd have a d.thales-argument,
d.thales-sequence etc.  But is this enough?

> - a very neat thing would be to have the execution model optionally
>   explicable: putting the stack or whatever the VM is doing into the space
>   so that the user can follow exactly what is happening. This would be
>   optional for efficiency reasons.

I'm thinking of designing the runtimes around ZZ, with some eye
on how easy it would be to do them in bare metal (~ compilation).
(Thales will use an activation record structure instead of a stack due
to the functional abstraction techniques.)

Hmm, automatic cell management: which is more efficient in terms of space:
when a cell representing an intermediate result is provably unnecessary,
just leave it at deleting all its (relevant) connections, or should I
also delete the cell itself?  If latter, some of the languages will need
an automatic cell management routine, a kind of garbage collector.

> - think about what kind of views would help to code and debug programs
>   in whatever languages (and showing comments in a nice way; e.g. floating
>   next to the code rather than embedded in the command stream).

Right.

-- 
%%% Antti-Juhani Kaijanaho % gaia@xxxxxx % http://www.iki.fi/gaia/ %%%