Re: [m-users.] IO argument clobbering

Volker Wysk <[email protected]> Mon, 17 Jul 2023 17:39:37 +0200
Newsgroups	gmane.comp.lang.mercury.general
Message-ID	<[email protected]>
Am Montag, dem 17.07.2023 um 16:26 +0100 schrieb Sean Charles
(emacstheviking):
> [A]  :- type callback == (pred(world, world, io, io)).
> [B]  :- inst callback == (pred(in, out, di, uo) is det).
> 
> [C]  :- pred run_loop(
>       callback::in(callback), world::in, world::out, io::di, io::uo
>   ) is det.
> 
> In an attempt to demystify it all then, at point [A] I am defining an
> equivalence type which is merely a Mercury way of defining something
> similar to a C preprocessor macro in that the use of callback *as a type*
> specified will just cause the compiler to use the value on the right hand
> side of '=='. That much I understand, I think!

That's correct.

> At [B], I am defining an instantiatedness tree, that although it has the
> same name as that used at [A], bears no actual relationship to it in any
> way.

That's right, but it does have a relationship. The name could be different,
but it happens to be the inst of a value of the type you've defined in [A].

> At [C], I am declaring that run_loop/5 is a predicate that takes an
> argument of *type* callback, and that that it is an input, and that the
> input MUST have the instantiatedness defined by the definition at [B], the
> first use of callback being the type, and the in(callback) is stating that
> the value MUST be ground i.e. contain no free variables.

The inst in(callback) happens to have no inst variables. It could have some,
for instance:

:- inst callback == (pred(in(I), out(I), di, uo) is det).

But the "in(callback)" inst isn't ground. It's a higher order inst. Only the
"in" with zero arguments is an abbreviation for "in(ground)". 

Bye,
Volker



> 
> Is that not even wrong, or close?
> 
> Despite it making me feel dumber than dumb, I continue to love Mercury for
> all that it offers! I did not have the luxury of doing a 'comp-sci degree'
> in my youth, I am self-taught which, whilst fun, can at times be so
> desparately discouraging when the manual content is written in such high-
> level language. If it wasn't for the high calibre and warmth of this
> mailing list I think I may have given up in my first month with mercury, a
> few years ago now!
> 
> :D
> 
> Thanks.
> 
> 
> 
> > On 17 Jul 2023, at 16:07, Volker Wysk <[email protected]> wrote:
> > 
> > Am Montag, dem 17.07.2023 um 15:52 +0100 schrieb Sean Charles
> > (emacstheviking):
> > > Zoltan, Volker...... yes!
> > > 
> > > That makes it compile and run just fine.... I am not sure I fully
> > > comprehend but I will go and RTFM some more, that might help.
> > 
> > "in" is an abbreviation for "in(ground)". "ground" means normal data,
> > nothing callable. A predicate isn't ground. Its inst is like you have
> > defined it in your ":- inst callback == ...".
> > 
> > Cheers,
> > Volker
> > 
> > > 
> > > Thank you both.
> > > 
> > > 
> > > > On 17 Jul 2023, at 15:37, Zoltan Somogyi <[email protected]>
> > > > wrote:
> > > > 
> > > > 
> > > > On 2023-07-17 16:27 +02:00 CEST, "Sean Charles (emacstheviking)"
> > > > <[email protected]> wrote:
> > > > > :- type callback == (pred(world, world, io, io)).
> > > > > :- inst callback == (pred(in, out, di, uo) is det).
> > > > > 
> > > > > :- pred run_loop(
> > > > >   callback::in, world::in, world::out, io::di, io::uo
> > > > > ) is det.
> > > > 
> > > > Without compileable example code I cannot be sure, but I think
> > > > the problem is the "callback::in" in the declaration of run_loop.
> > > > What happens when you replace it with "callback:in(callback)"?
> > > > The mode checker needs this to tell it the mode of the higher order
> > > > arg.
> > > > 
> > > > Zoltan.
> > > 
> > > _______________________________________________
> > > users mailing list
> > > [email protected]
> > > https://lists.mercurylang.org/listinfo/users
> > 
> > _______________________________________________
> > users mailing list
> > [email protected]
> > https://lists.mercurylang.org/listinfo/users
> 
> _______________________________________________
> users mailing list
> [email protected]
> https://lists.mercurylang.org/listinfo/users

_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users
signature.asc (application/pgp-signature, 833 B)