Haskell-ide-engine: Discussion: What FP can Learn from SmallTalk

[alanz]

https://www.reddit.com/r/haskell/comments/9x2is1/what_fp_can_learn_from_smalltalk_i_aimed_quite_a/

@deech did a talk at LambdaWorld in September, showing some cool features in SmallTalk.

Which of these can we present via HIE, and how?

[Avi-D-coder]

I was wondering the same thing. The importance of cross module goto definition and find references is stressed.

I am not sure the language server protocol is a good medium for most of this.

As you mention, LSP code lens could be used, however these lens would be predefined (metrics, inlined functions to a level or in module). The beauty of Smalltalk's code lens is that they are user defined in small talk. Taking this to the extreme if the work was put in hie, could evaluate comments in the context of a simple API (refs, args, types, impls, ...) like doctest.

[alanz]

Well, my view is to start with experimentation, make some introspection tools (which I have been wanting to do for a while), and see how it works, and then take it from there.

Fundamentally Haskell is not "image" based the way things like Smalltalk, Lisp et al are, but at least adding views will be helpful.

And I am very excited at the conversational code development possibilities enabled by codeActions and codeLenses.

It reminds me of the approach put forward way back when in ArgoUml, where you would have pluggable critics to analyse your code and offer suggestions for improvement.

[nponeccop]

The importance of cross module goto definition and find references

Did you mean cross-package?

I am not sure the language server protocol is a good medium for most of this

IMO the most important demonstrated feature was outstanding performance.

As for the mission of HIE, IMO it's providing the baseline which just works. Currently the least common denominator of IDE tools which just work are syntax highlighting and ghci. I have never heard that a new GHC release broke ghci or syntax highlighting, or that those are not maintained anymore, or that someone struggles to make them running for him in a non-exotic environment.

So features beyond those of LSP are not that important, usability, quality and performance of the baseline tool are. And as @deech said in the video, the culture of using an IDE then will make a very rich IDE a reality.

And as for exploration of large codebases, there are fairly many tools for widely used languages such as C++ and Java. And not all of them are IDEs:

• SourceTrail
• SciTools Understand
• Imagix 4D

So we in principle could have a companion GTK app, given that gi-gtk is used by Leksah so it's well-maintained by them. Or even a web interface. A non-IDE companion app has an advantage that it doesn't have to implement an IDE (let Leksah do it) and it works with any IDE by the means of either not integrating with it :) or by connecting to the same LSP process as the IDE.

But as I said earlier, it's better to focus on just supporting LSP extremely well. I think even forking GHC to make GHC API well-suitable for HIE is a better approach than feature-bloating.

[zeronone]

For cross package goto definitions, maybe haskell-code-explorer is useful.
https://github.com/haskell/haskell-ide-engine/issues/851