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

[Volker Wysk]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/users/attachments/20220719/5fce2205/attachment.sig>