Re: Do we need parsers?

dgay@barnowl.CS.Berkeley.EDU (David Gay) writes:
> 2) you lose all the programmer tools that assume text-based programs,
> e.g. grep, revision control systems, etc.


grep can still be used since a text-representation is available (and
can even be chosen) via an unparser. RCS is bit more painful in that
you'd can't just use the "generic text-diff algorithm", but such an
algorithm is already unuseable in several cases (like RCSing a GIF
file or a C source with sufficiently bizarre #defines). Also it seems
that such filetype-specific diff/merge algorithms might become much
more widespread since they are also useful for
very-wide-area-filesystems or disconnected-operation (a la CODA). Your
point still holds, tho, in that such an object-based (or
structure-based if you prefer not to sound too OO) environment can't
conveniently be quickly-grafted onto a Unix environment.


> 3) editing does not always follow the language's structural boundaries.
> I might want to copy the 'then' and 'else' clauses of an 'if' - this
> is hard in a structure-based environment.


That's true. Making it work as people would expect could be or sufficiently
hard to make it undesirable (from the coder POV, not for the user, of course).
But it's absence can be compensated by:
- exact and fancy font-locking (as opposed to emacs-style font-locking which
    only works most of the time)
- easy and precise spell-checker (knowing scoping rules allows to know exactly
    what identifiers are possible at a given place)
- ability to change an identifier without having to figure out where it is used
    (and without risking changing another identifier that happens to have the
    same name, but with a different scope)
- never any syntax error any more
- no more parsing/lexing might slightly speed up compilation
- getting rid of the text-representation allows more freedom, like having each
    user choose the representation they prefer (some might like lisp-style
    parentheses, others might prefer begin..end or {..}, ...)
- also potentially allows to get rid of the file-grouping thus allowing to
    look once at "all method for type foo" and later of "all variants of method
    bar" (so that you get both the OO-style per-class grouping and the
    ML-pattern-style per-operation grouping. Ideal for multi-method languages)


> 4) I don't think you'll avoid lexical analysis: you still need to
> verify that those numbers really are numbers, that the identifiers
> start with a letter, and contain only letters or numbers, and so on.


Agreed: it probably won't make lexing simpler, but it might allow to
get rid of most parsing problems (and replace'em with others, but
then, that's the whole point of "switching paradigm", right?)


> David Gay - Yet Another Starving Grad Student


Time to check out l'eveche again ?


> [Still sounds like Smalltalk. -John]


Yes. All I hope is that these ideas (coming from Lisp and Smalltalk
machines) will one day make it into main-stream systems.


                Stefan
--

Return to the comp.compilers page.
Search the comp.compilers archives again.