[m-dev.] Re: Visual vs total arity clash example [fwd]

[Fergus Henderson]

On 27-Jan-2000, Peter Nicholas MALKIN <pnmalk at students.cs.mu.oz.au> wrote:
> Fact: to allow for *OLD* code using DCGs or code written explicitly using
> io__state, to still work with the new io.m predicates that use EDCGs I must
> allow EDCG predicates to be called in expanded form.

OK...

> Consider the following code:
> 
> ****************** Old Code **************************************************
> 
> 	% app_all appends two lists onto the front of another list.
> :- pred app_all(list(char), list(char), list(char), list(char)).
> :- mode app_all(in, in, in, out) is det.
> 
> app_all(Cs1, Cs2, L0, L2) :-
> 	app(Cs2, L0, L1),	% This is an ambiguity error
> 	app(Cs1, L1, L2).	% This is an ambiguity error
>
> :- pred app(list(char), list(char), list(char)).
> :- mode app(in, in, out) is det.
> 
> app([], L0, L1).
> app([C | Cs], L0, L2) :-
>         app(Cs, L0, L1),	% This is an ambiguity error
>         L2 = [C | L1].

You lost me here.  Why are those three calls to app/3 ambiguity errors?

> > Finally, there's very little benefit to allowing users to write
> > expanded clauses, at least compared to the cost.  Can you give a
> > realistic example of a clause that's somehow better written already
> > expanded?  Remember, the cost is that you have to understand how EDGs
> > will be expanded in order to know whether two predicates in the same
> > module with the same name and different arities conflict.
> 
> Yes, I can.
> 
> The situation where you wish to use :- instead of -->> is for pragma c_code.
> Actually this applies always, maybe some extra syntax for pragma c_code is
> needed here. 
> 
> e.g.
> 
> **********************************************************************
> 
> :- pred io__rename_file_2(string, string, int, string) +hidden(changed(io)).
> :- mode io__rename_file_2(in, in, out, out) is det.
> 
> :- pragma c_code(io__rename_file_2(OldFileName::in, NewFileName::in,
>                 RetVal::out, RetStr::out, IO0::di, IO::uo),
>                 [will_not_call_mercury, thread_safe],
> "{
>         RetVal = rename(OldFileName, NewFileName);
>         ML_maybe_make_err_msg(RetVal != 0, ""rename failed: "",
>                 MR_PROC_LABEL, RetStr);
>         update_io(IO0, IO);
> }").

I think that if we're going to support hidden argument
syntax, we should extend that support to pragma c_code.
That is, we should allow the user to write code like this:

:- pragma c_code(io__rename_file_2(OldFileName::in, NewFileName::in,
                RetVal::out, RetStr::out) + hidden(changed(io)),
                [will_not_call_mercury, thread_safe],
	...;
	update_io(io, io);
}").

Well, the io__state is not a good example.
But the idea is that if you add `+hidden(changed(foo))',
then `foo' would be accessible as an ordinary C variable
from within the C code fragment in the `pragma c_code'
declaration.  A better example might be

	:- pragma c_code(incr_counter + hidden(changed(counter)),
                [will_not_call_mercury, thread_safe],
	"
		counter++;
	").

> I really do not think that whether a predicate uses EDCGs or not should
> dictate to the programmer where they put it in a module. This is too
> artificial a constraint that could reduce program readability.

Peter Schacte was only talking about the _expanded_ form going
in sub-modules named "EDCG".  The programmer would still be free
to put the form with hidden variables in any module he or she
liked.

So I don't think that is a good argument against Peter Schachte's
suggestion.  But I think there would be major implementation
difficulties in implementing his suggestion in the current
implementation.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------