gren-lang / gren-lang/compiler

Allow casing over multiple expressions

Open
#222 2 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

accepted language proposal
Dominant language
Haskell
Stars
503
Forks
29
PR merge metrics
No merged PRs in 30d

Description

Casing over multiple expressions is something that comes up in several cases. Currently, you can do this by wrapping things up in a record and casing over that.

-- a silly example, I know
case { left = 1, right = 3 } of
  { left = 1 } -> "Left is one!"
  { right = 1 } -> "Right is three!"
  _ -> "Left and right are not ones"

However, this isn't ideal as it requires allocating a data structure in order to perform the comparison, which is bad for hot loops. Also, for simple cases, it adds a bit of boilerplate (the names of the record fields) which, for a local single-used expression, doesn't add a ton of value.

To solve the efficiency problem, without loosing too much readability, one could allow for multiple expressions in a case of expression:

-- a silly example, I know
case 1, 3 of
  1, _ -> "Left is one!"
  _, 1 -> "Right is three!"
  _ -> "Left and right are not ones"

Alternatives

Previously Gren had tuples, which was quite often used for cases like these. However, tuples have the same performance overhead as records (they're compiled to the same thing) and tuples as a datastructre makes code more brittle as everything depends on the order of arguments. Positional semantics aren't that big of a deal in a single expression, but they're a problem when in a data structure.

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

No source files, tests, or compiler entry points are named in the issue. Start by locating the parser and compiler paths for case expressions, then assess the proposed multi-expression syntax and its performance implications. Done means the syntax is designed, implemented, and covered by relevant compiler tests.

Written by the indexing model from the issue text.

Assessment

Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.