8000 `val ... and rec ...` should parse · Issue #345 · smlnj/legacy · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

val ... and rec ... should parse #345

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
2 of 12 tasks
zbyrn opened this issue Feb 7, 2025 · 3 comments
Open
2 of 12 tasks

val ... and rec ... should parse #345

zbyrn opened this issue Feb 7, 2025 · 3 comments
Labels
bug Something isn't working compiler problem with compiler

Comments

@zbyrn
Copy link
Contributor
zbyrn commented Feb 7, 2025

Version

110.99.7.1 (Latest)

Operating System

  • Any
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

  • Any
  • Arm (using Rosetta)
  • PowerPC
  • Sparc
  • x86 (32-bit)
  • x86-64 (64-bit)
  • Other

System Component

Core system

Severity

Minor

Description

val rec f = fn _ => 3 and rec g = fn _ => 4

should be accepted by the parser. The definition (p. 78) defines the syntax for valbind as follows:

dec ::= val <tyvarseq> <valbind>
      | ...
valbind ::= <pat> = <exp> ⟨and <valbind>⟩
          | rec <valbind>.

This permits rec after and, but I believe the dynamic semantics is the same with or without the second rec.

Transcript

Standard ML of New Jersey [Version 110.99.7.1; 64-bit; January 17, 2025]
- val rec f = fn _ => 3 and rec g = fn _ => 4;
stdIn:1.24-1.33 Error: syntax error: deleting  AND REC IDA
stdIn:1.36 Error: syntax error found at FN
- ^D

Expected Behavior

No response

Steps to Reproduce

val rec f = fn _ => 3 and rec g = fn _ => 4;

Additional Information

No response

Email address

byronzhong@cs.uchicago.edu

@zbyrn zbyrn added the bug Something isn't working label Feb 7, 2025
@zbyrn zbyrn changed the title val ... and rec ... should be parse. val ... and rec ... should parse Feb 7, 2025
@dmacqueen
Copy link
Contributor

Yes, you are right that SML/NJ does not exactly follow the syntax of the Definition with regard to the rec modifier keyword. But there is general agreement that the Definition's grammar for value declarations, and rec in particular, is a bad design. In my MsML informal proposal, I suggest using only fun for recursive function declarations, and perhaps, if we ever introduce non-function recursive value declarations, we could use valrec as the keyword for those.

@zbyrn
8000 Copy link
Contributor Author
zbyrn commented Feb 10, 2025

I agree that some programs that the Definition permits, such as val rec rec rec rec ... and this, are nonsensical, but there may be benefits in allowing a Definition-compliant SML program to parse even by simply parsing and ignoring the rec keyword after and. If this is not planned, feel free to close this issue "as not planned."

In addition, if there isn't one already, I think we should maintain a list of SML/NJ's intentional deviations from the Definition, which could stop people from raising similar issues in the future.

@dmacqueen
Copy link
Contributor
dmacqueen commented Feb 10, 2025 via email

@JohnReppy JohnReppy added the compiler problem with compiler label Apr 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler problem with compiler
Projects
None yet
Development

No branches or pull requests

3 participants
0