parsing

[Brian T Rice]

On Fri, 7 Mar 2003, Jecel Assumpcao Jr wrote:

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

That's interesting, particularly if the language were the only one capable
of expressing the tools.

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

Taking a page from the E playbook, I'd call this a "principle of least
interaction", which probably encompasses their "principle of least
authority". Perhaps my wording is not the best. Can you think of a better
way to express this? It does fit with the HLL security model in Tunes:
http://tunes.org/HLL/safety.html

I find this really interesting, and we have been doing a bit of this in
Slate, in that the namespaces are separated out quite a bit, but there's
so much delegation between them into the lobby that it doesn't matter.
We're planning on providing the ability to enter new Namespaces as
persistent contexts, but for now this suffices.

I'm curious as to how this editor works in the way of semantics.
Basically, what scheme of objects have you arranged to make this work, and
what are your comments on what you chose?

I ask because Slate and Tunes would be interested in automated source
generation and so there'd have to be some reflective level to do this. Now
it seems obvious that this would be in a tool, but there has to be some
medium-independent logic to the tool.

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

Well, there's a common denominator of expectations about pop-up menus, but
CLIM - or more specifically, the Genera UI - do provide more. However,
there's a certain limit to what's intuitively expected at this level.
There's also a limit in the number and variability of possibilities that a
user can effectively deal with.

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

Yes, that is a problem. I used to be fluent in Spanish, but I know how
different Portuguese is; it'd be rough. Well, some kind of demonstration
would be worthwhile. I suppose I could offer some basic translation or
something in return. Anyway a picture (or working model) is worth a
thousand words.

I also recall your essay on translating Smalltalk into Portuguese; it's
definitely an issue I try to keep in mind.

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

There's probably some similar tool for the JVM these days; I imagine we
could do the same with our IL objects. Of course, Fare is interested in
this kind of thing in the sense of functional pattern-matching.

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

Yes, I have that. It doesn't reveal much about the code or architecture,
though. :)

> The link for the software itself still points to sunlabs and so it
> broken, but I have a copy.

Could you mail it to me? Heck, a copy of that Smalltalk-in-Self would also
be illuminating, I'm sure.

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

I suppose so, but it does seem wasteful. The lack of error handling would
be a real loss, of course.

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

Yes, that seems to be the intention within Maude 2, along with the
completion of support for genericity.

> Also mentioned in the introduction is that one difference between Core
> Maude and Full Maude is the support for object-oriented concurrency and
> modules.

Right, it's a prime example of the self-extensibility of the system.

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/