Jecel Assumpcao Jr
Fri Mar 7 15:49:01 2003
> > > [PIE and Sketchpad]
> Maybe you should post some reviews and links for them on the CLiki.
Good idea, though it will take me a while to get around to doing this. I
took a look at the other reviews and the list is very impressive.
> Okay, so you have the grammar but you don't worry about parsing.
> Actually, if individual keystrokes and such dispatch to "editors" or
> "specialized grammars" then it's not really a CFG, but Lisp's READ
Right, though that is a tool issue and not a language implementation
one. Bootstrapping is specially interesting when the language can't
work at all without a set of tool (implemented in that language!).
One thing that I should have been more explicit about is that I don't
have anything like "lobby" or "globals" that all objects inherit from.
The editor does keep a table of interesting objects around and allows
you to insert them into the code. This is only possible because objects
retain their identity when changed: you don't edit buttonMorph by
creating a new object and associating it with the old name in some
Why is this a good idea? Because then objects only know about other
objects they really need, not 416 that happen to be in some global
> The issue I see with this is that eventually you will want some
> contextual-sensitivity. But this is sort of a non-issue if you still
> have an access mode to whatever you want (an implicit escape).
The various editors are nested graphically so you can change modes with
a simple movement of the mouse. Pop-up menus are about as context
sensitive as you can get.
> Anyway, I'd like to see a demo of this some time. ;)
One little problem is that the system I am currently building is
entirely in Portuguese (the people I am doing this for can't read
English at all).
> Eventually some kind of system for serializing and reconstructing
> objects, yes. Parsing in the abstract sense does help with this.
Reading html pages, Excel spreadsheets and all kinds of legacy data is
important. That is a lot of boring programming if you don't have tools
> SmaCC works mostly the same way, except that it parses input text
> which partially consists of regular expressions. Ultimately, though,
> the main problem is that neither Smalltalk nor Self have the same
> kind of code model as Slate, so I'd have to hand-roll the
> code-generator in either case from scratch.
> (see src/compiler/cc.slate in the Slate CVS repository for some of
> the work I've been doing on this.)
It looks very interesting and I'll take a better look tomorrow. I
haven't actually seen SmaCC or TGen so I can't compare this with them.
A long time ago I wrote an "universal" assembler based on matching
regular expressions and it was fun to work with.
> I also haven't been able to find a working link for Mango in years,
> and I lost the copy that I did have. If you have a link, I'd welcome
Here is the paper:
The link for the software itself still points to sunlabs and so it
broken, but I have a copy.
> Parsers can't be generated from the BNF directly because the result
> would be too slow for real usage.
Even on modern machines? Even in the old mainframe days I would directly
translate BNFs into recursive Algol parsers. The problem wasn't
performance but really bad error handling.
> > The Maude manual pages you gave a link to talk about "objects" a
> > lot. I haven't looked at the rest of the language description.
> It does? I notice lots of uses of "operator" and "term" but not
> "object". There /is/ a way to perceive this system as objects and
> messages, which is a very interesting part of the language
> ("mobile"/"oo" maude), but it doesn't seem to be emphasized there.
Ooops... it was probably a hasty reading of
"Using object-oriented concepts, we can specify in Maude a general
input/output facility provided by the LOOP-MODE module shown below...
...We plan to endow Maude with general built-in support for objects;
this will make possible more general and flexible solutions for dealing
with input/output and persistent objects"
Also mentioned in the introduction is that one difference between Core
Maude and Full Maude is the support for object-oriented concurrency and
> One of the strengths of Maude's algebraic/rewrite model for parsing
> is that terms and parse trees have a lot of the same computational
> issues. The "geometric" properties of an operator (associativity,
> idempotency, and such) are dealt with at the same level for both
That sounds like it avoids having to write the same thing twice. I'll
have to find some time to read the whole Maude manual again.