Biggest feature I want is automated refactoring. Changing a type definition and getting a bunch of errors to fix is one of the defining features of Haskell as a development experience—but the changes themselves are still pretty manual, and in larger codebases, this quickly gets painful. I would love a system where I make a change, get a bunch of errors and as much of the refactoring as possible is done for me automatically. This would include traditional refactorings like renaming functions and constructors, but it would also include more Haskell-specific refactorings, potentially with some amount of interactiveness. One example I ran into recently: I added a field to a constructor that was used pretty widely in my code, especially in lots of tests, and I had to manually update each pattern using that constructor to disregard the new field and add a default value (an empty string, in this case) everywhere the constructor was used to build a value. This was really tedious to do, and seems systematic enough that it could have been fully automated. In other scenarios, I would want my editor to cycle me through each location that needs to update and give me an automated suggestion I can accept or reject so that I could do a first pass quickly and only spend time on cases that require more manual intervention. I have not used any Haskell refactoring tools yet, so I am not sure what exists today. Google around now, it looks like Facebook's retrie[1] project might be expressive enough to do the heavy lifting for a tool like this, so perhaps we just need a friendly frontend for it. [1]: https://github.com/facebookincubator/retrie On Mon, Nov 30, 2020 at 12:49 PM Alan & Kim Zimmerman wrote:

I would want to see moldable development[1] style search and visualisation.

Or something like [2]

Alan

[1] https://gtoolkit.com/ [2] https://2020.splashcon.org/details/splash-2020-oopsla/98/Adding-Interactive-...

On Mon, 30 Nov 2020 at 20:35, Gueven Bay via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...

Greetings,

Imagine that you can decide what functionality and features an Integrated Development Environment for Haskell should get. You can make this IDE with your wishlist similar in power as other IDEs for Java for example.

Now list as many features as you can, what would make the life of a Haskell developer as comfortable as possible!?

I am dying to know how this list of features at the end (of this thread) will look like. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Mon, 30 Nov 2020 at 21:42, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Mon, 30 Nov 2020, Tikhon Jelvis wrote:

...

Biggest feature I want is automated refactoring.

Any such refactoring tool would require a (configurable) formatting and indentation tool, because even simple search&replace will break your layout. Thus, a good code formatter would be an even more important feature of the IDE.

The ghc-exactprint library (as used in retrie, hlint refactors and HaRe) makes it so you can change the AST in a refactoring and preserve formatting/layout in the result. Alan

Sem like there are *many* standard examples around, IntelliJ, Eclipse, Netbeans, etc. Are there specific reasons that a Haskell IDE would be different in features?? Is there something lacking in use of (say) the standard IntelliJ IDE for Haskell? Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- From: Haskell-Cafe On Behalf Of MarLinn Sent: Monday, November 30, 2020 7:01 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] What features should an (fictitious) IDE for Haskell have? Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time. Maybe don't even store the code as ascii text.

All IDEs mentioned have good, sometimes excellent support for declarative languages like HTML, CSS, SQL, XML, you name it. Sure, some things won't transfer easily. E.g. Haskell needs different debugging tools, and different performance investigation tools. But at the coding & code inspection level, Haskell isn't any different. You code, you look up modules, you transform and refactor code. Modern IDEs tend to struggle with dynamic languages where the lack of type information makes them misidentify a lot of things, but Haskell isn't one of these (type inference is easy to do on the fly with a modern CPU). Am 01.12.20 um 07:53 schrieb YueCompl via Haskell-Cafe:

Typically, you programming with procedural mindset in an imperative language, but programming with mathematical mindset in a functional language. The difference in methodology would require difference in choices of methods / tactics.

...

On 2020-12-01, at 09:13, Gregory Guthrie mailto:guthrie@miu.edu> wrote:

Sem like there are **many** standard examples around, IntelliJ, Eclipse, Netbeans, etc. Are there specific reasons that a Haskell IDE would be different in features?? Is there something lacking in use of (say) the standard IntelliJ IDE for Haskell? Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- *From:*Haskell-Cafe mailto:haskell-cafe-bounces@haskell.org>*On Behalf Of*MarLinn *Sent:*Monday, November 30, 2020 7:01 PM *To:*haskell-cafe@haskell.org mailto:haskell-cafe@haskell.org *Subject:*Re: [Haskell-cafe] What features should an (fictitious) IDE for Haskell have?

Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time.

Maybe don't even/store/the code as ascii text.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

I am pretty sure they all work iwth utf-8 files... Greets, Branimir. On 1.12.20. 3:06 пре подне, Mig Mit wrote:

Please DO store code as ascii text. At the very least that would allow the use of external tools — sed, diff, git, whatever. Non-ascii representations were tried multiple times, and largely failed, in particular because of terrible interaction with other tools.

Also, please make sure your IDE is a good text editor. Because that's what the code is — not AST, but text. Until it is finished (to a certain lax definition of "finished") it is likely to not even be representable in AST form.

Sent from my iPad

...

On 2020. Dec 1., at 2:02, MarLinn wrote:



Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time.

Maybe don't even /store/ the code as ascii text.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Some time ago there was a thread about an article where the author advocated for extremely long and descriptive variable names. Discussion spread if that is the right approach and what is the best variable name length and descriptiveness. The correct choice depends on the reader context. The article author works as a contractor. He reads a lot of code for the first time. Long and descriptive variable names help him a lot. For someone else, well acquainted with the code, are such long names only a clutter that reduces readability. They might prefer single letter variable names, or pointfree style. So each of them goes and adjusts the variable name descriptiveness slider in the fictitious IDE aproppriately. The todays text-as-the-primary-representation approach however forces the author to make a pick already when writing the code. On 12/1/20 2:06 AM, Mig Mit wrote:

Please DO store code as ascii text. At the very least that would allow the use of external tools — sed, diff, git, whatever. Non-ascii representations were tried multiple times, and largely failed, in particular because of terrible interaction with other tools.

Also, please make sure your IDE is a good text editor. Because that's what the code is — not AST, but text. Until it is finished (to a certain lax definition of "finished") it is likely to not even be representable in AST form.

Sent from my iPad

...

On 2020. Dec 1., at 2:02, MarLinn wrote:



Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time.

Maybe don't even /store/ the code as ascii text.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Am 01.12.20 um 17:57 schrieb Marian Jancar:

The todays text-as-the-primary-representation approach however forces the author to make a pick already when writing the code.

A binary-only representation will also force to pick names. After all, the code will have to be read and understood, so the requirements on names are essentially identical.

Automatic code generation from type signature, using djinn exference and other packages, Automatically fill holes in the code using the same engines. El vie, 4 dic 2020 a las 19:45, Ben Franksen () escribió:

Am 01.12.20 um 03:06 schrieb Mig Mit:

...

Please DO store code as ascii text. At the very least that would allow the use of external tools — sed, diff, git, whatever. Non-ascii representations were tried multiple times, and largely failed, in particular because of terrible interaction with other tools.

Also, please make sure your IDE is a good text editor. Because that's what the code is — not AST, but text. Until it is finished (to a certain lax definition of "finished") it is likely to not even be representable in AST form.

Absolutely. And "a good text editor" for me includes (a) an easy way to re-configure key bindings and (b) the ability to define macros (using some sort of embedded language). The point is that I want to be able to re-use my finger's muscle memory as far as possible.

That's just the basics, of course, and on top of that I would expect at least the ability to easily navigate to the definition of a variable and also to iteratively visit all places where it is used, centering the code in the editor window and highlighting the variable, such that I can navigate to the next/previous occurrence, skip the whole file or subdirectory, etc. Like a multi-file/multi-dir language aware search and replace.

A very cool feature would be if I could select a program phrase and let it find /similar/ phrases, where a similarity metric could be edit-distance with respect to language tokens (ideally ignoring redundant parentheses and stuff like that).

Cheers Ben

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Alberto.

I wish this is being discussed in https://www.reddit.com/r/haskell/ https://www.reddit.com/r/haskell/ so I can upvote this comment. Do we have an alternative mechanism as with the mailing list? I noticed Julia's community has some bots cross posting between a few of its sites, do we or can we have a similar mechanism?

On 2020-12-01, at 16:28, Joachim Durchholz wrote:

That's one of the ideas that come up on a regular basis, but it doesn't buy you anything in practice.

You want to be able to represent code in mails, websites, and books. And you want that representation to be unambiguous, so you need to define the whole parsing process.

In the past, having a binary representation would help with refactoring and such, but modern CPUs are fast enough to create the AST on the fly. Even in the presence of syntax errors.

Also, pure AST editors tend to be clunky. They disallow invalid syntax, so the programmer is forced to do everything right. There are many situations where you start writing down something vague and refine it, dealing with those aspects first that you need. In a sense, the problem is that an AST doesn't give you a scratchpad for ideas and vagueness, everything has to be perfect from the get-go.

I first heard about such an idea in the 90s (when on-the-fly parsing wasn't really doable). It was one of the things MS wanted to do, and they even created a prototype. It failed.

Am 01.12.20 um 02:01 schrieb MarLinn:

...

Most importantly: A good IDE is not a text editor, but an AST editor. If the AST happens to be presented as text, that's a choice of visualisation, nothing more. Better to start with a graph-like visualisation to free the mind, then think through the possible interactions. Maybe add the typical text-like visualisation later. But don't start there or you'll just re-invent notepad for the nth time. Maybe don't even /store/ the code as ascii text. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Things *have* changed dramatically - you can install hls via ghcup, or clone+stack install.hs <desired-version>. For vim enabling it is literally one line for your lsp client. For vscode you don't even need to download/install it - there are static executables and installing the extension is enough. It also fails much less often, automatic setup configuration is improved, and features are growing at a steady pace. ======= Georgi

What I believe you got hung up on is the installation script that the website (https://www.haskell.org/ghcup/) attempts to push on you. This installation scripts tries to do lots of things, but what may have worked better for you is to just offer the right precompiled binary to the user. If you want to try, the current latest binary can be downloaded this directory (select the one for your system): https://downloads.haskell.org/~ghcup/0.1.12/ Having that and putting the binary in your PATH allows you to run the following: $ env GHCUP_USE_XDG_DIRS=1 ghcup install hls This will install HLS only, no additional stuff, and use the XDG directory structure. An alternative to letting users download the right binary themselves is of course to change the script. My point is that the only part of ghcup that tries to do "too much" is that installation script, not ghcup itself. Cheers, Tom ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, December 1, 2020 5:15 PM, Sven Panne wrote:

Am Di., 1. Dez. 2020 um 16:36 Uhr schrieb Georgi Lyubenov :

...

Things *have* changed dramatically - you can install hls via ghcup, or clone+stack install.hs <desired-version>. For vim enabling it is literally one line for your lsp client. For vscode you don't even need to download/install it - there are static executables and installing the extension is enough.

Looking at https://taylor.fausak.me/2020/11/22/haskell-survey-results/#s2q1, stack is by far the most popular way to manage GHC installations. If I read https://github.com/haskell/haskell-language-server correctly and I don't want to compile hls for myself, I have the option of either using ghcup or manually downloading the prebuilt binaries. I have never used ghcup before, and I don't intend to do so in the future (stack user here ;-), but I gave it a try. It took me some tries and modifications to the script to install only hls (no need for additional GHC/Cabal installations) to an XDG-conformant path. Downloading the wrapper + some hls versions manually from https://github.com/haskell/haskell-language-server/releases is definitely doable, but still a bit fiddly. I guess Vim people need to do the same, only the VS Code extension does things more automagically.

In a nutshell: Much better than before, but a far cry from a one-liner for the most common installation/IDE combos. There is probably not much missing: Only a simple script to install the wrapper/all hls versions into an XDG-conformant path (optionally selecting only a subset of the versions, but this shouldn't be the default). Coupling this to ghcup doesn't look like a good idea, this tries to set up too many unneeded things, at least I wasn't able to figure out how to download *only* hls.

...

It also fails much less often, automatic setup configuration is improved, and features are growing at a steady pace.

Great! :-) I think I'll give it a real try soon.

Am 01.12.20 um 17:22 schrieb Tony Zorman:

The second part is more of a "why has no-one packaged this for Debian/Ubuntu derivatives" (which I'm not sure is true anymore, but I don't use either so I can't check) shortcoming than a Haskell LSP shortcoming, don't you think?

Actually I have stopped using prepackaged development environments on the Debian-based distros I have been using. The thing is plugins. As soon as you need a plugin that isn't packages, you're starting to use a mixture of distro-provided IDE + standard plugins plus your own plugins. The experience tends to be "interesting" or "hell" depending on personal perspective, but at the end of the day, the primary purpose of a packaged IDE should be using it, not tinkering with it. I have switched to installing all IDEs to ~/bin/, and the experience has become _much_ less painful - I couldn't care less about an Eclipse or IntelliJ package. For things like Perl and Python, things can be even worse because these packages are geared towards running the distro, not towards developing software with them. At least with Python, it's easy to set up in ~/bin/ or in a project directory using virtualenv, so I'm not using those packages either. (I'm not going to advocate using any of these environments on a Haskell list, just showing experiences made with other languages ;-) ) Regards, Jo

On 2.12.20. 10:08 пре подне, Bardur Arantsson wrote:

On 01/12/2020 22.59, Joachim Durchholz wrote:

...

Am 01.12.20 um 17:22 schrieb Tony Zorman:

...

The second part is more of a "why has no-one packaged this for Debian/Ubuntu derivatives" (which I'm not sure is true anymore, but I don't use either so I can't check) shortcoming than a Haskell LSP shortcoming, don't you think? I have switched to installing all IDEs to ~/bin/, and the experience has become _much_ less painful - I couldn't care less about an Eclipse or IntelliJ package.

Absolutely agreed from many many years of experience. It almost always ends up being less painful to just use the upstream's binary bundle (For the reasons you stated.)... but perhaps I've been spoiled by the (relative) good quality of Intellij IDEA's bundles.

...

For things like Perl and Python, things can be even worse because these packages are geared towards running the distro, not towards developing software with them. Same thing applies for Haskell on Arch Linux, for example.

On Arch Linux you can't build anything. Only if you use bundle not related to distro... and compiler is set for dynamic libraries so you have to set up cabal config and ghs-options to use dynamic. But anyway you can't build lot of libraries... Greets, Branimir.

Regards,

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Hi, Thank you all for participating and gathering the features. After reading all your answers I want to subsume all your features: * moldable views of sources and searches in the sources * automated refactoring * configurable formatting and indentation (ghc-exactprint used in retrie, hlint and HaRe can help with that) * a good IDE is an AST editor (or should it be just a very featureful text editor?) * IDEs like IntelliJ and Eclipse are designed from and for imperative and object-oriented developers * Haskell would need specialized debugging and performance investigation tools * some kind of automated adjustment (with an slider as GUI element) of (very) * descriptive variable names * the IDE itself should be performant and reliable * use the haskell language server * the IDE should be easy to set up and manage (it should come in a big but modularized bundle) For some time now I had an idea for interactive wizards which create Haskell source. Thinking about these little helpers I wanted to see if there are some features Haskell devs wish they had in their environments which I can with time build into the wizards. Now how should the Haskell creator wizards look like: On the very basic level they create every language feature of Haskell. You want create a function? The wizard creates the function and its parameters and everything needed to run the function and stores them in the source. Based on this the helpers should create data structures and algorithms: As to create these you need in most cases several calls to the basic level. Next level would be "functionality": You do not want data structures, you are a user, you want your problem solved. Using the DS+ALGS the helpers create a calendar, a basic key-value store and much more. Of course you can create your own functionality wizards using the more basic wizards. It should be possible to call the wizards from the command line and later there should be some kind of easy and basic GUI (speak ncurses dialogs) for the wizards. You now gave me some points more to think about to integrate in the wizards. Am Mi., 2. Dez. 2020 um 18:47 Uhr schrieb Joachim Durchholz :

...

Absolutely agreed from many many years of experience. It almost always ends up being less painful to just use the upstream's binary bundle (For the reasons you stated.)... but perhaps I've been spoiled by the (relative) good quality of Intellij IDEA's bundles.

Eclipse works, too. I had been using it for years before I had to switch for work-related reasons - IntelliJ has some strengths and some weaknesses compared to Eclipse, and it depends a lot on which of the two got more love and attention in the previous years. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Fancy editor, VScode has Haskell support ;) Greets, Branimir. On 2.12.20. 9:23 по подне, YueCompl via Haskell-Cafe wrote:

I can't speak for other Haskellers, I even doubt I am a qualified Haskeller yet, but I don't think such *wizard* things will work well with Haskell, they might be suited to populate boilerplate bloated codebase, and when the project codebase would vastly follow imperative paradigm to develop routine business procedures. But I don't think Haskell is a great fit for that by today, though it had been said "Haskell is the best imperative language", as the ecosystem is geared toward solving whole categories of problems with highly abstract code, there are plenty pitfalls to develop specific, procedural components in Haskell.

Regards, Compl

...

On 2020-12-03, at 03:24, Gueven Bay via Haskell-Cafe wrote:

Hi,

Thank you all for participating and gathering the features.

After reading all your answers I want to subsume all your features: * moldable views of sources and searches in the sources * automated refactoring * configurable formatting and indentation (ghc-exactprint used in retrie, hlint and HaRe can help with that) * a good IDE is an AST editor (or should it be just a very featureful text editor?) * IDEs like IntelliJ and Eclipse are designed from and for imperative and object-oriented developers * Haskell would need specialized debugging and performance investigation tools * some kind of automated adjustment (with an slider as GUI element) of (very) * descriptive variable names * the IDE itself should be performant and reliable * use the haskell language server * the IDE should be easy to set up and manage (it should come in a big but modularized bundle)

For some time now I had an idea for interactive wizards which create Haskell source. Thinking about these little helpers I wanted to see if there are some features Haskell devs wish they had in their environments which I can with time build into the wizards.

Now how should the Haskell creator wizards look like: On the very basic level they create every language feature of Haskell. You want create a function? The wizard creates the function and its parameters and everything needed to run the function and stores them in the source. Based on this the helpers should create data structures and algorithms: As to create these you need in most cases several calls to the basic level. Next level would be "functionality": You do not want data structures, you are a user, you want your problem solved. Using the DS+ALGS the helpers create a calendar, a basic key-value store and much more. Of course you can create your own functionality wizards using the more basic wizards. It should be possible to call the wizards from the command line and later there should be some kind of easy and basic GUI (speak ncurses dialogs) for the wizards. You now gave me some points more to think about to integrate in the wizards.

Am Mi., 2. Dez. 2020 um 18:47 Uhr schrieb Joachim Durchholz :

...

...

Absolutely agreed from many many years of experience. It almost always ends up being less painful to just use the upstream's binary bundle (For the reasons you stated.)... but perhaps I've been spoiled by the (relative) good quality of Intellij IDEA's bundles. Eclipse works, too. I had been using it for years before I had to switch for work-related reasons - IntelliJ has some strengths and some weaknesses compared to Eclipse, and it depends a lot on which of the two got more love and attention in the previous years.

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

That's an `iterate (+1)` from me! I've just finished teaching my students about monads, and this facility would be really, really, useful.... (They're now engaged in a struggle with a monadic exercise ;-) Regards, Andrew

On 7 Dec 2020, at 23:22, André Popovitch wrote:

One feature I've always wanted would be able to "manually inline" a function. For example, if I have

foo a = a + a bar = foo 3

I'd like to be able to right-click on the invocation of `foo` and select some option to inline it, rewriting the file to read

foo a = a + a bar = 3 + 3

I think this would make it simple to dive into an abstraction to see what's really going on. For example, imagine a new user is confused by this expression:

Just 3 >> Just 4

They could right-click on `>>` to see that it is identical to:

case Just 3 of Just _ -> Just 4 Nothing -> Nothing

Which would allow them to easily see that this expression will always evaluate to "Just 4" (and hopefully simplify it). Enlightened, they could then hit ctrl-z to revert the code to its original state.

Haskell's purity and laziness makes it one of the only mainstream languages where equational reasoning is really possible, so this feature would play on Haskell's strengths and provide a feature that couldn't be replicated in other languages' IDEs. It would also allow new users to more easily dive in and understand certain abstractions (although how it would work in many cases would be hard to determine).

On Mon, Nov 30, 2020 at 3:35 PM Gueven Bay via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote: Greetings,

Imagine that you can decide what functionality and features an Integrated Development Environment for Haskell should get. You can make this IDE with your wishlist similar in power as other IDEs for Java for example.

Now list as many features as you can, what would make the life of a Haskell developer as comfortable as possible!?

I am dying to know how this list of features at the end (of this thread) will look like. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Andre Popovitch 989 627 4376 _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Software Foundations & Verification Research Group School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ --------------------------------------------------------------------