Lambda (was: Refactoring in Tunes)

btanksley@hifn.com btanksley@hifn.com
Fri, 21 Jan 2000 14:25:17 -0800


> From: Laurent Martelli [mailto:martelli@iie.cnam.fr]
> Subject: Re: Lambda (was: Refactoring in Tunes)
> >>>>> "billy" == btanksley  <btanksley@hifn.com> writes:
>   >> I can even imagine that ML could accept "define square x :- x*x;"
>   >> and define as many overloaded function as possible.

>   billy> I imagined that as well at the time.  There are a few
>   billy> problems with doing that -- for example, the number of
>   billy> functions grows exponentially.  The type inferencing is
>   billy> already NP-complete.

> So type annotations are just an optimization hint and are not strictly
> needed for semantics of the language.

They're needed for the semantics -- the definition of ML states that only
one function will be created.  It also states that the typechecking is
strong.  If you relax the "only one function" restriction, how many will you
allow?  The number of posible functions grows exponentially with the
complexity of the function (and all of the functions on which it depends).

A simple typo would result in accidentally overloading the function, with no
error or warning possible.  Later on, you could mistakenly use the wrong
type while calling the function, and it would be accepted without error,
producing the wrong behavior -- or, worse yet, you might use the RIGHT type
and have it accepted by the wrong function.

And as another complication, ML provides type parameters, to allow you to
reason about the types of passed-in variables.  Automatic overloading would
make this harder.

>   >> Anyway, if you have somewhere : (defun f (x) (* x x)) and
>   >> somewhere else (deftype f (int int))

>   >> It's very easy for a GUI to gather the 2 thing and display int
>   >> f(int x) = x * x ; The fact that the annotation refers to f
>   >> places it next to f. It's up to the UI to display this in a
>   >> convenient manner.

>   billy> I don't get it, though.  Why would we deliberately make
>   billy> things more complex?  Why shouldn't we design for simplicity?

> My design makes the core language simpler since it does not have to
> deal with type annotations. 

But the language already has to deal with types anyhow -- why not give the
programmer some tools to control the language in that respect?

Note that I object to a typeless dialect; Joy can already do that today, and
I like Joy a LOT.

> Laurent Martelli

-Billy