Re: Flex/Bison/ANTLR question... alternative tools for translation?

Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
20 Mar 2005 10:14:12 -0500

          From comp.compilers

Related articles
Flex/Bison/ANTLR question... alternative tools for translation? elikon@cox.net (rgaupsas) (2005-03-15)
Re: Flex/Bison/ANTLR question... alternative tools for translation? lfinsto1@gwdg.de (Laurence Finston) (2005-03-18)
Re: Flex/Bison/ANTLR question... alternative tools for translation? Brian.Inglis@SystematicSW.ab.ca (Brian Inglis) (2005-03-20)
Re: Flex/Bison/ANTLR question... alternative tools for translation? sk@z.pl (Sebastian) (2005-03-20)
Re: Flex/Bison/ANTLR question... alternative tools for translation? elikon@cox.net (rgaupsas) (2005-03-24)
Re: Flex/Bison/ANTLR question... alternative tools for translation? Brian.Inglis@SystematicSW.ab.ca (2005-03-25)
Re: Flex/Bison/ANTLR question... alternative tools for translation? elikon@cox.net (rgaupsas) (2005-03-31)
Re: Flex/Bison/ANTLR question... alternative tools for translation? Brian.Inglis@SystematicSW.ab.ca (Brian Inglis) (2005-04-02)
| List of all articles for this month |

From: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
Newsgroups: comp.compilers,comp.compilers.tools.pccts
Date: 20 Mar 2005 10:14:12 -0500
Organization: Systematic Software
References: 05-03-055
Keywords: parse, tools
Posted-Date: 20 Mar 2005 10:14:12 EST

On 15 Mar 2005 01:42:26 -0500 in comp.compilers, rgaupsas
<elikon@cox.net> wrote:


>I'm working on a translator whereby the input grammar is poorly
>defined; a lot is contextually dependent. I've gotten pretty far with
>Flex/Bison, making heavy use of lexical tie-ins to deal with
>this. However I have some cases, and expect to see more, which Bison
>handles poorly, e.g.:
>
> WK COLOR COLOR ... COLOR NAME PARAM = NUMBER
>
>The problem is that syntactically NAME and PARAM are indistinguishable
>from COLOR (both are alpha numeric of the same form), so the following
>form will not work (note Bflag sets the start_state in Flex).


Some lexical examples would help to understand your problem better:
you may be parsing non-terminal and terminal COLORs, etc. as if they
are the same type of token; they should not be, but it's hard to tell.
Which of these presumably syntactic elements are non-/terminals? If
you have a non-terminal COLOR, shouldn't you recognize it lexically by
looking up a list of currently valid colours, which may be modified by
defining a new colour name and value, if I understand some of your
intentions correctly?


--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada


Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
        fake address use address above to reply


Post a followup to this message

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