Proc and Lambda type syntax for block parameters

[yhk1038]

In this discussion,
I would like to review the 'Proc and Lambda type syntax for block parameters.'

Addressing this topic is a crucial part of T-Ruby's coverage of Ruby and represents a significant step forward.

I am grateful that @dfl has taken the lead by submitting this implementation as a PR (#38 #39).
Special thanks to @dfl for the contribution.

[yhk1038]

Summary of Proposed Syntax

Here's a summary of the syntax proposed in PR #38 and #39.

---

PR #38: Proc and Lambda Type Syntax

Proposed Syntax

1. Proc Type

# Syntax: Proc(ParameterTypes) -> ReturnType
def each(&block: Proc(Integer) -> void): void
  yield 1
  yield 2
end

def map_values(&block: Proc(Integer, Integer) -> String): Array<String>
  []
end

2. Lambda Type (stricter argument checking than Proc)

def strict_call(&block: Lambda(Integer) -> void): void
  yield 1
end

3. Optional Block Parameter (&block?)

def maybe_yield(&block?: Proc(Integer) -> void): void
  if block_given?
    yield 1
  end
end

RBS Conversion

T-Ruby	RBS
Proc(Integer) -> void	^(Integer) -> void
&block: Proc(Integer) -> void	{ (Integer) -> void }
&block?: Proc(Integer) -> void	?{ (Integer) -> void }

---

PR #39: Yield Statement and Expression Support

Proposed Syntax

1. Yield Statement

yield              # no arguments
yield x            # single argument
yield x, y, z      # multiple arguments
yield(x)           # parenthesized form
yield x if cond    # conditional modifier

2. Yield Expression

result = yield(value)  # capture block return value

3. Type Validation

def process(&block: Proc(Integer) -> String): void
  yield 42       # OK: Integer type
  yield "text"   # Compile error: expected Integer, got String
  yield 1, 2     # Compile error: expected 1 argument, got 2
end

[yhk1038]

TL;DR

How about this?

T-Ruby (PR)	T-Ruby (My opinion)	RBS
Proc(Integer) -> void	Proc<(x: Integer) => void>	^(Integer) -> void
&block: Proc(Integer) -> void	&block: Proc<(x: Integer) => void>	{ (Integer) -> void }
&block?: Proc(Integer) -> void	&block?: Proc<(x: Integer) => void> | nil	?{ (Integer) -> void }

Thoughts on Syntax Style

@dfl, these are my personal thoughts. My opinions don't need to be unconditionally accepted. I want to emphasize that I'm always open to discussion and improvement if there are better ideas.

Introduction

While static type transpiling is the core of T-Ruby, we aim to avoid novel or experimental syntax styles and instead pursue type syntax as close to TypeScript as possible.

• From a practical standpoint (not academic linguistics), TypeScript is a well-proven syntax system.
• Among proven syntax systems, we believe it least compromises the joy of writing Ruby.

We believe this approach brings lower learning costs and higher productivity for more developers and AI.

---

1. On Function Object Types

In Ruby, both Lambda and Proc are objects. This is a core philosophy of Ruby.

• Since Proc and Lambda are classes, static types should maintain syntactic consistency with other classes.
• We find RBS's approach (^(x) -> y) adds confusion rather than clarity.
• Lambda is also a subtype of Proc.

The proposed Proc(x) -> y is a unique form.

Alternative Proposal: Proc<(x: T) => R>

# Proposed syntax
def each(&block: Proc(Integer) -> void): void

# Alternative proposal
def each(&block: Proc<(x: Integer) => void>): void

Rationale:

• Makes it clear that Proc is a class and the block is an instance of Proc
• Consistent syntax with other generic types (Array<T>, Hash<K, V>)
• Injects TypeScript's function type (x: T) => R as a generic argument

---

2. On Block Parameters

Type Constraints

• Only Proc and Lambda types should be allowed for block parameters.

Type Inference

• If no type is specified, it should be inferred as Proc<(x: untyped) => untyped>.
• Since Lambda is a subtype of Proc, the ancestor of a block is always the Proc class.

# When type is not specified
def each(&block)
# block is inferred as Proc<(x: untyped) => untyped>

# Expressed with generics
def each<T, R>(&block: T): R
# T implicitly extends Proc<(x: untyped) => untyped>

# Explicit constraint
def each<T extends Proc<(x: untyped) => untyped>, R>(&block: T): R

# Restricting to Lambda
def strict_each<T extends Lambda<(x: untyped) => untyped>, R>(&block: T): R

# Of course, you can define types directly without using generics.
def each(&block: Proc<(x: untyped) => untyped>)
def each(&block?: Proc<(x: untyped) => untyped> | nil) # nillable
def each<X, Y, R>(&block: Proc<(x: X) => Y>): R # generic can be used for inside function of proc

---

Note: This discussion does not cover which function type definition is better among (x: T) => R vs (T) => R vs (T) -> R.

For now, we will use (x: T) => R as the standard.
Adding support for anonymous parameter syntax (T) => R through future improvements seems like a reasonable idea.