Re: Do I need to invent a new type of parser?

stephen@estragon.uchicago.edu (Stephen P Spackman)
Wed, 29 Apr 1992 03:50:11 GMT

          From comp.compilers

Related articles
Do I need to invent a new type of parser? jeffk@ecst.csuchico.edu (Jeffery Alan Keasler) (1992-04-20)
Re: Do I need to invent a new type of parser? Jan.Rekers@cwi.nl (1992-04-21)
Re: Do I need to invent a new type of parser? jeffk@ecst.csuchico.edu (1992-04-22)
Re: Do I need to invent a new type of parser? stephen@estragon.uchicago.edu (1992-04-26)
Re: Do I need to invent a new type of parser? hagerman@ece.cmu.edu (1992-04-28)
Re: Do I need to invent a new type of parser? stephen@estragon.uchicago.edu (1992-04-29)
Re: Do I need to invent a new type of parser? anton@mips.complang.tuwien.ac.at (1992-05-04)
Re: Do I need to invent a new type of parser? visser@fwi.uva.nl) (1992-05-06)
Re: Do I need to invent a new type of parser? keithc@dcs.qmw.ac.uk (1992-05-08)
| List of all articles for this month |

Newsgroups: comp.compilers
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Keywords: parse
Organization: University of Chicago CILS
References: 92-04-087 92-04-145
Date: Wed, 29 Apr 1992 03:50:11 GMT

In article 92-04-145 hagerman@ece.cmu.edu (John Hagerman) writes:
|This is interesting in itself; I'm working on source-to-source
|translation, and it sure would be nice if real languages handled comments
|in so clean a fashion (ie, so that they could easily be jammed into the
|parse tree, if desired).


Peter Grogono wrote a note about comments as "real" objects in SIGPLAN
Notices a few years ago (sorry, no cite, I'm not at the office). The other
important thing to worry about in designing comment systems is that
annotations need to be uniform and classed: I think we've all experienced
the inadequacy of on the one hand overloading comments with pragmas (a la
Pascal) or of making pragmas an independent unreliable entity (a la ANSI
C). The current lexical rules provide for the following forms of
"comments":


?"Comment directed at the human reader of this source object"
?facility"Pragma or other automatically processed annotation"


The ?facility form also covers applications like ?manpage"..."; the
facility tag itself is theoretically subject to renamed import like any
other identifier (but I haven't even begun to think about the details).
Presumably one ought to be able to say things like


?directive.gnu.3.4_3.8"-register"


to talk specific versions of specific compilers out of generating specific
bugs :-) (*No* offense to the gnu project intended, I just thought, who
else would get this right?!).


There is a second class of comments that are not visible to the syntax,
not because they are not present in the AST but because they satisfy other
pseudoterminals:


The form Is syntactically an
-------- -------------------
_?"Stuff" identifier
:?"Stuff" operator
.?"Stuff" keyword


(The forms of these tokens aren't arbitrary; the _ : . ? prefixes
consistently override the lexical classes of the tokens they attatch to. A
quoted string classes as a single alphabetic character at this level. So
the above are all derivative of the common identifier/ constant category.)


What I'd *like* to be able to do is relate multiple documents through the
extended comments (as, I hate to admit it, a kind of extension of
"literate programming" and hypertext, two notions that on the whole I
loathe :-), so that you could move a comment class "up" to become the
matrix document with embedded ?source"..." (or \source{...}) annotations.
But that really DOES require the abandonment of flat text models because
in general you have non-linearly-related trees.


Visions of ?fortran"..." annotations documenting the
pre-transformation sources dance in the head....
--
stephen p spackman Center for Information and Language Studies
stephen@estragon.uchicago.edu University of Chicago
--


Post a followup to this message

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