[m-dev.] HO List args: fold and unfold

[Ralph Becket]

doug.auclair at logicaltypes.com, Tuesday, 14 March 2006:
> [re: currying]
> >Because it's shorter and clearer :-)
> >	func(X, Y) = X^2 + Y
> >vs.
> >	compose((+), converse((^), 2))
> 
> That depends
> (http://www.cotilliongroup.com/man/combinators-man.html#ex-for-ralph):
> 
> vs:   ``b+`w* 
> which is shorter and clearer than either example
                       ^^^^^^^
Sorry, I can't agree with you on that point!

> >There is also a performance penalty with interpreting arity n
> >functions as unary functions returning arity n functions.
> 
> Yes, I know speed is a foundational issue for the Mercury team,
> but I'm willing to pay those two microseconds of runtime
> for the n minutes or hours saved during development (after all,
> I'm not talking just one 'sum-of-squares' coding exercise, we
> have modules that use curried functions in every clause of the
> predicate for data transformation -- one of these predicates
> has ~100 clauses).

Our position is that typing is cheap and reading is hard.  You can often
reduce the amount of typing by defining combinators for common HO idioms
in your application.  The reason why we don't have more in the library
is that we haven't seen other HO idioms enough times to agree that they
are general purpose rather than application specific.

> Also, this is a pay-as-needed feature.  
> Those who do no use cfoldl do not pay the curried function
> argument cost.  And, finally, currying can get pretty hairy,
> but most of it can be unwound with static analysis, so that
> there is actually no runtime cost, and compiler would do
> pretty much the same rewriting that it already does for
> regular HO arguments.
> 
> There.

Sure, it can be done and it may be done.  But at the moment we're too
busy to give proper consideration to the idea!

> I'll grant that not many non-Haskellers/MLers use currying
> regularly, if at all, and the number of people who use
> combinators day-to-day for real stuff is even smaller (I
> make number 3 in the world, I think).  So, I'll port this
> code from Prolog for my own use.  Should I submit it for
> inclusion into extras/?

I wonder whether adding operator sections a la Haskell might not achieve
90% of what you want for 1% of the syntax?  We've certainly considered
the idea in the past.

> >Is this what you're after:
> >:- func unfold(pred(T1, T2, T1)::in(pred(in, out, out) is semidet), T1::in) =
> >	(list(T2)::out) is det.
> >
> >unfold(P, A0) = ( if P(A0, X, A) then [X | unfold(P, A)] else [] ).
> 
> Sweet!  So is this function going into module list?

I'm not convinced I've got the interface quite right.  Would you care to
provide some examples of how it would be useful to you?

Cheers,
-- Ralph
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------