[kelbt-users] [feature proposal] autocommit mode

[Adrian Thurston]

What I mean is, how does the user decide on which productions to place a 
'hold'?

-Adrian

Elijah Epifanov wrote:
> I think the rule of least surprise wins here:
> 
> In autocommit mode:
> append `commit` to every production except those marked with `hold`.
> 
> It's that simple... both for user and for kelbt.
> 
> 2009/2/15 Adrian Thurston <thurston at complang.org>:
>> But how do you choose the production(s) to place the hold on? That's the
>> problem I'm seeing. Every choice point in a backtracking LR is covered
>> by many productions above it and I think a hold would need to be placed
>> on every one of those.
>>
>> Maybe we have different views of 'commit' at this point ... In kelbt a
>> commit clears everything below it in the parse tree. Perhaps in the
>> autocommit mode this should not be the case?
>>
>> -Adrian
>>
>> Elijah Epifanov wrote:
>>> Hey, sorry for the long delay.
>>>
>>> I think it should be just a flag at the end of a rule (where commit is
>>> implied in autocommit mode).
>>> e.g.:
>>>
>>> autocommit;
>>>
>>> # Second level supports multiplication.
>>> F: tok_number tok_mult F hold try { ... };
>>>
>>> I think hold is a correct antonym to commit in this case.
>>>
>>> 2009/1/25 Adrian Thurston <thurston at complang.org>:
>>>> I'm curious if it would be hard to tell where to put the 'noncommit'
>>>> flags. What do you think?
>>>>
>>>> -Adrian
>>>>
>>>> Elijah Epifanov wrote:
>>>>> 2009/1/23 Adrian Thurston <thurston at complang.org>:
>>>>>> So let me see if I understand ... autocommit would cause all alternative
>>>>>> parses to be discarded on every reduction, with the option to disable it
>>>>>> on specific reductions? This would make Kelbt behave like standard Yacc
>>>>>> by default, with the kelbt behaviour turned on only where needed?
>>>>> exactly, like any ordinary lalr parser
>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> Elijah Epifanov wrote:
>>>>>>> There's no need to delay commit when parsing an unambiguous language,
>>>>>>> therefore every rule will need (if efficiency is of concern) to commit
>>>>>>> after reduce.
>>>>>>>
>>>>>>> It would be convenient to set an auto-commit mode on on per-grammar
>>>>>>> basis and (rarely, if at all) disable it for specific portions when
>>>>>>> needed.
>>>>>>>
>>>>>>> %%
>>>>>>> # Second level supports multiplication.
>>>>>>> F: tok_number tok_mult F commit try { ... };
>>>>>>> F: tok_number commit try { ... );
>>>>>>> };
>>>>>>> %%
>>>>>>> ->
>>>>>>> %%
>>>>>>> autocommit;
>>>>>>>
>>>>>>> # Second level supports multiplication.
>>>>>>> F: tok_number tok_mult F try { ... };
>>>>>>> F: tok_number try { ... };
>>>>>>> %%
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> kelbt-users mailing list
>>>>>>> kelbt-users at complang.org
>>>>>>> http://www.complang.org/mailman/listinfo/kelbt-users
>>>>>> _______________________________________________
>>>>>> kelbt-users mailing list
>>>>>> kelbt-users at complang.org
>>>>>> http://www.complang.org/mailman/listinfo/kelbt-users
>>>>>>
>>>>> _______________________________________________
>>>>> kelbt-users mailing list
>>>>> kelbt-users at complang.org
>>>>> http://www.complang.org/mailman/listinfo/kelbt-users
>>>> _______________________________________________
>>>> kelbt-users mailing list
>>>> kelbt-users at complang.org
>>>> http://www.complang.org/mailman/listinfo/kelbt-users
>>>>
>>> _______________________________________________
>>> kelbt-users mailing list
>>> kelbt-users at complang.org
>>> http://www.complang.org/mailman/listinfo/kelbt-users
>> _______________________________________________
>> kelbt-users mailing list
>> kelbt-users at complang.org
>> http://www.complang.org/mailman/listinfo/kelbt-users
>>
> 
> _______________________________________________
> kelbt-users mailing list
> kelbt-users at complang.org
> http://www.complang.org/mailman/listinfo/kelbt-users