http://qs321.pair.com?node_id=770390


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

A literal or an enumeration or constant is now allowed as a subset type of one. That is indeed fairly new. File a bug. That's one reason why the enumerations (e.g. True and False) got changed to capitalized, as they are grammatically types. That's straight from the camel's mouth: "basically any value can be used as a single-valued type in a signature ... and write the usual factorial with multi factorial (0) { 1 } etc"

So it was in there a month ago, at least. He shows the declarator form of constant in that discussion, so it might have been in his head before it was checked in to STD.pm.

Perhaps we could have a node here that runs P6 syntax through rakudo or the current STD.pm treebuilder app.

—John

Replies are listed 'Best First'.
Re^3: Reflections on “Higher Order Perl” §1.1
by moritz (Cardinal) on Jun 10, 2009 at 17:20 UTC
    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?
      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

        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".