p5pRT
commented
6 years ago From zefram@fysh.org
Created by zefram@fysh.org
Everyone would like to have type constraints in signatures\, but a prohibitive issue is that the core doesn't have a general type system. (There are classes\, but they don't address any of the type distinctions we frequently need to make between unblessed data types.) Smartmatch could become the core's type system\, as we've discussed a bit when talking about the future of smartmatch.
Suppose that the smartmatch/switch discussions lead to a version of smartmatch that we can all live with. (In the last round of discussion we seemed to be agreed on smartmatch semantics\, and it's just the given/when stuff that's holding us back.) This would be almost entirely based on explicit overloading of the smartmatch operator by blessed objects that appear on the rhs of smartmatch. We would expect to see a rich ecosystem of matcher object classes that implement all kinds of predicate\, including composite predicates that incorporate subordinate matcher objects.
Matcher objects can then be used as type metaobjects. In general they're types in only the minimal sense that they have a concept of type membership. Specific kinds of matcher object may also have other kinds of type-related behaviour; for example\, Moose class metaobjects would presumably overload smartmatch to implement a class membership check\, while also having introspective methods that only make sense for the Moose concept of a class. But we don't need to worry about that; for signatures the only aspect of a type that we care about is the membership predicate.
So a scalar signature item could specify a type constraint by referring to an appropriate matcher object. We'd want to permit an arbitrary expression for the matcher object\, to allow for parameterised and composite types. So very little signature syntax is required; really just a signifier for smartmatching and a grammatical slot into which to put the matcher expression. Using signature syntax otherwise as it is today\, this would look something like:
use Smart_Type qw(Num Str union HashRef_of); # imaginary module use feature "signatures"; sub gronk ($why ~Str\, $how_hard ~Num = 5) {...} sub annotate ($subject\, $msg ~ union(Str\, HashRef_of(Str))) {...} sub nom ($food ~ My::Food->meta = My::Apple->new) {...}
"~" references the smartmatch operator while not being longer than necessary. The matcher expression would have to be restricted to expressions above some middling precedence level\, so that in the case of an optional parameter it doesn't read the "=" and default value expression as part of the matcher expression. But I imagine matcher objects would also overload the bitwise operators to perform Boolean compositions\, so it would be nice for the threshold to be lower than those operators. Any expression of lower precedence than the threshold could of course be parenthesised. So we'd have things like:
use Smart_Type qw(Str HashRef_of); use feature "signatures"; sub annotate ($subject\, $msg ~ Str | HashRef_of(Str)) {...} sub frob ($spec ~ (state $fspec_type = gen_fspec_type())) {...}
With respect to the last of those examples\, usually the type we want to smartmatch against is fixed for all time\, and recomputing the matcher for each execution of the sub would be unwanted expense\, potentially significant. So making the matcher be implicitly saved in an invisible state variable might be a better way to go. However\, it's impossible to get fully dynamic type constraint logic (referring to earlier parameters) if that's always done\, so consideration should then be given to having a variant of "~" that explicitly makes the matcher expression dynamic.
In optional parameters I imagine the default value expression would be exempt from the type constraint\, but this could go either way.
It's a little more difficult to apply type constraints to array and hash parameters. We probably want to apply the type constraint to the whole array or hash\, for maximum flexibility\, but the actual smartmatch operand would have to be *a reference to* the array or hash\, so how do we indicate that in the signature syntax?
It's also necessary to think about how type constraints would interact with aliasing in signatures [perl #132472].
Migrated from rt.perl.org#132473 (status was 'open')
Searchable as RT132473$