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

[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
>> 
>>