haskell-servant / haskell-servant/servant

Introduce (:/) alongside (:>) for segment separation

Open
#1,915 4 comments 1 reaction 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.