[Haskell-cafe] Throwback of inferred types

Jon Harrop jon at ffconsultancy.com
Sun Jan 20 17:18:52 EST 2008


On Sunday 20 January 2008 22:06:04 Duncan Coutts wrote:
> On Sun, 2008-01-20 at 21:02 +0000, Jon Harrop wrote:
> > On Sunday 20 January 2008 21:02:04 gwern0 at gmail.com wrote:
> > > On 2008.01.19 19:11:13 +0100, Peter Verswyvelen <bf3 at telenet.be>
> > > scribbled
> >
> > 1.4K characters:
> > > > I would find it most useful to get type inference information on the
> > > > fly, even when not all of the code compiles correctly yet.
> > >
> > > Does that make sense? If the code doesn't compile, then how could any
> > > type-inference be trustable?
> >
> > Note that this functionality continues to be widely used in other
> > functional languages, e.g. SML, OCaml, F#. I can't think why Haskell
> > would be any different.
>
> Really? That's pretty cool. How does it work?

With OCaml you compile with the -dtypes option and inferred types are 
available in the IDE. For example, in Emacs you hit C+C C+T to get the type 
of the subexpression under the cursor. In OCaIDE, this is provided as 
graphical throwback of the subexpression under the mouse in Eclipse and 
repeat type checking passes are automated.

In F#, the Visual Studio mode provides the same functionality.

I believe MLton provides the same functionality for SML.

> Does it use Achim's suggestion of replacing expressions which fail to
> type with new type vars and at runtime an error message with the type
> error?

I believe it just dumps the types of all subexpressions to file with source 
code locations as they are inferred. In the case of broken code, the given 
type is either non-existant (nothing is given because nothing has been 
inferred), more general that it should be (because later unifications have 
not yet been made) or wrong (which is most valuable when debugging type 
errors).

> Or do they use something more hacky that we could also implement 
> quickly?

OCaml generates .annot files that look like this:

"nth.ml" 6 68 78 "nth.ml" 6 68 91
type(
  string -> int Gram.Entry.t
)
"nth.ml" 6 68 92 "nth.ml" 6 68 97
type(
  int Gram.Entry.t
)
"nth.ml" 6 68 92 "nth.ml" 6 68 97
type(
  string
)
"nth.ml" 6 68 72 "nth.ml" 6 68 97
type(
  int Gram.Entry.t
)

> That would be cool. Then I can run the bits of my program that still
> work. It'd make the editor/interpreter session rather more "live".

Exactly.

> How close do the IDEs/emacs-modes for SML, OCaml, F# come to that? What
> are we missing out on? :-)

You're missing out on a lot if this isn't available for Haskell yet. I didn't 
realise just how invaluable this is until a system upgrade broke it and I 
really struggled to write OCaml code without it: I don't know how I managed 
before!

Some people argue that functional programming languages don't need decent 
development environments but, having used F#, I know better...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e


More information about the Haskell-Cafe mailing list