Re: Need starting tips for a new interpreter / parser

mikee@cetasoft.cog (Mike Enright)
15 Jan 1999 01:08:15 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: Need starting tips for a new interpreter / parser anton@mips.complang.tuwien.ac.at (1999-01-03)
Re: Need starting tips for a new interpreter / parser lio-daa@online.no (Harald Fjerdingstad) (1999-01-04)
Re: Need starting tips for a new interpreter / parser lio-daa@online.no (Harald Fjerdingstad) (1999-01-06)
Re: Need starting tips for a new interpreter / parser escargo@mirage.skypoint.com (1999-01-06)
Re: Need starting tips for a new interpreter / parser mslamm@mscc.huji.ac.il (Ehud Lamm) (1999-01-11)
Re: Need starting tips for a new interpreter / parser Immanuel.Litzroth@pandora.be (Immanuel Litzroth) (1999-01-11)
Re: Need starting tips for a new interpreter / parser mikee@cetasoft.cog (1999-01-15)
Re: Need starting tips for a new interpreter / parser hunk@alpha1.csd.uwm.edu (1999-01-15)
Re: Need starting tips for a new interpreter / parser lio-daa@online.no (Harald Fjerdingstad) (1999-01-17)
Re: Need starting tips for a new interpreter / parser mikee@cetasoft.cog (1999-01-19)
Re: Need starting tips for a new interpreter / parser ndc@alum.mit.edu (N. D. Culver) (1999-01-20)
| List of all articles for this month |
From: mikee@cetasoft.cog (Mike Enright)
Newsgroups: comp.compilers
Date: 15 Jan 1999 01:08:15 -0500
Organization: CetaSoft (com not cog)
References: 99-01-012 99-01-016 99-01-020 99-01-022 99-01-026
Keywords: design

On 11 Jan 1999 14:36:21 -0500, Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:


>[Using a language underneath a visual editor with capability
>of editting either textually or visually]
>
>One of the hard parts here is being able to do the transformation in both
>directions:
>visual/user view -> textual program
>textual program -> visual view
>
>This is a challange in those cases where either:
>* you have old reports that were created before the interface existed.
>This luckily for you, you don't have. OR
>* users/admins are allowed to change the textual code, but the result
>should make sense when viewed graphically.
>
>Doing these transformations in a straight forward way is not hard. But it
>will usually either mean stroing duplicate information, or producing a
>less than optimal visual representation.


I think if the report language was mostly declarative, a reversable or
redundant representation might not be necessary.


In parsing the script, one could use a parser which picked up the file
intervals of objects parsed. The tokenizer would have to provide the
file interval of each token, and then the parsing of non-terminals
would take it further. I think this data could be carried as
attributes if the parser worked that way. Eventually the file
intervals describe the intervals corresponding to the properties of
each object.


The graphical editor would either end up flagging changed objects or
creating new ones. In writing out the edits, one would essentially
copy text from the original file except in intervals the user changed.


This would give you a system that would allow both textual and
graphical editting. The end-user would decide which.


Post a followup to this message

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