Re^3: Reflections on “Higher Order Perl” §1.1

in reply to Re^2: Reflections on “Higher Order Perl” §1.1
in thread Reflections on “Higher Order Perl” §1.1

Note that multi a(0|1) { ... } is not the same as multi a(0|1 $n) { ... }. The former is explicitly allowed as a short cut for an anyonymous parameter, ie its longer form would be Int $ where 0|1. The latter is currently not parsed by STD.pm, and I don't see which part of the specs would allow that - any pointers to a piece of spec?

Comment on Re^3: Reflections on “Higher Order Perl” §1.1 Select or Download Code

Replies are listed 'Best First'.
Re^4: Reflections on “Higher Order Perl” §1.1 by John M. Dlugosz (Monsignor) on Jun 10, 2009 at 17:35 UTC
A literal (including integer) is a subset type. That means they should be able to appear in junction types. Either Larry was being overentheusiastic when he said that literals (including ints) and named values (constants and enumerations) "are" subset types, and the parser ran into trouble actually doing that in full generality, or the STD.pm is just not caught up to his latest vision. —John	[reply]
Re^5: Reflections on “Higher Order Perl” §1.1 by TimToady (Parson) on Jun 10, 2009 at 19:54 UTC
That's the theory, but for practical reasons (not giving Jonathan a thundering apoplexy, for instance), parameters are currently restricted to a single constraint in front, and will continue to be restricted until we get more experience with the sorting of multiple dispatch candidates using multiple constraints. See the note in S12, "Multiple constraints".	[reply]
Re^6: Reflections on “Higher Order Perl” §1.1 by John M. Dlugosz (Monsignor) on Jun 15, 2009 at 14:29 UTC
So chalk it up as "implementation limitation", and beware of any rules concerning multiple constraints as they are subject to change. "Single constraint" means not combining junctions and subsets? —John	[reply]

In Section Meditations