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

[Jeffery, C. <cli...@nm...>]

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
>