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) |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.