GSOC 2021 Ideas

[jneira]

• The Gsoc 2021 call for ideas has started and it would be great that hls would be present, as in previous ones
• We are plenty of features request, but it should have the appropiate scope (and i am not sure what can be)
• Some quick ideas:
  • Improve template haskell support: we have many bug reports about
  • REPL Support: REPL Support #477
  • There are several requests about suggestions, maybe they can be grouped
  • Tackle build tools interop through hie-bios: cabal show-build-info, the stack correlated functionality
  • The performance side: use of memory for example (several issues about too)
  • ....

[Ailrun]

How about stack/cabal integration of script (non-project) cradles?

[jaspervdj]

I think we'd be okay including several of these smaller issues. Is someone willing to summarize them so we can include them on the summer of Haskell page? I can also help if it's a pretty literal transcription of these issues. I'd like to get some ideas on our page over the next two weeks since it boosts Haskell.org's application to GSoC.

[jneira]

I've created a label Eligible for gsoc 2021
If we have isolated issues that can be used as base for gsoc we could label them, but if we want group several issues i would create a meta new one linking them and providing some context (and label it of course)

[jneira]

Another path to make progress could be in the renaming feature, that is almost missing in hls afaik

• There exists the retrie plugin and a issue about Retrie: implement high-level refactorings including renaming #282
• In hie we were using HaRe to refactor duplicate definitions f.e.

Could both be used?, would they be alternative or complementary? is a good idea make progress in the renaming feature thanks to the next Gsoc?

//cc @pepeiborra @alanz

[pepeiborra]

The renaming feature is very doable and it would be a great contribution. The main problem is that retrie does not actually work that well in big projects, because it doesn't use the renamed AST. So the project would involve 2 steps:

1. Enhancing retrie to use the renamed AST as described in Matching of qualified names facebookincubator/retrie#10
2. Implementing the refactorings described in Retrie: implement high-level refactorings including renaming #282 including rename.

I'm happy to mentor if @xich and @alanz are busy

[jneira]

nice, i've labeled #282 as eligible for gsoc

[michaelpj]

What about some of the big-ticket LSP features that we don't have yet? e.g. semantic tokens and call hierarchies. Possibly not enough work for a full GSOC, but you could extend it to "make sure we're using all the features of the spec that we can".

[jneira]

I would love to have call hierarchy, I think thanks it would be feasible using the already included hiedb

[michaelpj]

Yeah, I think it's pretty feasible, needs some work in the lsp library too, but I think mostly straightforward.

[wz1000]

I posted the following call for mentors and students regarding bytecode serialiation and/or fat interface files to the ghc-devs mailing list: https://mail.haskell.org/pipermail/ghc-devs/2021-March/019633.html

[jaspervdj]

I've added a stub here so this thread gets some visibility for students: https://github.com/haskell-org/summer-of-haskell/blob/master/content/ideas/hls.md

[July541]

Hello, I am a student who would like to apply for GSoC. HLS is a very useful project for every developer. As a beneficiary, I hope to contribute to this project. As HLS is a complex project that beyond my ability, some technical guide may help me establish a feasible plan. I want to know where I can get some help with the details of the proposal.

[pepeiborra]

I'm not sure if this is what you had in mind, but the IFL 2020 draft proceedings contain a research paper describing some of the internals of HLS. Past GSoC students like @fendor and @bubba might be able to offer more advice!

[July541]

Thank you! I'll keep moving by your instruction.

[fendor]

My advice is to get to know the ecosystem around HLS (read the blog posts at https://mpickering.github.io/ide/index.html for an overview), start contributing to minor issues and find a pain point you want to fix. Maybe even implement a feature before submitting your proposal.

This discussion provides some ideas about existing pain points, like cabal/stack scripts, performance issues, etc...

If you find an issue you want to work on, dont be afraid to ask questions, either on the issue or on IRC freenode #haskell-language-server

[jneira]

start contributing to minor issues and find a pain point you want to fix

Note that some issues are tagged with first good issue

[July541]

@fendor Thank you for your warm reply, I am trying your advice.

@jneira Thank you for your mention, I really focused on Eligible for GSoC 2021 before and ignored this newer friendly tag.

[jaspervdj]

@jneira Could you email me a list of email addresses of people who would be interested in mentoring? That way I can invite them to the GSoC dashboard.

[jneira]

Hi, i think @pepeiborra has mentioned he could be one of them, to help to implement renaming.
Not sure about others, sorry.
I am afraid it would not have enough time and proficiency to be a main mentor. I would try to help for sure, being officially a (secondary) mentor or not.
//cc @mpickering @wz1000 @michaelpj @Ailrun @fendor @berberman @isovector @ndmitchell

[isovector]

I'm happy to mentor

[OliverMadine]

If the proposals are still under review, I’d like to mention that I have updated some of my “draft” proposal with what I think would be a better approach to the renaming types. I also made some other minor changes.

Before I mentioned using Retrie's type forward to address the renaming issues (specifically with types),but since Retrie has limitations with larger projects, I think a combination of using HieDb references and file contents would work better. The details can be found on the draft proposal if access is still available to mentors?