Throwback of inferred types

older
Invitation for MathematiKa '08 :...

Jon Harrop

19 Jan 2008 19 Jan '08

12:30 p.m.

Is it possible to get throwback of inferred types into Emacs or an IDE for Haskell? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

Show replies by date

gwern0＠gmail.com

19 Jan 19 Jan

12:42 p.m.

On 2008.01.19 17:30:50 +0000, Jon Harrop scribbled 0.2K characters:

...

Is it possible to get throwback of inferred types into Emacs or an IDE for Haskell?

-- Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Sure. I once hacked together quite a while ago a little function for haskell-mode which looked like: ,---- | (defun getHaskellFunctionTypeSignature () | (interactive) | (progn | (setq file-name buffer-file-name) | (setq functionName (thing-at-point 'word)) | (shell-command (concat "echo :t " functionName " | ghci -v0 -cpp -fglasgow-exts -w " file-name "|grep " functionName) t))) | (global-set-key "\C-c\l" 'getHaskellFunctionTypeSignature) `---- And I think haskell-mode has a better way of doing things somewhere in its inf-haskell.el. -- gwern Information II captain SAS BRLO unclassified of Audiotel Taiwan RSOC

Peter Verswyvelen

1:11 p.m.

The problem is that this only works when the complete source file compiles correctly no? I would find it most useful to get type inference information on the fly, even when not all of the code compiles correctly yet.

...

-----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- bounces@haskell.org] On Behalf Of gwern0@gmail.com Sent: Saturday, January 19, 2008 6:42 PM To: Jon Harrop; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Throwback of inferred types

On 2008.01.19 17:30:50 +0000, Jon Harrop scribbled 0.2K characters:

...
Is it possible to get throwback of inferred types into Emacs or an

IDE

...
for Haskell?

-- Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Sure. I once hacked together quite a while ago a little function for haskell-mode which looked like:

,---- | (defun getHaskellFunctionTypeSignature () | (interactive) | (progn | (setq file-name buffer-file-name) | (setq functionName (thing-at-point 'word)) | (shell-command (concat "echo :t " functionName " | ghci -v0 -cpp | -fglasgow-exts -w " file-name "|grep " functionName) t))) | (global-set-key "\C-c\l" 'getHaskellFunctionTypeSignature) `----

And I think haskell-mode has a better way of doing things somewhere in its inf-haskell.el.

-- gwern Information II captain SAS BRLO unclassified of Audiotel Taiwan RSOC

Jon Harrop

3:04 p.m.

On Saturday 19 January 2008 18:11:13 Peter Verswyvelen wrote:

...

I would find it most useful to get type inference information on the fly, even when not all of the code compiles correctly yet.

Yes. Is this not provided by any development environments then? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

Achim Schneider

5:54 p.m.

"Peter Verswyvelen" wrote:

...

The problem is that this only works when the complete source file compiles correctly no?

ghc could just insert appropriate calls to error everywhere it can't compile, so you can choose whether to fix the bugs by lexical or operational ordering, ecj (the eclipse compiler) does exactly that. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.

gwern0＠gmail.com

20 Jan 20 Jan

4:02 p.m.

On 2008.01.19 19:11:13 +0100, Peter Verswyvelen scribbled 1.4K characters:

...

The problem is that this only works when the complete source file compiles correctly no?

Yes. As I said, it's a very hackish solution - think of it as proof-of-concept.

...

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? It might be reliable if the error is in definitions which don't get called or otherwise used by the function you are asking after, but there are going to be edge-cases, I should think, where it would bite you. -- gwern Freeh ASU 32 CIO GGL Force 97 b in Macintosh

Jon Harrop

4:02 p.m.

On Sunday 20 January 2008 21:02:04 gwern0@gmail.com wrote:

...

On 2008.01.19 19:11:13 +0100, Peter Verswyvelen 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. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

Duncan Coutts

5:06 p.m.

On Sun, 2008-01-20 at 21:02 +0000, Jon Harrop wrote:

...

On Sunday 20 January 2008 21:02:04 gwern0@gmail.com wrote:

...
On 2008.01.19 19:11:13 +0100, Peter Verswyvelen 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? 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? Or do they use something more hacky that we could also implement quickly? like: foo = 3 bar = 'c' baz = foo + bar So we infer: foo :: Int foo = 3 bar :: Char bar = 'c' baz :: a baz = error "No instance for (Num Char) arising from a use of `+' at foo.hs:5:6-14" 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". How close do the IDEs/emacs-modes for SML, OCaml, F# come to that? What are we missing out on? :-) Duncan

Jon Harrop

5:18 p.m.

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@gmail.com wrote:

...
On 2008.01.19 19:11:13 +0100, Peter Verswyvelen 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

Bulat Ziganshin

21 Jan 21 Jan

3:03 a.m.

New subject: Re[2]: Throwback of inferred types

Hello Jon, Monday, January 21, 2008, 1:18:52 AM, you wrote:

...

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!

oh, yes, i have a really hard times debugging large chunks of new code. nothing works, ghc error messages are next to useless and the best thing i can do - is just to add type annotations everywhere in order to find where ghc and me thinks different -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Achim Schneider

20 Jan 20 Jan

4:34 p.m.

gwern0@gmail.com wrote:

...

Does that make sense? If the code doesn't compile, then how could any type-inference be trustable?

Why, of course it is trustable, because it's going to fail, and that means that the code has type a -> _|_. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.

Jonathan Cast

5:26 p.m.

On 20 Jan 2008, at 1:02 PM, gwern0@gmail.com wrote:

...

On 2008.01.19 19:11:13 +0100, Peter Verswyvelen scribbled 1.4K characters:

...
The problem is that this only works when the complete source file compiles correctly no?

Yes. As I said, it's a very hackish solution - think of it as proof- of-concept.

...
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? It might be reliable if the error is in definitions which don't get called or otherwise used by the function you are asking after, but there are going to be edge- cases, I should think, where it would bite you.

Even if it's not reliable, the compiler gives its error messages based on some form of partial type inference. It would be quite interesting, some times, to see what the compiler thinks the types are, when it gives a type error (this bit me recently trying polymorphic recursion: I had a long list of polymorphic functions defined without type signatures (since the names were clear enough), factored out some duplicated code, and wound up with a set of mutually recursive functions, one of which was polymorphically recursive. I'll dig the example up if you want (it's kind of compilcated). Knowing that the compiler had various types inferred correctly would have helped me zero in on the place I needed a type signature (or at least I remember wanting to find such things out at the time)). jcc

Miguel Mitrofanov

5:34 p.m.

...

...
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?

Not much if you're writing from scratch, but if you're making minor changes in the already written code, it appears to be very useful. I use C-c C-t all the time, and it gives me the types as they were before my changes - if I didn't change them, this hints are helpful, and if i did - I'm aware of that.

Peter Verswyvelen

19 Jan 19 Jan

1:08 p.m.

Visual Haskell does that, but IMHO not as good as the F# plugin for Visual Studio. Currently I just use Emacs and Haskell Mode and the ":t" command, but this only works for top level functions (is this correct? Maybe some syntax exists to refer to an inner function?), so yeah, it would be really handy to have a good IDE that shows you the inferred types on the fly.

...

-----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- bounces@haskell.org] On Behalf Of Jon Harrop Sent: Saturday, January 19, 2008 6:31 PM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Throwback of inferred types

Is it possible to get throwback of inferred types into Emacs or an IDE for Haskell?

-- 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

6332

Age (days ago)

6334

Last active (days ago)

List overview

Download

13 comments

8 participants

participants (8)

Achim Schneider
Bulat Ziganshin
Duncan Coutts
gwern0＠gmail.com
Jon Harrop
Jonathan Cast
Miguel Mitrofanov
Peter Verswyvelen