smartmatch signatures

Another signatures issue we should think about: smartmatch-based types.
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 Hash_of);   # imaginary module
    use feature "signatures";
    sub gronk ($why ~Str, $how_hard ~Num = 5) {...}
    sub annotate ($subject, $msg ~ union(Str, Hash_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 Hash_of);
    use feature "signatures";
    sub annotate ($subject, $msg ~ Str | Hash_of(Str)) {...}
    sub frob ($spec ~ (state $fspec_type = gen_fspec_type())) {...}

The details of this are all open to discussion, but right now the details
don't matter, because we're still some way from having a smartmatch
that could be used for this purpose.  More useful at this stage would
be some agreement in principle on whether we want something like this,
and its coarser features.  But what we *really* ought to think about
now is how the likelihood of this happening affects the experimental
status of signatures.  Specifically, should we hold off from declaring
signatures stable until this feature has been implemented?

There isn't any need for such delay for simple users of signatures,
because we can always add this feature later without breaking anything.
But adding it later poses a problem for any module providing plugged-in
syntax that wants to imitate and extend the core syntax for a signature
item.  Given the popularity of signature-like syntax on CPAN, it
seems likely that some will pop up, and it's a reasonable thing to do.
Should we expect them to implement a partial core syntax at first and then
add a new bit to it later?  Inevitably they wouldn't all do it, and some
would be left deficient.  If we know that the core signature syntax isn't
complete yet, keeping it marked experimental could be a useful indicator.

-zefram

• smartmatch signatures by Zefram
• Re: smartmatch signatures by Sawyer X