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

Interfaces (AKA Type Types) #749

Open
dfellis opened this issue Jun 10, 2024 · 2 comments
Open

Interfaces (AKA Type Types) #749

dfellis opened this issue Jun 10, 2024 · 2 comments

Comments

@dfellis
Copy link
Member

dfellis commented Jun 10, 2024

Restoring interfaces to Alan blocks a lot of the standard library from being trimmed down significantly.

It's very similar to generic functions both conceptually and by implementation, except the checking and casting of a function into an actual function happens during function dispatch, checking if the provided type matches the interface, so the function call does not require explicit generic types when calling it in those cases, but it can only derive its behavior on the inputs, while generic functions can handle situations beyond that.

This should mix cleanly with generic functions, where the generic function declares a generic type or types for some things and an interface type or types for others: this would first construct the scope for the generic types to resolve them, offering up a new function which has interface arguments, which it would then confirm match the types of the values being provided.

This will require a new function type enum, probably.

@dfellis dfellis added this to the v0.2 release milestone Jun 10, 2024
@dfellis
Copy link
Member Author

dfellis commented Jun 29, 2024

Since this was written, implementing type inference with generic functions was done, so the way interfaces were used in Alan 0.1 is no longer necessary.

So, rather than further polluting the type scope with interfaces, making them actually "type types" that constrain on generic types (and allow for specified functions to be called on them) is the only place they'll be used in the syntax.

Also, the only kind of interface definition is the function declaration. Since operators map to only one function, they are now redundant, and since properties are simply functions now, they are also unnecessary.

This should make them easier to implement and clearer on their use.

Having the import of an interface also pull in all matching types and functions is still the intended behavior, so they will be "class-like" and I am not sure if there should be a class syntactic sugar or not. I think classes are a narrow box to confine your design in, but they are also the window a lot of developers view things, so not including it may be off-putting.

@dfellis dfellis removed this from the v0.2 release milestone Nov 7, 2024
@dfellis
Copy link
Member Author

dfellis commented Nov 7, 2024

Removing this from blocking the v0.2 release. It'll lead to nicer compiler errors but nothing else, so it's not really necessary for the initial launch.

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

1 participant