Do we need parsers?

Could the assembled wisdom pronounce on this idea?


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


If each object knew how to display itself, either as something like
cout << "if" << ifObj.expr << " then\n" << ifObj.statements << "endif\n";
or more graphically. And each object knows how to execute itself,
either in terms of invoking the execute method of other objects or
invoking primitives. They even could have a compile method that would
compile that object into a lower code.


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? An object editor wouldn't ever allow you to delete or
add say the 'i' in "if", but only the entire "if-then" object.


In a crude sense you can say its "been" done, the syntax editors do
something like this. But I am saying, we have the dog barking, now
chase the dog away and lets just work with the bark.


In a crude sense the "persistent object store" code becomes your
parser. But the point is it doesn't have to be human friendly
anymore. What has to be human friendly is the object "display"
methods. This may well be the whole power of this approach. It
separates the language object storage method from the human readable
display.


Thus the exact same code can be given a fancy textual display
colorized and fontized to the Nth degree, or at a switch of a flag,
some variety of diagrammatic display. Furthermore the editing can be
done on any of the displays.


John Carter EMail: ece@dwaf-hri.pwv.gov.za
Telephone : 27-12-808-0374x194 Fax:- 27-12-808-0338
[This is sort of the way that Smalltalk works, with each token eating
some tokens that follow. I can't say that I think it's a wonderful idea,
since it scatters the syntax all over the place and can be the source of
some rather wierd bugs. -John]
--

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