
Hi all, I have some quick questions for the type theory people: If I write an expression: (if .. then 23 else "Erk") In Haskell this would be an error, but perhaps I can assign it the type 'Top' (or 'Any') and then use reflection ala Data.Dynamic to inspect the type of this object at runtime and cast it back to something useful... But if I write: isEven "Erk" where isEven :: Int -> Bool isEven i = case i of 1 -> False 2 -> True ... Then this would be a genuine type error, because the case-expression demands an actual Int at runtime. Questions: 1) Could I perhaps wave my arms around and say something about the Int in the type of isEven being in a contra-variant position? Is this what is actually happening?, and can someone point me to a good paper? 2) This seems simpler than real intersection types, which I know are problematic. If I only want 'Top' and not a real object system like in Scala or Java, then can I just add this to a HM/unification style inference algorithm and expect it to work? I'm thinking the unifier only needs to know the variance of the types it's unifying to decide whether to throw an error or return Top - or will there be problems with higher order functions etc? I had a read through the subtyping chapter in "Types and Programming Languages" by Pierce - it gives the typing rules but don't mention inference or implementations. Scala seems to have this (http://www.scala-lang.org/intro/variances.html) but as I understand it, their system doesn't support full type inference without user supplied annotations... BTW: searching for 'the any type' in Google helps even less than you might expect :) Thanks, Ben.

Ben Lippmeier wrote:
If I write an expression: (if .. then 23 else "Erk")
In Haskell this would be an error, but perhaps I can assign it the type 'Top' (or 'Any') and then use reflection ala Data.Dynamic to inspect the type of this object at runtime and cast it back to something useful...
can someone point me to a good paper?
I have absolutely no clue about the subject, but I would start a "bibliographic paper chase" with Philip Wadler, Robby Findler. Well-typed programs can't be blamed. http://homepages.inf.ed.ac.uk/wadler/topics/links.html#blame-icfp Talk slides from Bay FP meeting: http://bayfp.org/talks/slides/philip_wadler_1_jan_08_bayfp.pdf Regards, apfelmus

On Thu, Apr 3, 2008 at 9:58 AM, Ben Lippmeier
Hi all, I have some quick questions for the type theory people:
If I write an expression: (if .. then 23 else "Erk")
In Haskell this would be an error, but perhaps I can assign it the type 'Top' (or 'Any') and then use reflection ala Data.Dynamic to inspect the type of this object at runtime and cast it back to something useful...
But if I write:
isEven "Erk"
where isEven :: Int -> Bool isEven i = case i of 1 -> False 2 -> True ...
Then this would be a genuine type error, because the case-expression demands an actual Int at runtime.
Questions: 1) Could I perhaps wave my arms around and say something about the Int in the type of isEven being in a contra-variant position? Is this what is actually happening?, and can someone point me to a good paper?
This is related to "gradual typing". I don't know how much work has been done into inference for gradual typing, but I'll bet you could hack on the HM algorithm a little and get something usable. Here's a relevant paper: http://www.cs.colorado.edu/~siek/pubs/pubs/2006/siek06:_gradual.pdf Enjoy. Luke

On Apr 3, 2008, at 10:41 AM, Luke Palmer wrote:
On Thu, Apr 3, 2008 at 9:58 AM, Ben Lippmeier
wrote: Questions: 1) Could I perhaps wave my arms around and say something about the Int in the type of isEven being in a contra-variant position? Is this what is actually happening?, and can someone point me to a good paper?
This is related to "gradual typing". I don't know how much work has been done into inference for gradual typing, but I'll bet you could hack on the HM algorithm a little and get something usable.
Here's a relevant paper: http://www.cs.colorado.edu/~siek/pubs/pubs/2006/siek06:_gradual.pdf
Yeah, there is work on inference for gradual types: http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1039-0... Aaron
participants (4)
-
Aaron Tomb
-
apfelmus
-
Ben Lippmeier
-
Luke Palmer