On Saturday 12 May 2007 06:45, you wrote:
> On Sat, 2007-05-12 at 05:47 +0100, Jon Harrop wrote:
> > > I have only seen one algorithm for this an it was
> > > extremely complicated. If you know a better way I'd
> > > sure like to know what it is.
> >
> > AFAIK, you just change the unify to intersect sets of types.
>
> I have no idea how to unify in the presence of (undiscriminated)
> setwise union of polymorphic types. It seems a little easier
> if the types are restricted to a finite set of non-polymorphic
> types.

They are, aren't they? e.g. int or float.

If you write:

> let ipow3 x =
    let sqr x = x*x in
    x * sqr x;;
val ipow3 : int -> int

then F# gives the inner definition "sqr" a type like [int|float] as 'a -> 'a 
until it is resolved to int -> int. If you change the code with an outer 
annotation:

> let ipow3 x : float =
    let sqr x = x*x in
    x * sqr x
val ipow3 : float -> float

then it still works because the inner type specializes to float -> float 
rather than defaulting to int -> int. The outer definition of "ipow3" then 
becomes float -> float.

> If ANYONE knows an algorithm that can do unification with
> sets of types, that is, with a union type, I'd sure like
> to know it!

Isn't this exactly what polymorphic variants do?

> > I hadn't thought of that. I just discovered that you cannot add vectors
> > of vectors in F#, so it is probably 1st order only.
>
> Hmm, that's a bit surprising if your explanation above is correct,
> that is, if it resorts to dynamic typing if it can't resolve
> statically.

I don't think it resorts to dynamic typing. I think it just doesn't do static 
code explosion as C++ templates do. That isn't dynamic typing because the 
types are still checked statically.

I believe the F# standard library also does some run-time type based 
optimizations, like using specialized routines for vectors and matrices of 
floats. Again, this isn't really dynamic typing because it does not introduce 
any run-time errors.

So if you do:

  type 'a complex = {r: 'a; i: 'a}
  let zero_float = {r=0.; i=0.}
  let zero_float32 = {r=0.f; i=0.f}

then it doesn't generate type specialized code for float and float32 (same as 
OCaml). When you do:

  List.map ((+) 1)

OCaml does not use a version of List.map that is specialized for ints.

That isn't to say that the .NET JIT won't do the specialization itself, but I 
believe it does not currently do that.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e