[m-users.] Concise syntax for initialising and updating discriminated union types

[Sean Charles (emacstheviking)]

I am a bot

> On 19 Jul 2022, at 09:40, Volker Wysk <post at volker-wysk.de> wrote:
> 
> Wow. Your answer took only 47 seconds.  :-))
> 
> Am Dienstag, dem 19.07.2022 um 09:37 +0100 schrieb Sean Charles
> (emacstheviking):
>> Me too! It was just a suggestion as I know you have an interesting view on things.
>> 
>>> On 19 Jul 2022, at 09:37, Volker Wysk <post at volker-wysk.de> wrote:
>>> 
>>> Am Montag, dem 18.07.2022 um 21:43 +0100 schrieb Sean Charles
>>> (emacstheviking):
>>>> Ah, Volker, I also forgot to mention this, term rewriting in the samples folder :-
>>>> 
>>>> ./mercury/mercury-srcdist-22.01/samples/expand_terms.m
>>>> 
>>>> If you could bend that to your will then you surely could create some kind of more pleasing record/field updating for your code.
>>>> I've played with it but not used it...yet.
>>> 
>>> I don't think this would be a good idea. It looks like a powerful tool, as
>>> far as I can tell. But it could easily make the code unintelligible. I'd
>>> rather stay with stock mercury than invent my own programming language. 
>>> 
>>> Bye,
>>> Volker
>>> 
>>>> Cheers
>>>> Sean.
>>>> 
>>>> 
>>>> 
>>>>> On 18 Jul 2022, at 19:57, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>>>>> 
>>>>> 
>>>>> 2022-07-19 04:35 GMT+10:00 "Volker Wysk" <post at volker-wysk.de>:
>>>>>>>> 2. Some concise way to update multiple fields, like above. Maybe the
>>>>>>>> compiler could additionally generate field update predicates for the fields
>>>>>>>> (like above), similar to field update functions.
>>>>>>> 
>>>>>>> This would be easier to implement, but one would want to design
>>>>>>> any such new feature carefully. For example,
>>>>>>> 
>>>>>>> - how do you specify which subset of the fields you want setter predicates for
>>>>>>> (in many situations, some fields should be read-only).
>>>>>> 
>>>>>> Couldn't this be done the same way as it's done for setter functions?
>>>>> 
>>>>> From the user's point of view, you could: you would write all the declarations,
>>>>> and the compiler would write all the definitions for you. From the compiler
>>>>> writer's point of view, extending the mechanism we now use to implement
>>>>> field access functions (both getters and setters) would not really work.
>>>>> This is because unnamed field get and set functions are just shorthand for unifications,
>>>>> which do not need entries in the predicate table, but getter and setter *predicates*
>>>>> obviously do need such entries. The bulk of the work of implementing getter
>>>>> and setter predicates would be setting up those predicate table entries,
>>>>> which is quite different from the existing code that rewrites things that look like
>>>>> calls to getter/setter functions into unifications.
>>>>> 
>>>>>>> You would also want some mechanism to control the names of the generated
>>>>>>> predicates, though a naming scheme consisting of {get,set}_<fieldname>
>>>>>>> would be a good default.
>>>>>> 
>>>>>> You could just use the field name as the predicate name in both cases, since
>>>>>> they differ in the arity.
>>>>> 
>>>>> Again, you could, but each line of code is read far more often than in it is
>>>>> written, so the wise tradeoff is to make reading easier, even if it costs a few
>>>>> keystrokes.
>>>>> 
>>>>> Zoltan.
>>>>> _______________________________________________
>>>>> users mailing list
>>>>> users at lists.mercurylang.org
>>>>> https://lists.mercurylang.org/listinfo/users