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

[RFC] Implement type inheritance #142

Closed
faultyserver opened this issue Jan 31, 2018 · 0 comments
Closed

[RFC] Implement type inheritance #142

faultyserver opened this issue Jan 31, 2018 · 0 comments
Labels
feature-request Any request for a new feature of the language. Includes both syntax and library features. rfc A request for comments from the community semantics.interpreter Any issue relating to changing the semantics of interpreter code. semantics Generic label for semantics issues. All semantics issues should have this tag. syntax Any issue relating to the syntax of Myst.
Milestone

Comments

@faultyserver
Copy link
Member

While talking about how to re-implement IO as a type rather than a module, it seemed to make the most sense to have IO be a supertype that other types can inherit from. For example, a Socket is an IO and a FileDescriptor is an IO. With the original idea of using module composition, the semantics would be more that Socket is a type that acts like an IO.

Assuming that inheritance is added to the language, the question then becomes how it should be represented in the syntax. I see two decent options for how this could work:

  • Following influence from Ruby and Crystal, use the < operator as a keyword:
deftype Foo < Bar
  # ...
end
  • Borrow the syntax from C++, using ::
deftype Foo : Bar
  # ...
end

I like the second option more, because it fits nicely with the existing syntax for type restrictions on method parameters.

The other consideration is how this will work in the interpreter itself. The simplest solution seems to be adding another property, supertype, to TType. Then, TType#ancestors will call #ancestors on the supertype and append the result to the list it already created.

Since Myst doesn't support singleton classes or other metaprogramming concepts like Ruby/Crystal does, I think this implementation will be sufficient for most cases.

@faultyserver faultyserver added rfc A request for comments from the community syntax Any issue relating to the syntax of Myst. semantics Generic label for semantics issues. All semantics issues should have this tag. feature-request Any request for a new feature of the language. Includes both syntax and library features. semantics.interpreter Any issue relating to changing the semantics of interpreter code. labels Jan 31, 2018
@faultyserver faultyserver added this to the Next milestone Feb 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Any request for a new feature of the language. Includes both syntax and library features. rfc A request for comments from the community semantics.interpreter Any issue relating to changing the semantics of interpreter code. semantics Generic label for semantics issues. All semantics issues should have this tag. syntax Any issue relating to the syntax of Myst.
Projects
None yet
Development

No branches or pull requests

1 participant