Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Automatic Expansion of uninitialized record fields #462

Open
ProofOfKeags opened this issue Oct 4, 2020 · 19 comments · May be fixed by #4325
Open

Feature Request: Automatic Expansion of uninitialized record fields #462

ProofOfKeags opened this issue Oct 4, 2020 · 19 comments · May be fixed by #4325
Assignees
Labels
component: ghcide Hackathon This issue is suitable for hackathon sessions level: easy The issue is suited for beginners type: enhancement New feature or request

Comments

@ProofOfKeags
Copy link

When a warning for "Fields of ‘SomeRecord’ not initialised: a, b, c, d" fires, I'd like a CodeAction that allows it to initialize all of those rows with typed holes.

Flow would look like this:

  1. let thing = SomeRecord{}
  2. Ctrl+'.' (or other code action trigger)
  3. let thing = SomeRecord{} --> let thing = SomeRecord { a = _, b = _, c = _, d = _ }

The reason that this is somewhat of a big deal is that in the presence of long record names with the conventional prefix based row names (someRecordA, someRecordB, ...), the typing for this is nontrivial and also entirely mechanical and so the editor is perfectly capable of doing this for me.

@ProofOfKeags
Copy link
Author

More sophisticated versions of this could infer what fields are already initialized, and only supply the ones that are missing in this way.

@ProofOfKeags
Copy link
Author

Is this something that belongs in ghcide or hls?

@jneira jneira added the type: enhancement New feature or request label Oct 4, 2020
@googleson78
Copy link
Contributor

Even cooler would be, agda supports straight up introducing the entire record.
So
0.

let
  thing :: SomeRecordType 
  thing = _
  1. <introduce-record
let
  thing :: SomeRecordType 
  thing =
    SomeRecordType
      { field1 = _
      , ...
      }

@jneira
Copy link
Member

jneira commented Oct 4, 2020

I would say that i could be done in a plugin in hls, but not sure.

@ProofOfKeags
Copy link
Author

@googleson78 yeah that's also great. That said, when the typedef expands (like many records do over time), I'd still like to be able to introduce the missing fields.

pepeiborra added a commit that referenced this issue Dec 27, 2020
* Detect ghc version mismatches

* Add ghc-check to stack extra deps

* ghc-check: explicit libdir and delay version error
@antoine-fl
Copy link

Somewhat related, it would be nice to have a shortcut to convert from using the "normal" constructor to using record syntax.

For example if I have the following:

data Person = Person { firstName :: Text, lastName :: Text }

let p = Person "Robert" "Dupont"

Some shortcut could convert the second line to:

let p = Person { firstName = "Robert", lastName = "Dupont" }

@jneira
Copy link
Member

jneira commented Oct 4, 2021

Now tactics has a code action: Wingman: Use constructor Person which converts

person :: Person
person = _

in

person :: Person
person = Person {firstName = _wf, lastName = _wg}

So i think the suggestion of @googleson78 is already covered.

It still misses the other two requests:

  • Person {} to Person {firstName = _wf, lastName = _wg}
  • Person wf wg to Person {firstName = _wf, lastName = _wg}

For the first one there is a dedicated ghc warning usable to add a quick fix:

• Fields of ‘Person’ not initialised: firstName, lastName
• In the expression: Person {}
  In an equation for ‘person’: person = Person {}typecheck(-Wmissing-fields)

So i would say it should not be very much dificult to get

@jneira jneira added level: easy The issue is suited for beginners component: ghcide pr welcome labels Oct 4, 2021
@naufik
Copy link

naufik commented Oct 18, 2021

Had a look at the codebase and I think this might be a good start for me to start contributing. Can I attempt this issue?

My outline would be to add a code action for the Fields of '<X>' uninitialized warning. Right now, there is a code action for "suppress errors" so I suppose I can add an alternative quick fix as @jneira mentioned.

For suggestion 2 I'd probably have to have a look on how LHS detects if a token is a record constructor invoked using function syntax.

Hoping to spend the week on this 🤞

@jneira
Copy link
Member

jneira commented Oct 18, 2021

@naufik nice! thanks for willing to contribute, feel free to ask anything here or in the chat channels.

@salmanjnr
Copy link

Is this still open for contributions?

@naufik
Copy link

naufik commented Mar 8, 2022

Hey @salman69e27, unfortunately when I picked this up I couldn't get the build env to work at the time and currently have time constraints to contribute. You can pick up

@salmanjnr
Copy link

Thank you @naufik . I will start working on it in a couple of days

@pepeiborra
Copy link
Collaborator

Contributions are welcome 🤗 I just want to point out, as it is not mentioned in the thread, that HLS already generates record fields when autocompleting a record constructor.

Is this good enough? Does it just need to be publicised more?

@ProofOfKeags
Copy link
Author

The original request is really around having HLS intelligently expand any constructor that had a warning on "uninitialized record fields".

@googleson78
Copy link
Contributor

This is, of course, an issue with my setup - but actions were trivially set up for me and I use them extensively, while I still haven't gotten around to making the record field autocomplete, so I would be happy with having this as a code action.

@michaelpj michaelpj added the Hackathon This issue is suitable for hackathon sessions label May 17, 2023
@dan-blank
Copy link

I'd like to work on this ticket! :)

@akshaymankar
Copy link
Contributor

I'm working on this during Zurihac 2024.

@googleson78
Copy link
Contributor

Just an update that my usecase is no longer covered either, since wingman is not maintained since 9.0 afaik

@akshaymankar
Copy link
Contributor

Update from me: I have a branch with something that kinda works, just adds some extra new lines (not sure what's going on). I will try to resolve it this weekend, if not I will create a draft for someone more experienced with ghc-exactprint to take a look.

@akshaymankar akshaymankar linked a pull request Jun 17, 2024 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ghcide Hackathon This issue is suitable for hackathon sessions level: easy The issue is suited for beginners type: enhancement New feature or request
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.