[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] A plan: Geek Clang
- To: ZZ Development <zzdev@xxxxxxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] A plan: Geek Clang
- From: Antti-Juhani Kaijanaho <gaia@xxxxxx>
- Date: Mon, 14 Aug 2000 10:42:00 +0300
- In-reply-to: <Pine.HPP.3.96.1000812141623.28807G-100000@xxxxxxxxxxxxxxxx>; from lukka@xxxxxxxxxxx on Sat, Aug 12, 2000 at 02:24:56PM +0300
- Mail-followup-to: ZZ Development <zzdev@xxxxxxxxxx>
- References: <20000811122755.I5648@xxxxxxxxxxx> <Pine.HPP.3.96.1000812141623.28807G-100000@xxxxxxxxxxxxxxxx>
- Sender: Antti-Juhani Kaijanaho <ajk@xxxxxxxxxxx>
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
> - eventually we want some version of clang to
> be compilable to C-like speed (either JIT or explicitly)
> - 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).
%%% Antti-Juhani Kaijanaho % gaia@xxxxxx % http://www.iki.fi/gaia/ %%%