tweag / tweag/linear-base

Which `IO` to export in `Prelude`

Open
#236 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Bikeshedding
Dominant language
Haskell
Stars
359
Forks
45
PR merge metrics
No merged PRs in 30d

Description

Currently, our Prelude.Linear is exporting the non-linear IO type; just because it is what Prelude has. But, we have a linear IO implementation, and one might argue that it should be the default one.


I do not have a clear opinion on this. I think:

Linear.IO:

  • (+) Fits the spirit of linear base.
  • (+) It supports lifting non-linear IO actions (fromSystemIO* family of functions), so it is not overly restrictive.
  • (-) It will probably force us to export Control functors.
  • (-) Might be an unnecessary overhead for people who don't use linear IO, and they might be the majority.

non-linear IO:

  • (+) Probably less surprising to users and easier to use.
  • (-) Requires us to also export a bunch of unrestricted stuff to be usable (unrestricted functors, simple IO functions like print).

I guess another option is to not have any IO type exported, and expect users to make an explicit choice. Which would actually be my preference if there is no clear verdict.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the exports of Prelude.Linear and the existing Linear.IO and non-linear IO APIs, including the fromSystemIO* functions and related Control functors. Compare whether Prelude should export linear IO, non-linear IO, or neither, and document or implement the project’s chosen direction with the required supporting exports.

Written by the indexing model from the issue text.

Assessment

Tech stack
haskell
Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.