5 ms·

if the editor is aware of the type inference, you can display the signature without having to type it. it can be useful as you get automatically generic functi

if the editor is aware of the type inference, you can display the signature without having to type it. it can be useful as you get automatically generic functions, which can save a lot of time if you decide the refactor later and use say, floats instead of doubles. you don't have to edit any functions. just start using floats.

Animats 9y ago
if the editor is aware of the type inference Does any actual editor do that? Few text editors for programs are even aware of definitions in other modules.
- sacheendra 9y ago
  I don't know if it is available for other languages. But IntelliJ does it for Kotlin.
- paavohtl 9y ago
  Any editor or IDE with F# or TypeScript support can show the inferred type for anything you have selected or hover over. Ionide (an F# plugin for VS Code) can even show the inferred type over each let binding (including functions) within the text editor itself.
- lambdawitch 9y ago
  I have this for both OCaml and Haskell in Visual Studio Code.
- throwaway613834 9y ago
  Visual Studio does that for Python. It occasionally fails (e.g. it doesn't have definitions for built-ins like map()) but overall it's pretty decent. (It also does that for C++ and C# and whatnot for inferred types, but I thought I've seen other editors do it too...)
- Groxx 9y ago
  I dare say we can call this "yes, for many popular languages, in many modern IDEs". Might I suggest taking a fresh look at IDEs? It sounds like you might be stuck in text-editor land, wondering how green the grass is on the other side (or if they even have grass). IDEs do indeed provide grass, and a significant portion of the time it'll even trim and weed itself when you look at it and wonder if it's time to mow.
  - tomjakubowski 9y ago
    IDEs promise a lot, and in many cases they deliver at least some of them. But they're all or nothing: to benefit, you must use their text editor, their debugger, their supported suite of compilers, their documentation browser, their everything. A trend has emerged recently: editor-agnostic language oracles. These tools expose an IPC interface for querying, and in some cases even mutating (i.e. refactoring), source code. They often incorporate a compiler so the type information you get is perfect, and exactly what the compiler sees. Integration with the programmable text editor of your choice (vim, Emacs, Atom, Sublime Text, VSCode…) is a simpler matter of making the right IPC calls. I think this is the sweet spot. I would hate to be locked into an IDE's poor text editor or buggy interface just because they offer some convenient tools. Some examples of editor-agnostic tooling: * CIDER for Clojure and ClojureScript (via weasel or figwheel). The primary editor plugin is Emacs, but vim and Sublime Tex support exists outside the main repository. * rtags and ycmd for C and C++ * tern for Javascript * racer and RLS for Rust * eclipse.jdt.ls for Java * guru for Go Microsoft has even created a protocol for these daemons to follow, which makes editor integration even simpler: https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations https://github.com/Microsoft/language-server-protocol/wiki/P...
    - Groxx 9y ago
      Oh yeah, very much agreed (though debuggers are rarely bound so tightly in my experience). And all the language-server-protocol stuff seems exciting and fantastic and I hope it brings about a new breed of tools But that's probably still a year or two away at least for any given language for basic support, much less reaching parity with mature IDEs. In the meantime...
- yaantc 9y ago
  Merlin [1] can provide type information for OCaml and integrates with emacs, vim and sublime (at least). One can easily select any expression and get its type. From experience, it's very convenient to spot mistakes leading to properly typed code, but not with the expected type(s). [1] https://opam.ocaml.org/blog/merlin-2-0-0-released/ https://opam.ocaml.org/blog/merlin-2-0-0-released/
- DonaldFisk 9y ago
  The editor I had to write for Full Metal Jacket (my visual dataflow language) infers types by a mechanism similar to Prolog unification when you draw edges to connect vertices/function calls, and won't let you draw edges where the types at each end are incompatible. I imagine it would be a lot harder to do this in an editor for a text-based language, so it would probably be left to the compiler to check, which would have to build its own graph connecting function calls. Incidentally, things have moved on in the functional programming world from vanilla Hindley-Milner types, and there's a lot of interest now in dependent types, which depend on values returned at run time, e.g. if you're drawing on a window, the x-coordinate's type is a number from 0 to the window's width, which might change while the program is running. This adds an extra layer of type safety, eliminates a further class of errors, and allows the compiler to safely remove some run-time checks.
- somenewacc 9y ago
  For Haskell, there's a plugin called ghc-mod http://www.mew.org/~kazu/proj/ghc-mod/en/ http://www.mew.org/~kazu/proj/ghc-mod/en/ It works with many text editors, like Emacs or vim. edit: the trend today is to work with the "language server protocol": http://langserver.org/ http://langserver.org/ Haskell people are writing new tooling based on LSP to supersede ghc-mod: https://github.com/alanz/haskell-lsp https://github.com/alanz/haskell-lsp
  - w4tson 9y ago
    Is this what rust uses in IntelliJ? I know they have built some tooling that IDEs delegate to for tooling such as autocomplete etc rather than building it n times in n editors
    - steveklabnik 9y ago
      IntelliJ has their own stuff, it does not use the RLS.
- vilhelm_s 9y ago
  For emacs and ocaml, caml-types.el is simple but very helpful. (It reads the type information generated by the ocaml compiler's -annot option.) http://caml.inria.fr/svn/ocaml/trunk/emacs/caml-types.el http://caml.inria.fr/svn/ocaml/trunk/emacs/caml-types.el

Animats 9y ago

if the editor is aware of the type inference Does any actual editor do that? Few text editors for programs are even aware of definitions in other modules.

sacheendra 9y ago
I don't know if it is available for other languages. But IntelliJ does it for Kotlin.
paavohtl 9y ago
Any editor or IDE with F# or TypeScript support can show the inferred type for anything you have selected or hover over. Ionide (an F# plugin for VS Code) can even show the inferred type over each let binding (including functions) within the text editor itself.
lambdawitch 9y ago
I have this for both OCaml and Haskell in Visual Studio Code.
throwaway613834 9y ago
Visual Studio does that for Python. It occasionally fails (e.g. it doesn't have definitions for built-ins like map()) but overall it's pretty decent. (It also does that for C++ and C# and whatnot for inferred types, but I thought I've seen other editors do it too...)
Groxx 9y ago
I dare say we can call this "yes, for many popular languages, in many modern IDEs". Might I suggest taking a fresh look at IDEs? It sounds like you might be stuck in text-editor land, wondering how green the grass is on the other side (or if they even have grass). IDEs do indeed provide grass, and a significant portion of the time it'll even trim and weed itself when you look at it and wonder if it's time to mow.
- tomjakubowski 9y ago
  IDEs promise a lot, and in many cases they deliver at least some of them. But they're all or nothing: to benefit, you must use their text editor, their debugger, their supported suite of compilers, their documentation browser, their everything. A trend has emerged recently: editor-agnostic language oracles. These tools expose an IPC interface for querying, and in some cases even mutating (i.e. refactoring), source code. They often incorporate a compiler so the type information you get is perfect, and exactly what the compiler sees. Integration with the programmable text editor of your choice (vim, Emacs, Atom, Sublime Text, VSCode…) is a simpler matter of making the right IPC calls. I think this is the sweet spot. I would hate to be locked into an IDE's poor text editor or buggy interface just because they offer some convenient tools. Some examples of editor-agnostic tooling: * CIDER for Clojure and ClojureScript (via weasel or figwheel). The primary editor plugin is Emacs, but vim and Sublime Tex support exists outside the main repository. * rtags and ycmd for C and C++ * tern for Javascript * racer and RLS for Rust * eclipse.jdt.ls for Java * guru for Go Microsoft has even created a protocol for these daemons to follow, which makes editor integration even simpler: https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations https://github.com/Microsoft/language-server-protocol/wiki/P...
  - Groxx 9y ago
    Oh yeah, very much agreed (though debuggers are rarely bound so tightly in my experience). And all the language-server-protocol stuff seems exciting and fantastic and I hope it brings about a new breed of tools But that's probably still a year or two away at least for any given language for basic support, much less reaching parity with mature IDEs. In the meantime...
yaantc 9y ago
Merlin [1] can provide type information for OCaml and integrates with emacs, vim and sublime (at least). One can easily select any expression and get its type. From experience, it's very convenient to spot mistakes leading to properly typed code, but not with the expected type(s). [1] https://opam.ocaml.org/blog/merlin-2-0-0-released/ https://opam.ocaml.org/blog/merlin-2-0-0-released/
DonaldFisk 9y ago
The editor I had to write for Full Metal Jacket (my visual dataflow language) infers types by a mechanism similar to Prolog unification when you draw edges to connect vertices/function calls, and won't let you draw edges where the types at each end are incompatible. I imagine it would be a lot harder to do this in an editor for a text-based language, so it would probably be left to the compiler to check, which would have to build its own graph connecting function calls. Incidentally, things have moved on in the functional programming world from vanilla Hindley-Milner types, and there's a lot of interest now in dependent types, which depend on values returned at run time, e.g. if you're drawing on a window, the x-coordinate's type is a number from 0 to the window's width, which might change while the program is running. This adds an extra layer of type safety, eliminates a further class of errors, and allows the compiler to safely remove some run-time checks.
somenewacc 9y ago
For Haskell, there's a plugin called ghc-mod http://www.mew.org/~kazu/proj/ghc-mod/en/ http://www.mew.org/~kazu/proj/ghc-mod/en/ It works with many text editors, like Emacs or vim. edit: the trend today is to work with the "language server protocol": http://langserver.org/ http://langserver.org/ Haskell people are writing new tooling based on LSP to supersede ghc-mod: https://github.com/alanz/haskell-lsp https://github.com/alanz/haskell-lsp
- w4tson 9y ago
  Is this what rust uses in IntelliJ? I know they have built some tooling that IDEs delegate to for tooling such as autocomplete etc rather than building it n times in n editors
  - steveklabnik 9y ago
    IntelliJ has their own stuff, it does not use the RLS.
vilhelm_s 9y ago
For emacs and ocaml, caml-types.el is simple but very helpful. (It reads the type information generated by the ocaml compiler's -annot option.) http://caml.inria.fr/svn/ocaml/trunk/emacs/caml-types.el http://caml.inria.fr/svn/ocaml/trunk/emacs/caml-types.el