parsing

[Jecel Assumpcao Jr]

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

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

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

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

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

Here is the paper:

  http://research.sun.com/research/techrep/1994/smli_tr-94-27.pdf

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 
http://maude.cs.uiuc.edu/manual/maude-manual-html/maude-manual_36.html

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

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

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.

-- Jecel