Re: Do we need parsers?

Firstly I would like to beg the patience of our moderator. This post
will seem to wander far from the topic of compilers into the realms of
text handling utilities. If you will allow me I will, amongst other
tricks, show that if the intelligence of the compiler is placed on the
objects, all other utilities gain the power of the compiler.


On Fri, 16 May 1997, David Gay wrote:


> John Carter <john@dwaf-hri.pwv.gov.za> writes:
> If every statement was an object. ie. You had an "if-then" object, an
> "if-then-else" object and a "assign" object and and and..
>
> Then do we need lexical analysers and parsers? Couldn't we just create
> object editors and persistent object stores and bypass the whole
> grammar issue?


> There are several objections to this:
> 1) you have to convince users to use your special "object" editor,
> when what they are used to is emacs/whatever.


True. But Emacs is so flexible, I might well be tempted to write the
first versions in Elisp as a major-mode anyway.


The storage format would be brute force, simple as possible, with open
specification so writing/adapting another editor to handle the objects
would be easy.


The hard work and the intelligence lies in the design and creation of
the object classes themselves.


It is important to recognise that deep in the heart of all OOPS
implementations is what is essentially a database of information about
the structure of and procedures that operate on the objects.


Thus unlike parsers, generic object editors can be really dumb. They don't
need to know much, they just need to know how to get answers from the
OOPS database.


> 2) you lose all the programmer tools that assume text-based programs,
> e.g. grep, revision control systems, etc.


Ah! But think of what you can gain if the programmer tools follow this
path as well.... Smart-editing is just the tip of the iceberg. Freedom
of representation is just the first and smallest of benefits.


An editor is a general purpose tool for manipulating ASCII chars. Grep
searchs amongst ASCII chars for a specified pattern. Now what if we up
the level of atomicity to objects instead of mere chars. What if
"grep" and "head" and "diff" and "patch" and and and ... worked with
objects as the basic atoms. What if we have a very rich library of
objects, do we not then vastly increase our power. Imagine a regular
expression query and replace in a document....


Now for the following example denote an arbitary object of type 'T' by
[T]. Suppose in our document we had a series of tables containing
experimental data followed by a program modelling some aspect. (OK,
so this example is contrived, I just wish to illustrate the
implications of moving from an ASCII centric system.)


Find all occurences matching the regular expression
"[Table]*([Table])([Program])" and replace it by "[String 'The sum of
row one of the table'] \1 [String ' is '] \1.row[0].sum [String
'compare this with the result of the model'] \2.eval"


Where \1, \2 correspond to the objects matched in the "()" brackets within
the regular expression. (As per Emacs query-replace-regexp or Perl
regexps)


Note the vast increase in power, enabling one to work at structural
levels with our normal text tools. Note the "\1.row[0].sum", as \1 is
a table object, we can invoke table methods on it, thus document and
programming language becomes mixed. Note the "\2.eval", as \2 is a
program we can evaluate it.


OK, So my convention [String 'this is a string'] is cumbersome but
this is merely an artifact of trying to explain what the future could
be like using present day ASCII tools.


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


I once saw a algebraic manipulation package that had the lovely
feature that the cursor keys changed which subexpression was currently
selected for copy/replace operations. Left/right arrow chose preceding
/ succeeding expressions, up/down arrow encompassing expression /
first subexpression. So to resolve your problem you would select the
clause you want, you will find this takes far fewer keystrokes than
character by character selection, then copy and paste. By sufficently
many "down arrows" one can work at an arbitarily low level, including
character level.


> 4) I don't think you'll avoid lexical analysis:
No, I can't, not entirely. But the scanner can be made smarter allowing
things like the linux-style TAB key name completion. For example,
possible identifiers would be severely restricted by the scoping and
typing rules, thus automatic name completion could be a powerful aid.


> [Still sounds like Smalltalk. -John]
Yes, that dog is barking, keep the bark, chase away the dog. Remove
the reliance on an ASCII textual storage form.


John Carter EMail: ece@dwaf-hri.pwv.gov.za
Telephone : 27-12-808-0374x194 Fax:- 27-12-808-0338




--

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