Open saem opened 1 year ago
doesnt it means that type T is not simple anything, but have to implement init proc? maybe go to finalising concept
way
type A = concept a
a.init() is ref A | void
proc create[T: A](): ref T =
new result
init result
doesnt it means that type T is not simple anything, but have to implement init proc? maybe go to finalising
concept
way
IIUC, then yes, over time that's the conclusion I'm arriving at too. That the first real fix is to have working concept
s that capture the contract that the routine requires.
Core Issue
bind
andmixin
are template metaprogramming features, which generics are not. Generics, or parametric polymorphism, have to do with types.To put a very fine point on things:
Is a procedure type, with a type parameter, meaning the type changes (polymorphic) based on said type parameter. It can be read as,
foo
is a procedure type, where for all T (universal),T, T -> T
.It's not arbitrary syntactic "fill in the blanks", those are templates and those are entirely different. Doing this will drive a major step in substantially improving our type system and digging deep into the fun bits.
Solution/Approach
Steps:
bind
andmixin
from genericsSteps 1 - 3 are there to discover the rest of the detailed solution, because
mixin
is a poor facsimile for late static type safe binding, which is fundamentally very useful. So some sort of alternative approach is required for generics to fill the gap the removal ofmixin
, especially, will leave behind.If you'd like to work this issue please ping, @saem.
Early Thinking about Solution
This is mostly illustrative and not any sort of final design. The assumption is that early binding remains as the default behaviour and so the focus is on some
mixin
-ish feature/behaviour. Taking themixin
example form the manual (reproduced below):With whatever
mixin
-ish thing we end up with, it should be equivalent to the following -- ignore the syntax, it's merely approximating the approximate goal using existing constructs: