Custom operators in the revised syntax
[
Home
]
[ Index:
by date

by threads
]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
Date:   (:) 
From:  Jon Harrop <jon@f...> 
Subject:  Re: [Camllist] Custom operators in the revised syntax 
On Saturday 12 May 2007 10:49, you wrote: > What your system should do when encountering: > > let double x = x + x;; F# ossifies global definitions to defaults (if any) or type errors. In this case: val double : int > int If the definition had been: let first a = a.[0];; then there is no default and it would ask for clarification as to the type of "a" (is it an array, hash table, vector etc.). > double 1;; Fine. > double 1.1;; > double (Vector.from_array [ 1.1; 2.2; 3.3 ]);; Both static type errors. This seems to work very well by minimizing confusion, maximizing performance (everything is resolved statically) and letting me write mathematical expressions concisely. If the definition of "double" is nested then its type is not ossified immediately but will unify to "int" at the application "double 1;;", so the next two calls are static type errors just as they are in OCaml. There are other problems, like do we generalize from: val ( * ) : 'a > 'a > 'a to: val ( * ) : 'a > 'b > 'c e.g. "scalar * vector > vector"? You also have ambiguity with conventional syntax. Does "vector * vector" mean dot, cross or elementwise product? Lessons can be learned from languages like Matlab, where people often accidentally add a scalar to each element of a vector (so we know that would be a useful type error). Potentially, you could even overload "f x" to allow it to mean multiplication when "f" is a numeric and not a functional value. So the type could go through ['a > 'b  int  float  ...]. I've written about 100k LOC of F# code now and I haven't had a single nontrivial type problem caused by overloading. So I'd definitely question the conventional view that overloading and inference do not sit well together. Worst case, the compiler asks for a type annotation...  Dr Jon D Harrop, Flying Frog Consultancy Ltd. The F#.NET Journal http://www.ffconsultancy.com/products/fsharp_journal/?e