FW: [mercury-users] Records

[Lee Naish]

In message <199911100007.NAA06433 at hermes.otago.ac.nz>ROK wrote:
>	Ok, so you could apply a rule that if the
>	combination setter is defined, you use it, if not, you use the
>	individual ones.  But what happens when you're setting 3 members, and
>	there are setters defined for each individual field and for each
>	combination of two?  The compiler could choose any of the 3 pairs
>	together with the remaining individual setter, and could apply these
>	two setters in either order, for 6 possible choices.  Which one do you
>	choose?
>	
>There's the answer:  YOU choose, not the compiler.  It's an ambiguity.
>If the compiler tells you
>	R with {A=X, B=Y, C=Z}
>is ambiguous between uses of A:=, B:=, C:=, AB:=, BC:=, AC:=,
>then YOU choose which one you mean and write it that way:
>	R with {A=X} with {B=Y,C=Z}
>for example.

Maybe I'm a bit slow, but I can't figure out why the compiler would ever
tell you the above is ambiguous, and why only some multiple update
functions would be defined.  As I see it (with yet another syntax), the
meaning of

	R with (f1_is X and f2_is Y and f3_is Z)

is as follows.

'with' is (converse) function application (X with F means F(X))

f1_is, f2_is, f3_is are (automatically generated) single field update
functions, and they are curried; they are also prefix operators.

'and' is function composition: compose(f1_is(X), ...)


Should it be the case that the expressions compose(f1_is(X),f2_is(Y)) and
compose(f2_is(Y),f1_is(X)) denote the same function?  Yes!

Should the behaviour of the above two expressions be the same, with or
without fancy type/integrity constraint/admissibility checking turned on?
Yes!

Should the compiler generate the same code for all optimisation grades?
Not necessarily.

The compiler may generate code which temporarily violates
admissibility but this should not be observable.

We want a "non-strict" semantics for this kind of code, similar to code
in functional languages.  Take the following example:

f (a,b) = (1 div a, 1)
g (a,b) = (1, 1 div b)

q1 = (f.g) (0,0)
q2 = (g.f) (0,0)

(f.g) and (g.f) both map any pair of numbers to (1,1) - they can be
thought of as the same function and will behave identically in a
non-strict functional language.  However, if you think about how q1 and
q2 are likely to be executed, one computes the intermediate expression
(1,1 div 0) and the other computes (1 div 0,1).  Either or both of these
could be considered inadmissibile in a more strict language but this makes
reasoning about programs more difficult.

I think detailed discussion about record updates (and all kinds of other
things no doubt) with fancy constraints needs to come after agreement on
the semantics of Mercury with such constraints.  One starting point would
be http://www.cs.mu.oz.au/~lee/papers/sem3/ (which supports the truth
values true, false and inadmissible for basically Horn clause programs);
another would be a semantics for Mercury without such constraints (but
including higher order etc)...

And while someone else comes up with the three-valued higher-order
logical-functional semantics, we can keep ourselves busy arguing about
syntax - any more suggestions?-)

	lee
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------