Re: [Unicon-group] Parser package and Unicon compiler grammar/semantic action changes

[Richard H. M. <rhm...@gm...>]

Since "UniKRon" also uses a modified parser, I appreciate Bruce's work.
But I have not tried to coordinate with Bruce
because UniKRon changes the grammar in addition to changing the actions.

Richard H. McCullough
http://ContextKnowledgeSystems.org
What is your context?


On Thu, Jan 7, 2021 at 9:52 AM Jeffery, Clinton <cli...@nm...>
wrote:

> Hi Bruce,
>
> I don't know how many private replies your message got, but since you
> asked for feedback on the list I want to make sure you got at least one
> public feedback.  Your recent pull request, which updates and therefore
> makes a major improvement to the uni/parser library, was approved by me.
> While I endorse your soliciting additional feedback from the group,
> probably not too many people are using uni/parser, so you might not get
> much feedback.
>
> I made a few suggestions regarding usability that were intended to give
> you ideas of what uni/parser could look like that would cause me to become
> enthusiastic about fully documenting it and maybe switching the Unicon
> translator over to using it. The fact that your actions mechanism is
> general enough that I might be able to do that means that you have made a
> significant advance over the old uni/parser. However, I think some tweaks
> to what you've done will improve it. I hope we can come up with a mechanism
> that does not mandate hardwired link directives in the middle of the .y
> file, and I hope we come up with a set of default action procedures and
> allow end-users to override some actions while using the default for
> others.  Whether any of these tweaks happen or not, I do not have
> reservations about committing your pull request.
>
> Cheers,
> Clint
>
> On Tue, Jan 5, 2021 at 4:38 PM Bruce & Breeanna Rennie <
> br...@dc...> wrote:
>
>> Good morning to all,
>>
>> I am not sure how many of you would be looking at the pull requests for
>> the https://github.com/uniconproject/unicon. I have recently submitted a
>> pull request that affects the parser package in the Unicon distribution.
>>
>> Clinton has made some very salient observations on the code changes that
>> I have made and I think his observations need to be seriously taken into
>> consideration before pull request gets into the Unicon system. My
>> reasons for the changes I have made are given below and I fully
>> recognise that I do not, in my normal programming, follow the historical
>> code standards that are used in the Unicon project and that my normal
>> programming does not suit what others feel to be appropriate. I am
>> putting forward my response (as below) for discussion and I am asking
>> for any changes that everyone feels need to be made to the pull request
>> to have your say now, so that what gets implemented meets the relevant
>> leadership and community expectations. I am happy to make changes to the
>> code as necessary. I am one person and my opinions as to what good code
>> is is just my opinions.
>>
>> The following is my response to the concerns and observations raised by
>> Clinton as I want Unicon to obtain a higher profile and use amongst the
>> wider programming community.
>>
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> I understand your concerns here. The reason for this approach is that it
>> allows for a single generic grammar file to be defined that is common
>> across any application that needs to analyse Unicon programs. For many
>> of the productions, there is no requirement to change the semantic
>> actions thus defined, especially those actions that are simply $$ := $1.
>> However, due to the requirements of the iconc compiler and the analysis
>> it requires, there are a number of semantic actions that were requiring
>> very specific additions.
>>
>> My first attempt at designing the semantic actions showed up some
>> problems with the approach I was using in creating a common semantic
>> action for multiple productions. After considering the needs of the
>> parser package, the Unicon compiler (icont/iconc), I made a decision to
>> just define an action for each and every production and allow the
>> programmer to define whatever he/she wanted in terms of changing the
>> relevant semantic action, while keeping the grammar file unchanged. It
>> has put the process one level indirection level away from the grammar
>> file.
>>
>> The other thing I found was that all parameters for each production are
>> passed to the semantic action and this allows the specific parse tree
>> produced by the semantic action to be determined by the programmer
>> outside of changing the grammar file. I am able to restructure the parse
>> tree as I see fit via the semantic actions without affecting the grammar
>> file.
>>
>> Now, with the above said, this may not fit in with how other people do
>> things and as such, if the specific structure I have created here
>> doesn't suit then I do not have any problems it being changed. I just a
>> long experience having had to support other people code and required
>> major changes to keep it operational effective and I have found by
>> experience that making code not have unexpected consequences is a long
>> term maintenance feature. It ends up requiring less work to understand
>> what will happen when changes are made.
>>
>> I had a similar view when I made the changes to the parse tree scanning
>> procedures that Robert Parlett had written. They worked with the
>> specific parse tree structure he had implemented, but became difficult
>> to use when the parse tree changed. What I am trying to aim for is a
>> simplicity in the general structure of the code (or at least simplicity
>> from my perspective). However, I do understand that what I consider
>> simplicity and easily understandable is not going to be so considered by
>> others. There is a place for "trickiness" and complexity, but in
>> "normal" code I do try to avoid it or at least make it as uniform as I
>> can.
>>
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> regards
>>
>> Bruce Rennie
>>
>>
>> _______________________________________________
>> Unicon-group mailing list
>> Uni...@li...
>> https://lists.sourceforge.net/lists/listinfo/unicon-group
>>
> _______________________________________________
> Unicon-group mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>