[m-users.] IO argument clobbering

[Peter Wang]

On Tue, 18 Jul 2023 02:09:12 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> On 2023-07-17 17:43 +02:00 CEST, "Volker Wysk" <post at volker-wysk.de> wrote:
> > Am Montag, dem 17.07.2023 um 17:39 +0200 schrieb Volker Wysk:
> >> 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)". 
> > 
> > Hmmm... Looks like I was confused about what "ground" means. 
> 
> In different contexts, "ground" means several related and similar
> but nevertheless slightly different things. Which meaning of "ground" people
> mean when they write that term is *usually* clear from the context, but not always.
> 

It's also easier if you explicitly say "ground term", "ground type" or
"ground inst". And then there is the phrase "a ground inst" vs the inst
named `ground' ...

> The standard meaning in logic programming theory is simply "a term that
> contains no variables", and all uses of "ground" include this meaning. But Mercury
> goes beyond standard logic programming theory by having types,
> including higher order types. When you write "ground" in a Mercury program,
> that occurrence of "ground" describes a term that contains
> no variables AND whose type is either not a higher order type,
> or is a higher order function type with the standard function mode
> (which is: all arguments are input, the return value is output).
> It cannot be a higher order predicate type, or a higher order function
> type with a nonstandard mode, because for those, you need to tell
> the compiler the modes of their arguments.

To clarify, you CAN approximate a higher-order term with the inst `ground',
because the term has no variables (variables essentially meaning "holes"
in the term that are not yet filled in).

What you can't do is CALL a higher-order term approximated by `ground'
because `ground' does not include any higher-order inst information.
(With one exception: you CAN call a higher-order function term because
in the absence of higher-order inst information, the standard function
mode will be assumed.)

Back to the original error:

    ui.m:193:   In clause for `run_loop(in, in, out, di, uo)':
    ui.m:193:   in argument 1 (i.e. the predicate term) of higher-order predicate
    ui.m:193:   call:
    ui.m:193:   mode error: variable `AppHandler' has instantiatedness `ground',
    ui.m:193:   expecting higher-order pred inst of arity 4.

I think we should try to include something like

    cannot call the higher-order term because the instantiatedness
    `ground' is missing higher-order inst information.

to help newcomers make the connection.

Peter