Vapor is a language made as a part of the Reaver Project effort. The name has originated as a word play on a word "vaporware" - the author often called this language a "vaporlang", and later decided to keep that name.
The matching algorithms for "is this a specialization of that typeclass function?" for the purposes of recognizing what is going on in the first place is currently limited to matching by the number of arguments. This of course limits overloading beyond what I want the limits to be, and has to be fixed in a future version of the compiler.
[ ] This limitation must become documented and handled as an error at typeclass definition - I'd really prefer the compiler to tell the users how limited the overloading is in typeclasses, instead of them getting weird results somehow (like getting the compiler to infer the wrong parameter type for an overriden function in an instance definition - that'd be awkward).
Implementation notes
This section of this comment exists literally to let me wrap my head around a possible implementation strategy for typeclass instances, as this appears to be a part of the compiler that will actually require having notes for me to be able to implement this (and even verify that I'm doing things in roughly the right way).
Steps to instantiate a typeclass and then get an actual instance:
Create a bare bones instance expression object; this needs to refer to the original templated type. Save the arguments here (or is it even necessary?). Track functions/function declarations that haven't been overwritten yet in this class. (This will be an additional vector; is there a chance I could introduce an intermediate "builder" class for this? Probably; try to do this when first implementing the thing..)
The bare bones instance expression object should also, at the same time, cache an actual type of instances (i.e. seeing how the template is function (parameters...) -> typeclass, this is the value of type typeclass).
The expression from (1) should be saved in the instantiations cache, even though it won't be very expensive, really. (As this is just the entry point, this shouldn't be very expensive, but nevertheless we can just cache it.)
Copy the cached "builder".
Go through definitions in an instance_literal, adding them to the builder. Match each of them against the original typeclass literal.
Make it an error to define something multiple times.
Make it an error to define something that wasn't defined in the typeclass.
Make it an error to define a function unmatched in the typeclass literal.
Make it an error to declare a function. (Check that this is actually guaranteed on the parser level!)
For each named function definition, make sure there's an overload_set that's specific to this instance that has the functions added.
If there are some declarations in the typeclass literal that weren't overriden in the instance literal, error and tell the user to define them.
If there are some definitions in the typeclass literal that weren't overriden in the instance literal, instantiate those (here's where the points below - about analysis_context - come into light). Make sure the functions land in a new overload_set that's specific to this instance. (Same note as last bullet point in (4).)
General notes I couldn't capture in the sketch of the algorithm above:
function_declarations and functions from typeclass_literal should be cloned/instantiated/whatever as lazily as possible; this means that they mustn't be cloned in step 1, which will be slightlyextremely awkward.
Here's also other random notes that I made to myself when writing down the above points:
In analysis_context, the instantiations cache needs to be able to hold statements, and not just expressions (function declarations and definitions will also be instantiated!).
In analysis_context, the instantiations cache needs to keyed off more than just template_expression; within a single typeclass template, for instance, there will be multiple things that will be instantiated. Quite possibly it can be keyed off statement *, to the underlying templated statement,
In the future, template_expression will need to be extended to statements, though it's quite possible that template_expression will remain and the compiler will get a separate template_statement thing.
Some problematic things
template_expression's "call operator" function won't be as simple as just doing _instantiate. For typeclasses, it'll need to look for the default instance (possibly creating it when necessary). For simple types templates, it will just do _instantiate. I don't know what to do about function templates yet. Last idea was that function templates wouldn't be callable, i.e. actual template arguments to functions would always be non-deducible; in which case, the call operator for the template would also just return a function that you'd then call, in which case typeclasses alone would be special here; but I think that's fine.
There's something that kind of appears like an unsoundness of the original idea for the system, that became apparent to me after typing down the above points (very much the previous one). The type of a template expression is function (typeof(parameters)...) -> typeof(templated_expression). In case of typeclasses, typeof(templated_expression) is typeclass. This is consistent with how instance definitions function: they define an instance, that is - an object of type T(arguments...) (where T is a typeclass). Now... in regular code, the way I wanted things to work, was for T(arguments...) to actually fetch the default instance of T, so the result of this wouldn't be of type typeclass - the type of that expression would be the value of type typeclass that results from applying the template. This seems deeply wrong.
I can fix this problem by making T(arguments...) always refer to the type of instances, and give it a member or a member function called ??? (need to bikeshed the name so hard). This would make it less convenient to get the default instance, but would fix the unsoundness and inconsistency of the system.
After bikeshedding with some people, here's the solution: T(arguments...) refers to the type of instances; default(T(arguments...)) refers to the default instance of T(arguments...).
Current and/or expected limitations
The matching algorithms for "is this a specialization of that typeclass function?" for the purposes of recognizing what is going on in the first place is currently limited to matching by the number of arguments. This of course limits overloading beyond what I want the limits to be, and has to be fixed in a future version of the compiler.
Implementation notes
This section of this comment exists literally to let me wrap my head around a possible implementation strategy for typeclass instances, as this appears to be a part of the compiler that will actually require having notes for me to be able to implement this (and even verify that I'm doing things in roughly the right way).
Steps to instantiate a typeclass and then get an actual instance:
function (parameters...) -> typeclass, this is the value of typetypeclass).instance_literal, adding them to the builder. Match each of them against the original typeclass literal.overload_setthat's specific to this instance that has the functions added.analysis_context- come into light). Make sure the functions land in a newoverload_setthat's specific to this instance. (Same note as last bullet point in (4).)General notes I couldn't capture in the sketch of the algorithm above:
function_declarations andfunctions fromtypeclass_literalshould be cloned/instantiated/whatever as lazily as possible; this means that they mustn't be cloned in step 1, which will beslightlyextremely awkward.Here's also other random notes that I made to myself when writing down the above points:
analysis_context, the instantiations cache needs to be able to hold statements, and not just expressions (function declarations and definitions will also be instantiated!).analysis_context, the instantiations cache needs to keyed off more than justtemplate_expression; within a single typeclass template, for instance, there will be multiple things that will be instantiated. Quite possibly it can be keyed offstatement *, to the underlying templated statement,template_expressionwill need to be extended to statements, though it's quite possible thattemplate_expressionwill remain and the compiler will get a separatetemplate_statementthing.Some problematic thingstemplate_expression's "call operator" function won't be as simple as just doing_instantiate. For typeclasses, it'll need to look for the default instance (possibly creating it when necessary). For simple types templates, it will just do_instantiate. I don't know what to do about function templates yet. Last idea was that function templates wouldn't be callable, i.e. actual template arguments to functions would always be non-deducible; in which case, the call operator for the template would also just return a function that you'd then call, in which case typeclasses alone would be special here; but I think that's fine.There's something that kind of appears like an unsoundness of the original idea for the system, that became apparent to me after typing down the above points (very much the previous one). The type of a template expression isfunction (typeof(parameters)...) -> typeof(templated_expression). In case of typeclasses,typeof(templated_expression)istypeclass. This is consistent with how instance definitions function: they define an instance, that is - an object of typeT(arguments...)(whereTis atypeclass). Now... in regular code, the way I wanted things to work, was forT(arguments...)to actually fetch the default instance ofT, so the result of this wouldn't be of typetypeclass- the type of that expression would be the value of typetypeclassthat results from applying the template. This seems deeply wrong.I can fix this problem by makingT(arguments...)always refer to the type of instances, and give it a member or a member function called???(need to bikeshed the name so hard). This would make it less convenient to get the default instance, but would fix the unsoundness and inconsistency of the system.After bikeshedding with some people, here's the solution:
T(arguments...)refers to the type of instances;default(T(arguments...))refers to the default instance ofT(arguments...).