Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #34139

Re: Parsers for extensible grammars?

Cross-posted to 2 groups.

Show all headers | View raw

On 10/25/2014 2:14 PM, Les Cargill wrote:
> rickman wrote:
>> On 10/23/2014 11:30 PM, Les Cargill wrote:
>>> Don Y wrote:
>>>> Hi,
>>>>
>>>> [I probably should direct this at George...  :> ]
>>>>
>>>> I'm writing a command parser.  Some set of commands are "common".
>>>> But, other instances of the parser are augmented with additional
>>>> commands/syntax.
>>>>
>>>> [These additions are known at compile time, not "dynamic"]
>>>>
>>>> Ideally, I want a solution that allows folks developing those
>>>> "other" commands to just "bolt onto" what I have done.  E.g.,
>>>> creating a single "grammar definition" (lex/yacc) is probably
>>>> not a good way to go (IME, most small parsers tend to be ad hoc).
>>>>
>>>> [Note:  I can't even guarantee that the extensions will be
>>>> consistent or "harmonious" with the grammar that I implement]
>>>>
>>>> A naive approach (?) might be for my code to take a crack at
>>>> a particular "statement"/command and, in case of FAIL, invoke
>>>> some bolt-on parser to give it a chance to make sense out of
>>>> the input.  If *it* FAILs, then the input is invalid, etc.
>>>>
>>>> This sounds like an incredible kluge.  Any better suggestions?
>>>
>>>
>>> If all else fails, strstr() keywords, then have a corresponding
>>> parsers for each keyword.
>>>
>>> A better approach is a container (struct) of keywords or arguments ( if
>>> it's not a keyword, it's an argument ) , an integer for the index of
>>> keywords in s string table, and an index for the position of the token
>>> within the command.
>>>
>>> Extensibility should not be difficult.
>>
>> That is starting to sound a lot like Forth.
>>
>
> Forth could easily be a better choice. I need to spend
> more time on Forth.
>
> I tend towards Tcl because I have a large codebase of scripts
> for it. It also excels at socket/serial port handling.

In many ways Forth is amazingly simple.  You define words (subroutines) 
that have actions.  Words are stored in the dictionary.  Forth has built 
in a "parser" that scans the input for words and numbers (in that 
order).  The dictionary is searched for words in the input stream and 
when found they are executed.  If no word is found Forth checks to see 
if the "word" is actually a number.  If it is a number it is pushed onto 
the stack.  Pretty simple, no?

The action of a word can make use of system words to further parse the 
input stream.  This is done if the input "grammar" is not RPN style with 
the values first (nouns) and the words (verbs) last.  This is done even 
for some Forth words like "TO" which is used to store a value in a 
variable, e.g. "99 TO BottlesOfBeer".

Most people find the use of the stack to be a problem for them while it 
is really no big deal.  It's just different.  Forth has other issues 
which relate to the fact that not so many people use it.  But it seems 
to be a very useful tool to me.

-- 

Rick

Back to comp.lang.forth | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: Parsers for extensible grammars? rickman <gnuarm@gmail.com> - 2014-10-25 14:23 -0400
  Re: Parsers for extensible grammars? Les Cargill <lcargill99@comcast.com> - 2014-10-26 00:50 -0500
  Re: Parsers for extensible grammars? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-26 19:21 +0000
    Re: Parsers for extensible grammars? rickman <gnuarm@gmail.com> - 2014-10-26 15:29 -0400

csiph-web