Syntaxes & Block Closures

Mats Nygren nygren at sics.se
Wed Sep 13 17:38:58 UTC 2000


Hi,

I should inform you about the work with syntaxes discussed on the list
earlier this year. I'm a bit behind schedule with it but am getting
warmed up again. It shouldn't take forever before a first version can be
shown. I'm talking about CCodeGenerator, the T<>Node-classes and their
connection with ParseNode-subclasses. Some people that expressed interest
in this earlier and to the extent that you have time for this now, let's
keep in touch.

Besides the syntactic issues I will have things to say about the organization
of the code. How plugins relate to the interpreter. This relates the discussion
in "The Mosner bit". And possibilities of structured information (struct in C).

I also said I would look into the Compiler+VM and make block-closures,
this will take some time. First the code generation (shall write a thesis
about it) then block-closures.

Sum total: this will radically restructure the C code generation process
without essentially change the functionality. Only make it more flexible
for changes and other uses and give some options how the code is
written. Similarly with the Parser. Restructuring for flexibility and
separation of parsing from compilation.
Together with a parser for C this makes it possible to fileOut
ordinary Squeak-code in C syntax for later fileIn. And also it will be
possible to view all of the Squeak code in C(like) syntax. Like Dan Ingalls
NoColon-syntax.

A point with the work is the organization of the code, intended to make
many syntaxes easy to describe and incorporate into the system. In short
it can be seen as a syntactic analog to the semantic MOP of CLOS. In the
sense that a family of things related by inheritance is given instead
of just one single thing. Together with work on MOP's this can get quite
interesting.

When the C-version is satisfactory, candidates are Python, Scheme, Pascal,
Prolog, JavaScript, bash and others. If someone has some speical motivation
for doing some of that a joint effort can be a good idea.

/Mats





More information about the Squeak-dev mailing list