[m-dev.] Why does the language insist on explicit lambdas?

[Peter Schachte]

On Fri, May 11, 2001 at 03:55:15AM +1000, Fergus Henderson wrote:
> OK, so that was the old story.  But now that I think about it a bit
> more, I suppose the type checker doesn't handle all constraints eagerly
> any more.  In particular, type class constraints get delayed.  Maybe we
> could do something similar here, with a higher-order call adding a class
> constraint for some builtin type class constraint.  i.e. for
> 
> 	p(P, A) :- P(A).
> 
> we'd infer
> 
> 	:- pred p(T1, T2) <= call(T1, T2).
> 
> Then we'd just need to have some builtin instances of this type class
> for the builtin higher-order types.  Hmmm, interesting...
> I haven't thought through all the ramifications of this.

That would be nice.  But if that proves to be too much work, I think an
engineering solution (ie, a hack) would be much better than nothing.  How
about just specifying that F(A) always means fully applying F to A, not
partially applying it?  Ie, always type F(A) as F :: func(T1) = T, A :: T.
I expect partial application is much less common than full application, so
this may well be a 90/10 solution (10% of the work, 90% of the benefit).
And it doesn't preclude a proper solution at a later time.

-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  There is nothing so useless as doing
http://www.cs.mu.oz.au/~schachte/      efficiently that which should not be
Phone:  +61 3 8344 9166                done at all.
Fax:    +61 3 9348 1184                    -- Peter F. Drucker 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------