Skip to content
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

Mutually recursive datatypes #397

Closed
yihozhang opened this issue Jul 16, 2024 · 4 comments
Closed

Mutually recursive datatypes #397

yihozhang opened this issue Jul 16, 2024 · 4 comments

Comments

@yihozhang
Copy link
Collaborator

yihozhang commented Jul 16, 2024

Currently, datatypes cannot be mutually recursive. For example, the following is not allowed

(datatype Foo
  (foo Bar))

(datatype Bar
  (bar Foo))

OCaml supports mutually recursive type with the type ... and ... keyword. We can probably do something similar:

(datatype Foo
  (foo Bar)
and      Bar
  (bar Foo))

Or

(datatype Foo
  (foo Bar)
 andalso  Bar
  (bar Foo))

Or

(datatype*
  Foo
    (foo Bar)
  Bar
    (bar Foo))

Or (Jul 25 updates: we are more in favor of this syntax)

(datatype*
  (Foo
    (foo Bar))
  (Bar
    (bar Foo)))

Or maybe there is a better syntax for this?


Another pattern we commonly have (but is not supported) is

(datatype Expr
    (Call String VecExpr))
(sort VecExpr (Vec Expr))

Our recursive datatypes should also have a good support for this.

@saulshanabrook
Copy link
Member

FWIW in the Python bindings mutually recursive data types are supported through late binding type annotations. All classes/datatypes are translated to plain sort definitions & functions.

@oflatt
Copy link
Member

oflatt commented Jul 25, 2024

One advantage of this proposal is that it would still allow mutually recursive data types even if we made datatype closed, instead of open as it is now

@saulshanabrook
Copy link
Member

Thought: Could make all types "lazy", that would support recursive data.... With the current syntax, then we just defer processing until it's defined.

@saulshanabrook
Copy link
Member

This was fixed in #432

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants