Convenience in the Haskell ecosystem

[simonmic]

5 years from now there might be different maintainers… or stack and cabal may have merged, or been superseded by something better than both ?

[simonmic]

Interesting ideas, and stack’s script command is a step in that direction (I believe it will automatically add some common packages based on your imports).

[bradrn]

@hasufell

What would be interesting is if there’s a better interface for saying “install the latest HLS that’s compatible with GHC X.Y.Z”. This is implemented in VSCode Haskell extension in fact! It utilizes the following metadata for that: ghcup-metadata/hls-metadata-0.0.1.json at develop · haskell/ghcup-metadata · GitHub.

Very interesting, thanks!

From what I can see, this file looks very repetitive… is there no way to compress it somewhat to reduce transfer and parsing time? It would be really great to figure out a way to include this in GHCup somehow.

@hasufell

The third option that has been mentioned is to ship HLS with GHC, but that has large implications, including for the GHC devs and their resources. I can see some benefits, but I’m not sold yet.

From a purely user-centric perspective, this seems obviously the most convenient option. But given the very significant effort which would be required to coordinate this, it’s equally obvious that it can’t happen any time soon.

[hasufell]

@bradrn

From what I can see, this file looks very repetitive… is there no way to compress it somewhat to reduce transfer and parsing time? It would be really great to figure out a way to include this in GHCup somehow.

You might be surprised, but the actual transfer time is not the bottleneck.

@bradrn

From a purely user-centric perspective, this seems obviously the most convenient option. But given the very significant effort which would be required to coordinate this, it’s equally obvious that it can’t happen any time soon.

Also note that you now coupled the following things with GHC:

• release management
• release CI

Whether you consider that a good or bad thing is up to you to decide. I’m skeptical.

I believe one good side effect of the decoupling is that we have a good argument for demanding a stable GHC API. If we move every major project into GHC that needs a lot of its “internals”, then what do we end up with?

[bradrn]

@maxigit

It is more that just discoverability it is also about curating, the proposed packages have been selected by the community.

This is true: a commented-out Cabal file solves that much.

However, I am of the opinion that defaults matter — a lot. Basic types such as Text, Map, ByteString, State, FromJSON are really widely used in Haskell code, and I want to make it as easy as possible for people to get started using the Haskell ecosystem. Leaving packages commented-out by default does not achieve that goal.

@maxigit

I though you wanted something battery included so basically text, containers, possibly aeson, maybe cassava for csv, some networking lib, and sql one (you’ll need to chose between mysql, sqllite, psql etc …). Maybe a new Prelude, a simple hhtp server ?

I’d like the selection to be as unopinionated as possible. So: most (if not all) of the boot libraries, probably aeson and cassava, probably a networking library, maybe some other common utilities like optparse-applicative or even lens, but nothing related to webservers or SQL (because there’s too many competing options), and definitely not a new Prelude.

@maxigit

@hasufell

GHCup is an installer, not a cabal file templating mechanism.

Fair enough. What about resurrecting Haskeleton (or equivalent) and have GHCup installing it ?

That would be fine with me as a first step. I’d be interested to hear @taylorfausak’s views on it (as the creator of Haskeleton).

Like I said, I’m also working on my own idea for a templating application: hopefully I can share a first version in a few days.

@hasufell

You might be surprised, but the actual transfer time is not the bottleneck.

Hmm, then what is? (Surprise me!)

@hasufell

I believe one good side effect of the decoupling is that we have a good argument for demanding a stable GHC API. If we move every major project into GHC that needs a lot of its “internals”, then what do we end up with?

I agree with this. It’s a good point.

[hasufell]

@bradrn

Hmm, then what is? (Surprise me!)

Process spawning (we use curl, not non-audited TLS haskell libraries), establishing connection overhead (HTTPS etc), yaml parsing. Although parsing is fairly fast now too, even with multiple MB, so there’s a constant overhead and a very low increase with size. I don’t think compression will get us anywhere.

[taylorfausak]

Haskeleton started as a repository that people could use as a template. Then I heard about hi and converted it to work with that. Then Stack added the ability to initialize projects with templates, so I added it to that.

All that to say, there are plenty of ways to make templates for Haskell projects. Haskeleton has done most of them, although I stopped maintaining it a long time ago. These days I would probably just make a template repository:

Creating a template repository - GitHub Docs

[michaelpj]

It would be very nice to simplify the distribution story for HLS. In case anyone is interested, I attempted to summarise the issues here: HLS and the user's GHC · Issue #3671 · haskell/haskell-language-server · GitHub

[vanceism7]

I feel like this has been a pretty productive conversation, with a couple of different actionable items that have come out of it. They’ve been summarized above atleast once, but I figured maybe I should re-summarize (along with ideas I’ve seen floating around in other posts)

I see a couple of different potential project ideas:

• Some type of templating system for cabal/stack
• cabal add <package> (for adding dependencies)
• Some type of cabal gen-deps command which, from imported modules, can automatically insert all required packages into build-depends. (This seems like a natural extension of cabal add <package>)
• A minimal fallback ide server for HLS (integrate dante into hls?)
• A better story for editor support outside of vscode (like emacs)
• Local Modules / Fixing the “duplicate field name/duplicate constructor” problem
• Make code formatting tools easier to use

I dont know if something exists for this or not, but I can envision some type of “Haskell Convenience Committee” or “Haskell Tooling Committee”, or something! It would be nice if there was at least some type of Haskell Foundation official repo for tracking requests/conversations about reducing all the papercuts in the ecosystem.

These concerns are obviously very spread out amongst all the Haskell tooling; most of them would require the insight and cooperation of the various project maintainers to decide if the ideas are feasible, to help steer the ideas in a feasible direction, and to aid with guidance or implementation. But if there’s not already an official place for storing wish list items like stuff we’ve discussed here, I think it would be helpful to create one.

[george.fst]

@vanceism7

It would be nice if there was at least some type of Haskell Foundation official repo for tracking requests/conversations about reducing all the papercuts in the ecosystem.

There may well be benefits to having something more official, but in the meantime there’s @tomjaguarpaw’s Tilapia, which aims to track a lot of these cross-project issues.

[mpilgrem]

That is correct: with stack script, if no packages are specified, all the required packages that are in the snapshot or are a GHC boot package are deduced by reference to the import statements in the source file. The base package associated with the version of GHC specified by the snapshot is always available.

[bradrn]

@vanceism7 That’s a really great summary, thanks!

@vanceism7

• Local Modules / Fixing the “duplicate field name/duplicate constructor” problem

I don’t recall this being discussed, though; could you elaborate please?

@vanceism7

I dont know if something exists for this or not, but I can envision some type of “Haskell Convenience Committee” or “Haskell Tooling Committee”, or something! It would be nice if there was at least some type of Haskell Foundation official repo for tracking requests/conversations about reducing all the papercuts in the ecosystem.

I second this. The whole point of the Haskell Foundation is to coordinate such things, after all.

@george.fst

There may well be benefits to having something more official, but in the meantime there’s @tomjaguarpaw’s Tilapia , which aims to track a lot of these cross-project issues.

Oh, I didn’t know about this. It doesn’t seem to be too well-known, unfortunately, which limits its usefulness. A good first step might be to make this more ‘official’.

[sclv]

Imho the best place for a lot of these things to live is as enhancement requests in the trackers for the individual projects. If its for projects that don’t yet exist, the issues section of the haskell tech proposals repo is a place to create tickets that might later involve into proposals seeking HF support Issues · haskellfoundation/tech-proposals · GitHub

[vanceism7]

@bradrn

@vanceism7

• Local Modules / Fixing the “duplicate field name/duplicate constructor” problem

I don’t recall this being discussed, though; could you elaborate please?

This wasn’t discussed here, but I referenced it in the neohaskell conversation. One of the very annoying bits of Haskell for me is the whole issue with duplicate record fields and duplicate data constructors. It’s quite annoying that i can’t do:

data Person = Person
  { name :: Text, ... }

data Company = Company
  { name :: Text, ... }

-- Or
data Breakfast = Eggs | Banana

data Lunch = Sandwich | Banana

Without running into duplicate name errors. Even if you use the duplicate fields extension, you still run into ambiguous type errors. The only way to currently work around this is to move the types into separate modules, or add prefixes to the names, which is a big pain. Richards local Modules Proposal would give namespaces to these things by default, so you could access them like Person.name or Breakfast.Banana.

@sclv

Imho the best place for a lot of these things to live is as enhancement requests in the trackers for the individual projects.

Yea that’s true, but I also think there’s some value to aggregating these types of requests, so there’s a centralized place where people find all the different initiatives being worked on to improve QOL.

I didn’t know about Tilapia either, that’s really cool. Making it an officially recognized haskell foundation repo is probably a good next step. I think we need to do more to make it known that we care about this as a community, and maybe help focus efforts towards fixing some of this stuff

[bradrn]

@vanceism7

This wasn’t discussed here, but I referenced it in the neohaskell conversation.

Thanks for explaining!

[puppo]

@vanceism7

Yea that’s true, but I also think there’s some value to aggregating these types of requests, so there’s a centralized place where people find all the different initiatives being worked on to improve QOL.

I think this in turn could help initiatives that aim to attract and welcome new people to Haskell (and perhaps some to return). The technical advantages are one thing, and I personally find a lot to love in that – they’re great ‘selling points.’ They’re just not the only ones!

I could see Haskell promoting itself along the lines of:

You too can do an awful lot of (#@$ with Haskell from day one, check it out: [… ad hoc plotting … data parsing/wrangling … command line tools … http(s) APIs … blah blah blah …]

AND, if or when you’re interested in going deeper into [… highlighted advanced and active research topics …], Haskell’s got your back bro.

Obviously not necessarily in that tone, but does that make sense? What @bradrn was looking for in the OP, plus a few other easily-overlooked low-hanging fruit that Haskell as a general purpose language really can do exceedingly well at, while presenting an entry point to so much more.

I guess what I was getting at with the npx create-react-app post above was:

• Providing an attractive gateway to the ecosystem for a selection of common projects (however basic they might seem), but maybe also a couple of ‘almost everything but the kitchen sink’ options?
• The tool does not need to do everything for everybody (I guess it could be expanded on with other templates), it just needs to offer a few interactive questions that would provide a suitable environment for a potential new programmer (rather than leave them to their own devices amongst the myriad of options in Haskell multiverse).
• A brief statement explaining the options in the interactive tool would be nice. e.g., cabal vs stack; nix vs not-nix.
• A few closing statements after the tool has finished would also be nice. create-react-app used to (I guess it still does) leave you with some links and suggestions and so on. Bonus points if the basic project type has a brief-'n-cheerful tutorial associated with it that folk can follow along. But it wouldn’t hurt to setup the scaffold project as a minimal, working, project including comments that someone pretty new to Haskell could follow.

If this all sounds too much, or confused, or whatever – that’s cool. Just throwing it out there before I get distracted again. (Every time I’ve come back to this thread to flesh out what I had in mind I’ve found so many cool things I didn’t know existed to look into instead … )

On the bright side? This could be orders of magnitude less complex than the actual create-react-app. That thing has to contend with Lovecraftian Horrors left, right, and from n-dimensions.

-e- TLDR: ‘Haskell, what is it good for?’ ‘Well, in fact … [a highlighted selection of general purpose app types, that will behave well, look beautiful, and can be refactored however you see fit].’ i.e., it’s not just for the 130+ IQ kids’ to toy around with and troll each other, although you can get in on that game if you want.

[george.fst]

@vanceism7

Even if you use the duplicate fields extension, you still run into ambiguous type errors. The only way to currently work around this is to move the types into separate modules, or add prefixes to the names, which is a big pain.

Well, the other way is to use NoFieldSelectors (and access fields via puns, wildcards, dot syntax, or overloaded labels for optics). Admittedly this does nothing for constructors, but I’ve found duplication there a lot less of an issue in practice than with fields.

[vanceism7]

Ah, I suppose I missed my specific use-case with my example. The one area I ran into issue with this was record update syntax.

modifyCompany company =
  company { name = "some new name" }

modifyPerson person =
  person { name = "johnny boy" }

I typically use record dot syntax but it doesn’t save me from this scenario. I get ambiguous field errors and have to go through the trouble of redundant qualified imports where I import Person and Company separately to fix it.

I don’t run into duplicate data constructors as much, but it does happen to me there as well

[george.fst]

Yeah, OverloadedRecordUpdate should fix this, but it seems to have had quite a few setbacks.

In the meantime, I’m fairly happy with modifyCompany Company{..} = Company{name = "some new name", ..}

[angerman]

OverloadedRecordUpdate is highly experimental and can change without warning at any time and will.