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

rgaupsas <elikon@cox.net>
24 Mar 2005 21:12:48 -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: rgaupsas <elikon@cox.net>
Newsgroups: comp.compilers,comp.compilers.tools.pccts
Date: 24 Mar 2005 21:12:48 -0500
Organization: Cox Communications
References: 05-03-055 05-03-072
Keywords: translator
Posted-Date: 24 Mar 2005 21:12:48 EST

Brian Inglis wrote:
> 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?


Sorry, my choice of the term COLOR was poor for this example. COLOR,
NAME, and PARAM can all be alpha-numeric combination. So a list of valid
terms is not applicable.



Post a followup to this message

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