haskell-servant / haskell-servant/servant
Introduce (:/) alongside (:>) for segment separation
- Dominant language
- Haskell
- Stars
- 2k
- Forks
- 427
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 5
Description
cc @ysangkok @fisx @clintonmead @arybczak
I'd like to request your opinions about introducing the `(:/)` operator alongside the `(:>)` to fullfill the same purposes: Segment separation in URLs.
## Why
The reasoning here is double:
* People separate URLs with a forward slash, it's natural that we reflect this in the API. Servant is alreay **a lot** to absorb, I think it is right that we remove some unnecessary cognitive burden on the newcomers;
* It's conflicting with a bunch of other APIs (optics, effectful, bluefin, massiv, etc.) See on [Hoogle](https://hoogle.haskell.org/?hoogle=(%3A%3E)).
## Scope
I am not suggesting that we deprecate `(:>)` outright, not before a well-advertied timeline and rigorous deprecation process.
We can do one of two things:
1. Re-define `(:>)` in terms of `(:/)`, which means that GHC will output `(:/)` in some places where `(:>)` is used, in the case of errors.
2. Duplicate every instance, and so error messages are kept in sync with the written code. This brings in much more code, but removes confusion.
Contributor guide
Research direction
No files or tests are named. Start by locating the existing (:>) operator and its usages, then compare the proposed (:/) alternatives, including their effect on error messages and duplicated instances. Done means the maintainers have selected an approach and the resulting API behavior is implemented consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- haskell
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100