Elm-pair development tool

Request Feedback
1

I’ve released a site for a tool called Elm-pair and I’d love people’s thoughts and feedback. The tool’s pitch is this:

Elm-pair helps you write Elm code. You tell Elm-pair about the change you want to make and it will do the actual work. It’s a bit like using an IDE except you don’t need to learn any keyboard shortcuts.

You talk to Elm-pair by making a change in your code and saving it. Elm-pair will notice the change you made, and if it understands your intent will respond with a change off its own.

If that sounds interesting to you then please take a look at the site for more details and demo’s! I’d love to learn what you think of it.

https://elm-pair.jasperwoudenberg.com/

31 Likes
2

Oh my, what a twist. I got hooked by the very well done videos with editor integration. As a vim user, this looks really nice.

2 Likes
3

I was super disappointed at the end, but I’d absolutely love this as a tool! Especially if it was IDE agnostic.

5 Likes
4

I’ve seen some of the features here in packages like elm-jutsu for Atom and Vscode.

The features you propose seem like a better and more complete implementation of the concept.

I can’t wait to see progress on this over time.

2 Likes
5

Interesting ideas, although the way they’re presented disappointed me a bit at the end :wink:

I think a bunch of these features can be implemented using a language server and code actions. E. g. remove unused imports with elm-analyse.

3 Likes
6

This looks awesome! Would definitely use.

1 Like
7

Another feature I’d love: changing map numbers when changing the number of arguments passed to a Json.Decode.map function. E.g. if you have

decodeMyModel : Decoder Model
decodeMyModel =
  map2 Model
    field "field1" int
    field "field2" string

and you add

decodeMyModel : Decoder Model
decodeMyModel =
  map2 Model
    field "field1" int
    field "field2" string
    field "field3" bool

it would change map2 to map3 on save.

4 Likes
8

Looks promising ! Would definitely use

1 Like
9

This would be really nice

1 Like
10

Hey Jasper. I love these ideas! I also think that much more powerful environments for code editing/exploration/transformation are possible.

For example, to add to your examples of editing code, I’ve been considering some ways to explore code:

  • I might want to see all functions that have values of a particular type in their definition (say, to find out what the type is for)
  • I might want to see the definitions of all functions used in a given function (say, to refactor something across these functions)
  • I might want to improve documentation, so I’d want to see all the functions and types without comments attached (or maybe functions without type annotations)
  • I might want to clean up, so I’d want to look at a list of unused functions and other symbols like types and type aliases
  • I might want to evaluate my use of a package, so I’d want to see all the places where any symbols from that package appear
  • I might want to see all uses of a given symbol in context (eg within functions where it’s used)
  • I might want to review all the types in the code base (eg to see if there is duplication or field name discrepancies)
  • I might want to find all functions that return a particular type.

Imagine the answers to all these questions showing up in a single view in the editor (ie not as a list of search results), allowing me both to see results in context and to edit anything, eg refactoring something across a whole chain of functions or deleting unused functions, without jumping between files or scrolling around a lot.

This is probably just the tip of an iceberg! Some of this is possible now, some of this could be possible with sufficiently advanced editors. I think, however, that to take this to a logical conclusion and allow entirely new ways of working with code, it’s necessary to go beyond text. I believe that representing code as text is a limitation on how we work with it.

3 Likes
11

This kind of feature that automates things using types is just awesome. I’m in love with elm-pair! I hope we’re gonna have a tool like this soon!

1 Like
12

I like the ideas, but my main concern with the tool would be trust. It’s very much “action at a distance”, and I would be nervous about it doing unintended changes. When I use a refactoring tool in my IDE, I have a pretty good idea about what it’s going to do, and I can trust it won’t do anything aside from that. But here it’s not really obvious to me what the tool wants to do based on the changes I’m making, so I’m not sure I trust it to do what I intended to happen. For example, when I add a new argument to a function, maybe adding Debug.todo and keeping everything compiling for now is what I want, but maybe I’d rather just have the compiler list all the places that I now need to update.

But anyway, it’s a cool concept to start from :blush:

1 Like
13

It looks helpful, but I’m fairly sure some of the features would be difficult to achieve.

For example, what happens when the ‘auto-import’ comes across something ambiguous (e.g. a map function which is likely found in many packages)?

It would also need to play well with other tools (e.g. elm-format, elm-live or elm-reactor etc).

If those things could be overcome I’d definitely use it.

1 Like
14

I agree this is an important aspect. If the tool does the wrong thing even a small percentage of the time, then I imagine it quickly becomes more annoying than useful.

One defense against this I imagine is that elm-pair should only jump into action if the code was compiling before the user made a change and compiles again after elm-pair responded with a change. The suquence of events would look like this:

  1. Base state: the project is compiling.
  2. The user makes a change over one or several saves.
  3. Elm-pair diffs the current state of the code with the state it was in when it last compiles (1). If it thinks it understands the change than it responds with a change of its own.
  4. Elm-pair compiles the code with the change applied somewhere out of the way. Only if the project compiles again with the change applied will it apply the change for real.

I think that would give decent assurances that Elm-pair doesn’t misunderstand intent, but probably the only way to really tell is to try build this thing.

Yeah, that’s a fair point. For that particular example, I think if Elm-pair adds Debug.todos it should add all the places where it does that to the editor’s ‘error list’, so it becomes easy for the user to go through all those places. Generating a unique string in the Debug.todo might also help. That way, if the programmer decides not to fix those todos immediately but comes back at them later, it’s easy search across the project for all occurrences of a particular todo once you find one.

Lastly I would love it if all the changes elm-pair introduces could be undone by a single ‘undo’ operation in the editor.

In my example the auto editor triggers on a user writing out the import in a qualified manner. So if you’d only write map elm-pair wouldn’t do anything, but if you’d write Thing.map it would add an import for the Thing package, if such a page exists and isn’t imported yet. You could then as a second step remove the Thing. qualified from the import, and elm-pair would respond by exposing map from Thing so it can be used in an unqualified manner.

3 Likes
15

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.