On 2011-08-11, at 15:26, Tudor Girba wrote:
> Hi Camillo,
>
> A first-class omit would be better especially given that you could package it
> as an extension.
>
> In any case, the current code should be reverted. While you play with another
> implementation, could you move the current versions from the PetitParser
> repository?
sure sure remove it :)
> Cheers,
> Doru
>
>
> On 11 Aug 2011, at 15:14, Camillo Bruni wrote:
>
>> Thanks for the vast answers and pointing out critical parts of the
>> implementation.
>>
>> On 2011-08-11, at 08:14, Tudor Girba wrote:
>>> Hi,
>>> Camillo, thanks for taking an interest and for letting us know that you
>>> committed.
>>>
>>> Lukas, thanks for the answer. I would also like to add one comment: omit is
>>> maybe interesting for small and quick parsers in which you have the grammar
>>> and the parser together. However, for anything significant, if you want to
>>> split the grammar and the various parsers, it all of a sudden becomes less
>>> useful because you do not want to restrict the grammar.
>>
>> Yeah and that's exactly the reason why I think this is useful. Since we want
>> to use PetitParser also for small "dirty" projects where portability is a
>> secondary problem. And I still disagree that it becomes less useful, it is
>> just a way of filtering your output from parser in a very simple way ;).
>> Furthermore having the omit doesn't mean that you will have to use it. t
>> mean there is also the #flatten message which goes somewhat into the same
>> direction IMO, since it is there for modifying directly in the parser the
>> data. It could be omitted as well and put into the grammar.
>>
>>> I also took a quick look at the implementation. There are simply too many
>>> ifs that add complexity to an already non-trivial code.
>>
>> Indeed the implementation is not very nice, and more of a preliminary hack
>> to see if it works, I will definitely do a second pass with lukas'
>> suggestion for a first-class object to denote the omit property.
>>
>>> All in all, I think we should retire this add-on.
>>>
>>> Cheers,
>>> Doru
>>>
>>> On 11 Aug 2011, at 07:31, Lukas Renggli wrote:
>>>> Hi Camillo,
>>>>> I quickly hacked (with a lot of tests) support for omit in PetitParser.
>>>>> This should simplify some parsing efforts as an additional filtering step
>>>>> could be avoided.
>>>>>
>>>>> parser := ($" asParser omit, $" asParser negate star flatten, $" asParser
>>>>> omit)
>>>>> parser parse: '"asdfsd"' "yields directly #('asdfsd') "
>>>>>
>>>>> vs
>>>>>
>>>>> parser := ($" asParser, $" asParser negate star flatten, $" asParser)
>>>>> parser parse: '"asdfsd"'
>>>>>
>>>>> which yields #($" 'asdfsd' $")
>>>>
>>>> I don't really see use of #omit. The element is still in a collection
>>>> and you need to extract it from there. What is the benefit other than
>>>> it is now at index 1 instead of 2?
>>>>
>>>> Also the implementation has some problems:
>>>>
>>>> 1. #omit makes it really hard to compose grammars, because parsers
>>>> suddenly get very asymmetric and start to affect each others behavior
>>>> depending on how you compose them.
>>
>> it shouldn't be about the behavior of the grammes, I might have not done
>> everything correctly in my implementation, but the way the parsing rules are
>> evaluation is not changed, its should be only affecting the output of the
>> parsers (in this sense a special PPActionParser).
>>
>>>> 2. For the same reason grammar transformation becomes impossible, one
>>>> of the design goals of PetitParser.
>>
>> sure, but having the feature doesn't mean you have to use it. And in my case
>> it would simply some of the parsers I use.
>> Actually in the end the Omit is nothing but a special PPActionParser right?
>> (Just a curious question, how do you handle grammar transformation in this
>> case?)
>>
>>>> 3. #omit makes a typical grammar (the smalltalk one) roughly 15%
>>>> slower without even using the new feature.
>>
>> yep thats an implementation issue, as you mentioned addressing this with a
>> first-class object won't affect existing grammars at all.
>>
>>>> 4. There are various methods (#-, #match..., #copy..., ...) that need
>>>> to be fixed when you add state to a parser.
>>>>
>>>> 5. There is no need for eager (#initialize) as well as lazy
>>>> initialization (kills the possibility for a quick invocation).
>>
>> right, thats indeed an ugly property of my hack (=> first class objects will
>> do)
>>
>>>> 6. Please do not remove PPParser class>>new and do not change how
>>>> initialization works, otherwise you break GemStone, VisualWorks, and
>>>> GNU Smalltalk. The Seaside wiki has some nice documentation of how to
>>>> correctly initialize objects (basically following the pattern of
>>>> Objective-C).
>>
>> ok, that was a bit hasty
>>
>>>> I think, problems 1, 3 (!), 4, 5 and to some extent also 2 could be
>>>> solved if the implementation was a bit more object-oriented. That is,
>>>> if you added a PPOmitParser that would dispatch from #parseOn: to some
>>>> other parsing method #parseOmittedOn: you wouldn't need all those
>>>> #ifTrue:ifFalse:.
>>>>
>>>>> I pushed my solution to the petitparser repos. I didn't add full support
>>>>> for flatten.
>>>>
>>>> Did you see #map: and #permutation:? Both allow you do the same in a
>>>> less invasive way:
>>
>> Of course in my example this is straight forward, but in a bit more complex
>> parser with a couple of options or intermediate tokens you don't want it
>> would be nicer to directly specify it on the parser nodes. And in such a
>> sense only affect how flatten works...
>>
>>>> parser := ($" asParser , $" asParser negate star flatten, $" asParser).
>>>> parser map: [ :begin :inner :end | inner ]
>>>>
>>>> or
>>>>
>>>> parser := ($" asParser , $" asParser negate star flatten, $" asParser).
>>>> parser permutation: #(2)
>>>>
>>>> Additionally, did you see the experimental binding/capturing
>>>> functionality in PetitBeta? This kind of provides something much more
>>>> general and (I believe) much more powerful without the above
>>>> drawbacks. Bind-Capture allows you to bind certain parse results
>>>> anywhere down the tree to names and directly access them later on in a
>>>> capture block. It also deals with unpacking and reshuffling
>>>> collections automatically, check the tests for that.
>>>>
>>>> Your example would look like:
>>>>
>>>> parser := ($" asParser , ($" asParser negate star flatten bind:
>>>> #inner) , $" asParser).
>>>> parser capture: [ :inner | inner ]
>>
>>
>> Ah cool, this is indeed a bit nicer, didn't have at the new branch yet… will
>> do ;)
>>
>>
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
>
