Lambda (was: Refactoring in Tunes)
21 Jan 2000 07:22:24 +0100
>>>>> "billy" == btanksley <firstname.lastname@example.org> writes:
>> But our system is not designed yet, so we can decide what we want
>> to put in it.
billy> Right. And I'm telling you what I think our system should
So do I :-)
billy> It sounds as though you're saying that for any standard we
billy> decide on, you would feel free to leave out parts of the
billy> standard, and then blame the standard-compliant programs for
billy> not running on your system.
No. I just think that we should define the best standard as possible.
>> 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.
>> Isn't typechecking proving that no type errors will occur if you
>> run the program ?
>> From an academic viewpoint, I suppose so. Most programmers find
>> it more
billy> useful when it proves that there IS a type error, and this is
billy> the use for which I designed this.
These are the two sides of the coin.
>> 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.