fram-lang/dbl

Non-exhaustive pattern-matching as a warning instead of error

Open

#210 opened on Apr 2, 2025

View on GitHub
 (4 comments) (0 reactions) (0 assignees)OCaml (28 forks)auto 404
2.1. pattern-matchingerror messagesgood first issue

Repository metrics

Stars
 (46 stars)
PR merge metrics
 (PR metrics pending)

Description

Non-exhaustive pattern-matching could be optionally considered a warning. Such a behavior of the type-checker would simplify prototyping in Fram. For not-matched cases we could generate a call to built-in function "dbl_runtimeError", maybe even showing the counterexample of not-matched pattern. There is a minor design decision on what to do with non-exhaustive pure pattern-matching. Raising runtime-error should be considered as an effect [] (NTerm in Core), so I think, non-exhaustive pure pattern-matching should be an error.

Contributor guide

Research direction
Investigate the type checker code for pattern matching. Locate where non exhaustive match errors are raised. Modify to produce a warning and generate a call to dbl runtimeError for unmatched patterns. Ensure that pure pattern matching still raises an error due to effects. Test the changes.
Tech stack
None
Domain
compilers
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GitOCaml
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
50