Re: [Linuxsampler-devel] parser generator

[Vladimir S. <ha...@so...>]

Christian Schoenebeck wrote:

>>>I don't think I like all these tradeoffs in the protocol definition you're
>>>discussing the last days. :)
>>>      
>>>
>>All of them? There was one tradeoff (disallowing key names that match
>>keywords
>>    
>>
>
>Thats one of the tradeoffs I definitely don't like. Because the driver 
>developer should be able to add any parameter name he wants for his device 
>driver.
>  
>
There is an easy way to solve that is with the coding convention. For 
example, all tokens MUST be uppercase and all parameters MUST be 
lowercase. Does the driver developer care if his driver's parameters 
have to be lowercase? It can even be done for him automatically . . .
I think this solves the issue and we can move on to solve other issues 
that have to do with the application. After all, we are not writing a 
parser, so we don't need to be 'perfect' there. Life and software are 
never perfect but as long as a particular solution solves the problem i 
don't see an issue.
When you say 'one of the tradeoffs' what other tradeoffs do you see. 
Maybe i'm forgetting something but i thought that was the only one.

>>so the parser can be smaller and faster) and one fix (putting quotes
>>around string literals
>>    
>>
>
>Right, that was a relict, nothing against that of course.
>
>  
>
>>OK, maybe there's something out there that does something really clever,
>>like flipping between different lexers according to context. But they've
>>    
>>
>
>That's what I meant. The parser should at least work in such way together with 
>the scanner, so the scanner only feeds the parser with terminal symbols which 
>are defined in current (that is most congruent) grammar rule. The interface 
>between lex and yacc is of course too primitive to allow such things. But 
>there are a lot of parser generators out there, so I still hope we can find 
>one that can do that and maybe even supports BNF, means an abstract 
>definition of the protocol.
>  
>
We could. I'm not sure this is really necessary. The protocol is not 
that incredibly complex that we can't solve our issues using flex/bison 
combo. Again, i'm not a flex/bison person myself so i'd love to learn 
any other software as well so bring it on :) I just don't see any 
urgency in that. To me it's like priority number 65535 :)

Regards,
Vladimir.