Lambda (was: Refactoring in Tunes)
20 Jan 2000 19:34:28 +0100
>>>>> "billy" == btanksley <email@example.com> writes:
>> In oher words, your system is correct, and mine is broken just
>> because if different from yours ? :-)
billy> Yes. Just as broken as if it didn't understand the
billy> annotation which says "the following name is the title of a
billy> new definition." Just as broken as a C system would be if it
billy> didn't understand the keyword 'int' when used in the
billy> declaration of a parameter.
But our system is not designed yet, so we can decide what we want to
put in it.
billy> ML functions have one and only one type. However, ML's infix
billy> operators are overloaded, and thus textually ambiguous.
billy> define square x :- x*x;
billy> is of ambiguous type, and the compiler will refuse to accept
billy> it (is it float or int?). The solution is simple: the
billy> programmer provides a type annotation at any point in the
billy> program where it helps. For example, this:
billy> define square:(int->int) x :- x*x; define square x:int :-
billy> x*x; define square x :- x*x:int; define square x :-
billy> (I think caml may have the same characteristics, by the way.
billy> I don't know, having never used caml.)
billy> Of course, the oddity here is the result of what I would
billy> consider a design mistake -- overloading is a strange action
billy> in a type-inferenced language, doubly so when you realise
billy> that in spite of the overloading you still have to specify
billy> which version of the function you're going to use.
Overloading is a UI concept. Therefore I think it's bad to put that in
a language. Because I think it's evil to put UI stuff in a
language. (but you probably know tha now :-)
billy> Perhaps a language without overloading would not require
I can even imagine that ML could accept "define square x :- x*x;" and
define as many overloaded function as possible.
billy> I don't understand why you're suggesting it.
>> I think that separation of concerns is a very good principle.
billy> Drinking water is a good principle, too. But that doesn't
billy> mean I do it instead of designing a language.
I think that separation of concerns is a very good principle in
designing computer systems, and that includes computer languages.
>> Proving that some code has some properties should not be mixed
>> with interpreting that code.
billy> But nobody's proving anything about the code -- these type
billy> annotations are used to help the programmer write to the
billy> interface, and allow the compiler to do typechecking.
Isn't typechecking proving that no type errors will occur if you run
the program ?
billy> I don't feel good about splitting these things, but would an
billy> acceptable compromise be a C-style header file? You lose a
billy> LOT of power that way (since you can't place the annotations
billy> anywhere in the source),
What's so powerful about that ?
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.