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

jeffk@ecst.csuchico.edu (Jeffery Alan Keasler)
Wed, 22 Apr 1992 00:47:25 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: jeffk@ecst.csuchico.edu (Jeffery Alan Keasler)
Keywords: parse, question
Organization: California State University, Chico
References: 92-04-087
Date: Wed, 22 Apr 1992 00:47:25 GMT

Jeffery Alan Keasler <jeffk@ecst.csuchico.edu> writes:
> I am especially interested in methods of handling operators which have
>greater than dyadic associativity. I would also like to know about any
>good papers available concerning efficient methods of handling arbitrarily
>long lookahead under heavy overloading of operators.


>[I'd think that you ought to be able to tweak old-fashioned operator
>precedence to handle this. But it does look like a language design approach
>that will rival Intercal in readability and ease of use. -John]


        My language is not static. Programmers can specify productions in
their programs. These productions will be optimized and incorporated into
the compiler as the compiler continues parsing the rest of the program. I
am simply trying to provide for the worst case so that my parser will not
crash when a crazy programmer trys to implement some strange structure.
For the more usual case, I would expect programmers to generate
productions that look more like the following:


pattern: /* operator uses tertiary associativity */
        REPLACE str1 WITH str2 IN str3
decl:
        string str1 /* The order of these declarations determines associativity */
        string str2
        string str3
code:
. /* definition for the above operation in */
. /* terms of the base language and/or */
. /* previously defined productions */






pattern:
        a < b < c < ... /* ... is one of many special operators. */
decl: /* It means one or more repetions of */
        int a /* the two preceeding items with the */
        int b /* possibility that the 2nd item is */
        int c /* ommitted on the last occurence. */
code:
        logical result
        int i


        result = a < b


        for ( i = 0 ; i < _c ; i ++ )
        {
result = result && b < c [ i ]
}


push result /* return result */
--
jeffk@cscihp.ecst.csuchico.edu
[Not to throw cold water on your plans, but 15-20 years ago there were quite
a few languages which allowed to you define syntax on the fly. They all died.
Makes you wonder, huh? -John]
--


Post a followup to this message

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