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 [EMAIL PROTECTED] wrote: > > > On 2008.01.19 19:11:13 +0100, Peter Verswyvelen <[EMAIL PROTECTED]> > > > 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe