dfellis
commented
2 months ago 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.
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.