[m-users.] Field access functions usage

[Dirk Ziegemeyer]

Hi Mark,
Hi Zoltan,

> Am 16.08.2019 um 04:56 schrieb Zoltan Somogyi <zoltan.somogyi at runbox.com>:
> 
> 
> 
> On Thu, 15 Aug 2019 23:04:46 +0200, Dirk Ziegemeyer <dirk at ziegemeyer.de> wrote:
>> init_foo = X :-
>>    X^field_1 = 5,
>>    X^field_2 = "bar".
> 
> Without declarations for the field functions, the compiler sees this
> as two unifications: X = foo(5, _), and X = foo(_, "bar"). This is effectively
> a Herbrand constraint satisfaction problem , which the compiler can solve.
> 
> In the presence of declarations for the field functions, one part of the compiler
> generates the definitions of those functions if the programmer does not provide
> those definitions, but the rest of the compiler just treats those functions as if
> they were any other function. This means that it does NOT try to use its knowledge
> of what the code of those functions is, since the programmer may decide to
> redefine them at any time.

Thank you both for your explanations and the solution.

As far as I understand, the function init_foo/0 gets de-sugared to

a) In absence of the compiler-generated access function:
init_foo = X :-
    X = foo(5, _),
    X = foo(_, "bar").

b) In presence of the compiler-generated access function:
init_foo = X :-
    field_1(X) = 5,
    X = foo(_, "bar").

Variant a compiles fine and b produces exactly the same error as:
init_foo = X :-
    X^field_1 = 5,
    X^field_2 = "bar".

The different de-sugaring of b is choosen to allow the programmer to redefine the field access functions.

Dirk