leanprover / leanprover/lean4

RFC: ForIn keys on the value rather than the type

Open
#5,555 1 comment 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

do-notation P-low RFC
Dominant language
Lean
Stars
9.2k
Forks
990
Avg merge
1d 17h
Merged PRs (30d)
175

Description

Proposal

Currently, ForIn has the following type:

class ForIn (m : Type u₁ → Type u₂) (ρ : Type u) (α : outParam (Type v)) where
  forIn {β} [Monad m] (x : ρ) (b : β) (f : α → β → m (ForInStep β)) : m β

Note in particular that the class depends on ρ (the collection type) but not (x : ρ) (the particular collection being iterated over). This means that it is impossible to implement an iterator where the yielded element type depends on the value:

for x in (g : MyGraph) do
  -- x : VertexOf g

The current workaround for this is to define a wrapper type structure ElementOf (g : MyGraph) but this requires some boilerplate to set up, complicates usage code, and is also not very discoverable.

The way this situation can be improved is to move the (x : ρ) argument to a parameter, so that it can participate in typeclass inference such that α can depend on x:

class ForIn (m : Type u₁ → Type u₂) {ρ : Sort u} (x : ρ) (α : outParam (Sort v)) where
  forIn {β} [Monad m] (b : β) (f : α → β → m (ForInStep β)) : m β

(Note, I've also changed Type to Sort in two places here. I believe the use of Type in this position is not necessary, but this can be considered separately if desired.)

This impacts mainly users of the ForIn typeclass, namely libraries for programming such as Batteries, as well as users that have set up their own iterable collection types.

Community Feedback

This was recently discussed on Zulip.

Impact

Add 👍 to issues you consider important. If others benefit from the changes in this proposal being added, please ask them to add 👍 to it.

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 with the ForIn class declaration shown in the issue, then inspect its downstream users, especially Batteries and custom iterable collection types. Evaluate how moving the collection value into the class parameters affects typeclass inference and dependent yielded types, and consider the proposed Sort changes separately. Done means a reviewed design or implementation that supports the MyGraph/VertexOf g example without the ElementOf wrapper and accounts for affected users.

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
Quiet
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.