Revision 27313

Date:
2009/06/30 01:58:33
Author:
lwall
Revision Log:
[S03] make constant have "our" scoping
[S12] attempt to spec irc conversation with jnthn++
Files:

Legend:

 
Added
 
Removed
 
Modified

  • docs/Perl6/Spec/S03-operators.pod

     
    4061 4061 our $foo # lexically scoped alias to package variable
    4062 4062 has $foo # object attribute
    4063 4063 state $foo # persistent lexical (cloned with closures)
    4064 constant $foo # lexically scoped compile-time constant
    4064 constant $foo # "our" scoped compile-time constant
    4065 4065
    4066 4066 Variable declarators such as C<my> now take a I<signature> as their
    4067 4067 argument. (The syntax of function signatures is described more fully in S06.)

  • docs/Perl6/Spec/S12-objects.pod

     
    12 12
    13 13 Created: 27 Oct 2004
    14 14
    15 Last Modified: 10 Jun 2009
    16 Version: 85
    15 Last Modified: 29 Jun 2009
    16 Version: 86
    17 17
    18 18 =head1 Overview
    19 19
    … …  
    965 965 of the arguments match up with the declared types of the parameters of
    966 966 each candidate. The best candidate is called, unless there's a tie,
    967 967 in which case the tied candidates are redispatched using any additional
    968 tiebreaker long names (see below).
    968 tiebreaker strategies (see below). For the purpose of this nominal typing,
    969 no constrained type is considered to be a type name; instead the constrained type
    970 is unwound into its base type plus constraint. Only the base type upon
    971 which the constrained type is based is considered for the nominal type
    972 match (along with the fact that it is constrained). That is, if you have a parameter:
    969 973
    970 If a tie still results, only candidates marked with the C<default> trait are
    971 considered, and the best matching default routine is used. If there
    972 are no default routines, or if the available defaults are also tied,
    973 a final tie-breaking proto sub is called, if there is one (see above).
    974 Otherwise the dispatch fails.
    974 subset Odd of Int where { $_ % 2 }
    975 multi foo (Odd $i) {...}
    975 976
    977 it is treated as if you'd instead said:
    978
    979 multi foo (Int $i where { $_ % 2 }) {...}
    980
    981 Any constrained type is considered to have a base type that is "epsilon" narrower than
    982 the corresponding unconstrained type. The compile-time topological sort
    983 takes into account the presence of at least one constraint, but nothing about the
    984 number or nature of any additional constraints. If we think of Int' as
    985 any constrained version of Int, then Int' is always tighter nominally than Int.
    986 (Int' is a meta-notation, not Perl 6 syntax.)
    987
    976 988 The order in which candidates are considered is defined by a
    977 989 topological sort based on the "type narrowness" of each candidate's
    978 990 long name, where that in turn depends on the narrowness of each
    … …  
    980 992 Parameters whose types are not comparable are also considered tied.
    981 993 A candidate is considered narrower than another candidate if at least
    982 994 one of its parameters is narrower and all the rest of its parameters
    983 are either narrower or tied. This defines the partial ordering of
    984 all the candidates. If the topological sort detects a circularity in
    985 the partial ordering, all candidates in the circle are considered tied.
    986 A warning will be issued at C<CHECK> time if this is detected and there is
    987 no default candidate to fall back to.
    995 are either narrower or tied. Also, if the signature has any additional
    996 required parameters not participating in the long name, the signature
    997 as a whole is considered epsilon tighter than any signature without
    998 extra parameters. In essence, the remaining arguments are added to
    999 the longname as if the user had declared a capture parameter to bind
    1000 the rest of the arguments, and that capture parameter has a constraint
    1001 that it must bind successfully to the additional required parameters.
    1002 All such signatures within a given rank are considered equivalent,
    1003 and subject to tiebreaker A below.
    988 1004
    1005 This defines the partial ordering of all the candidates. If the
    1006 topological sort detects a circularity in the partial ordering,
    1007 all candidates in the circle are considered tied. A warning will be
    1008 issued at C<CHECK> time if this is detected and there is no suitable
    1009 tiebreaker that could break the tie.
    1010
    1011 There are three tiebreaking modes, in increasing order of desperation:
    1012
    1013 A) run-time constraint processing
    1014 B) use of a candidate marked with "is default"
    1015 C) use of a candidate marked as "proto"
    1016
    1017 In the absence of any constraints, ties in the nominal typing
    1018 immediately failover to tiebreaker B or C; if not resolved by B or C,
    1019 they warn at compile time about an ambiguous dispatch.
    1020
    1021 If there are any tied candidates with constraints, it follows from our
    1022 definitions above that all of them are considered to be constrained.
    1023 In the presence of longname parameters with constraints, or the
    1024 implied constraint of extra required arguments, tiebreaker A is
    1025 applied. Candidates which are tied nominally but have constraints
    1026 are considered to be a completely different situation, insofar as it
    1027 is assumed the user knows exactly why each candidate has the extra
    1028 constraints it has. Thus, constrained signatures are considered to
    1029 be much more like a switch defined by the user. So for tiebreaker
    1030 A the candidates are simply called in the order they were declared,
    1031 and the first one that successfully binds (and completes without
    1032 calling nextsame or nextwith) is considered the winner, and all the
    1033 other tied candidates are ignored. If all the constrained
    1034 candidates fail, we throw out the rank of constrained variants and
    1035 proceed to the next tighter rank, which may consist of the
    1036 unconstrained variants without extra arguments.
    1037
    1038 For ranks that are not decided by constraint (tiebreaker A),
    1039 tiebreaker B is used: only candidates marked with the C<default>
    1040 trait are considered, and the best matching default routine is used.
    1041 If there are no default routines, or if the available defaults are
    1042 also tied, tiebreaker C is used: a final tie-breaking proto sub is
    1043 called, if there is one (see above). Otherwise the dispatch fails.
    1044
    989 1045 Ordinarily all the parameters of a multi sub are considered for dispatch.
    990 1046 Here's a declaration for an integer range operator with two parameters
    991 1047 in its long name:
    … …  
    1005 1061 Note that a call to the routine must still be compatible with
    1006 1062 subsequent arguments.
    1007 1063
    1064 Note that the C<$by> is not a required parameter, so doesn't impose
    1065 the kind of constraint that allows tiebreaker A. If the default
    1066 were omitted, it would be a required parameter, and subject to tiebreaker A.
    1067 Likewise an ordinary named parameter does not participate as a tiebreaker,
    1068 but you can mark named parameters as required to effectively make
    1069 a switch based on named binding:
    1070
    1071 multi foo (Int $a;; :$x!) {...} # constrained
    1072 multi foo (Int $a;; :$y!) {...} # constrained
    1073 multi foo (Int $a;; :$z!) {...} # constrained
    1074
    1075 multi foo (Int $a;; *%_) {...} # unconstrained
    1076
    1077 The first three are dispatched under tiebreaker A as a constrained
    1078 rank. If none of them can match, the final one is dispatched as
    1079 an unconstrained rank, since C<*%_> is not considered a required
    1080 parameter.
    1081
    1082 Likewise, constrained types sort before unconstrained:
    1083
    1084 multi bar (Even $a) {...} # constrained
    1085 multi bar (Odd $a) {...} # constrained
    1086
    1087 multi bar (Int $a) {...} # unconstrained
    1088
    1089 And values used as subset types also sort first, and are dispatched
    1090 on a first-to-match basis:
    1091
    1092 multi baz (0) {...} # constrained
    1093 multi baz (1) {...} # constrained
    1094
    1095 multi baz (Int $x) {...} # unconstrained
    1096
    1097 If some of the constrained candidates come by import from other modules,
    1098 they are all considered to be declared at the point of of importation
    1099 for purposes of tiebreaking; subsequent tiebreaking is provided by
    1100 the original order in the used module.
    1101
    1008 1102 [Conjecture: However, a given multi may advertise multiple long names,
    1009 1103 some of which are shorter than the complete long name. This is done
    1010 1104 by putting a semicolon after each advertised long name (replacing