🚀 go-pugleaf

In article <MFX.92Oct7105619@lenin.cs.tu-berlin.de>, mfx@cs.tu-berlin.de (Markus Freericks) writes:

< Quotes how I implement curried functions in a compiled graph 
  reduction implementation >

|> Your argumentation is based on a graph reduction implementation. I
|> would think that such are only feasible for lazy languages, which SML
|> (which started the thread) is not.

Hmm, that may be right, at least in a language like SML that supports
ref types and :=. Then evaluation order becomes important. What a pain!

< I asked how tuples were optimized in SML >

|> Well, if you have a CPS-based compiler, function call arguments will
|> usually be held in registers, only closures have to be created on the
|> heap (or on the stack, if they provably don't escape). And in such an
|> environment, tupling is much cheaper! (Again, it is of course true
|> that a very naive approach would allocate tuples as data objects on
|> the heap.)

It seems that everybody knows the tricks needed to implement the 
idioms that are common in their language of choice, and tacitly
assumes that these tricks have been used, at the same time expecting
all other languages/idioms to have been implemented naively. 

< Discussion of type signatures >

|> Well, in my SML programs (I am writing a partial evalutor) i tend to
|> have functions of 4-5 parameters, and missing parameters are one of
|> the most typical typing errors I make. Of course, type check would
|> catch most of these in a currying language, too. 

In fact, the type checker catches all of these errors in either case,
but I grant that the error messages probably will be somewhat more
informative for tupling errors (e.g. 'Unable to unify ('t2133 * 't2150)
with ('t2133 * 't2133 * 't2165)' vs. 'Unable to unify (Char) with 
('t2133 -> 't2156)).

|> Well, for me the question is: does a language *force* me to use
|> curried functions, or does it offer tupled functions, too? For me,
|> tupling is a safety device, a little comparable to typing, that makes
|> it possible to say "this function should be called with so many
|> arguments". A language that does not support this device (or makes it
|> overtly expensive, e.g. by explicitly creating/desctructing tupel
|> objects) lacks a feature that makes life easier.

So, the conclusion is: provide and optimize both tupling and currying!
Your wish is my command :-)

Cheers,
         Karl-Filip

------------------------------------------------------------
Make the frequent case fast, and the fast case frequent!