[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: [zzdev] A plan: Geek Clang

I love the Geek philosopher idea; we'd have RMS, ESR, and many others ;)

(I know it was a typo but a really great one).

> I will build several orthogonal prototypes of Clang named after Greek
> philosophers.  I except that none of them will be the ultimately chosen
> Clang design, but I hope that these ventures into the design space
> will give us experience and ideas that help in the ultimate design.
> These versions are parallel to each other, and separate from the current
> prototype Clang.  I will develop them as GZZ modules.
> The Greek Clang will have minimal implementations mainly allowing testing
> of the design ideas.

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.

We have to work out where you could publish these language specs in
refereed publications...

> My first design will be called Thales Clang, after Thales of Miletus
> (624-547) who was arguably one of the founders of modern mathematics.
> The basic idea of the design is namelessness for everything,
> weak typing, and a procedural/functional framework for abstraction.
> After implementation, Thales Clang should be powerful enough to express
> anything that is computable.  (I will of course implement primitives for 
> manipulating ZZ space.)

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

Some things to keep in mind: 

- 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

- 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.

- 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).

These are all rather non-complinguistic things, but that's because I trust
you will do well with the core languages anyway.