`val rec` and nested match

[minoki]

I think it is sensible to disallow nested match in val rec, but I couldn't find such words in the definition. Am I missing something?

In HaMLet S, the following code results in a runtime error.

val rec (f with () = print (g "X")) = fn x => x
and (g with () = print (f "Y")) = fn y => y;

[JohnReppy]

My preference would be to eliminate rec and just make fun the primitive.

Since the Definition already imposes a syntactic restriction on val rec bindings (i.e., the r.h.s. must be a fn expression),
we could restrict the l.h.s. to variables with an optional type constraint.

[ratmice]

Isn't this covered by footnote 25 on valbind in the sml97 definition, causing anded vals to be disjoint?

(25) When the option is present we have Dom VE ∩ Dom VE′ = ∅ by the syntactic restrictions.

I personally have found val rec to be syntactically preferred occasionally as it can be more concise...

[JohnReppy]

Restriction (25) is there to prevent redefinition of identifiers in the binding, such as in the following code:

val x = 12 and x = 13;

Definitions like the following are permitted:

val rec f = fn x => g x and g = fn y => f y;

Since fun is just syntactic sugar for val rec they must be allowed to support mutual recursion.

[YawarRaza7349]

Maybe I'm the one who's missing something, but I think it makes more sense to allow nested matches, but simply not have the variables being introduced available in them, the same as a non-rec val would be. Add the newly introduced variables to only the RHS of each binding. So:

val f = fn x => "Old f: " ^ x
val g = fn y => "Old g: " ^ y
val rec (f with () = print (g "X")) = fn x => "New f: " ^ x
and (g with () = print (f "Y")) = fn y => "New g: " ^ y;

would print:

Old g: X
Old f: Y

while your example would be a "name not found" error at compile time.

[JohnReppy]

I'm not sure that I understand your proposal; are you suggesting that if one has val rec p1 = e1 and p2 = e2 and p1 is nested, then its bound identifiers are not available in e2?

[YawarRaza7349]

No, its bound identifiers are available in both e1 and e2. But they're not available in p1 or p2 in the nested match expressions, which is where the uses of f and g appear in minoki's example.

[JohnReppy]

I think that there are some technical challenges with this approach. Because e1 is defined in terms of the variables in p2, if p2 has a guard pattern then the binding might fail and e1 cannot be evaluated. Restricting p1 and p2 to irrefutable patterns greatly simplifies the implementation issues with little loss of useful expressiveness.
I would propose the following specification:

A pattern is trivial if it is a variable, wildcard, or trivial pattern constrained by a type.

The left-hand side of a val rec binding must be a trivial pattern and the right-hand side must be a fn expression.

For SML, the fact that the right-hand side already must be a fn implies that the left-hand side must be trivial, so this restriction is backward compatible.

[rossberg]

That makes sense to me. If you want full backwards compatibility with SML'97, you'll also need to allow as patterns, however.

[JohnReppy]

Right. So it should read

A pattern is trivial if it is a variable, wildcard, an as pattern involving trivial patterns, or a trivial pattern constrained by a type.

The left-hand side of a val rec binding must be a trivial pattern and the right-hand side must be a fn expression.

[dmacqueen]

Since a function can only be bound to a variable in a val rec, allowing “as” patterns is pointless — it just introduces an “alias” for the function name, and it is not obvious whether that alias should be used in the right hand side(s) of the val rec. If you really need an alias for a function “foo”, how about writing val rec foo = <fn exp> val foo1 = foo The only possible drawback would be that you could not use the alias “foo1” in the rhs of the foo declaration. GENERAL OBSERVATION: The “Definition” (say 97) was not a document handed down to us mortals by the gods. It is a man-made document with bugs and omissions and design errors. Bugs, omissions, and design errors do not deserve to be regarded as unfixable, and when thinking about fixing them, one is not under the obligation to try to divine the “intensions” of the original definers. But fixes should attempt to improve the language. When fixing something, it is better to simplify rather than complicate.

On Jul 3, 2023, at 9:36 AM, John Reppy ***@***.***> wrote: Right. So it should read A pattern is trivial if it is a variable, wildcard, an as pattern involving trivial patterns, or a trivial pattern constrained by a type. The left-hand side of a val rec binding must be a trivial pattern and the right-hand side must be a fn expression. — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGXNPLFH3CCG7XNSTVRYGTXOLYITANCNFSM6AAAAAAZESR5D4>. You are receiving this because you are subscribed to this thread.

David MacQueen ***@***.***