Re: relationship between slurpy parameters and named args?
HaloO, Austin Frank wrote: It seems to me like these are related contexts-- arguments to a sub are supposed to fulfill its parameter list. This makes the overloading of prefix:* confusing to me. Would an explicit type List help? I'm pretty sure we don't need slurpiness in argument lists, and I don't know if the prefix:* notation for named arguments would be useful in parameter lists. But just because I can reason that, for example, prefix:* in an argument list can't mean slurpiness, that doesn't make it clear to me what prefix:* _does_ mean in that context. Slurpiness in a parameter list is a property of a *zone* not of a single parameter, IIRC. In a parameter list * actually is no operator but a syntactic type markup! As arity indicator it could actually be given after the param like the !, ? and = forms. If the slurpy zone has more type constraints then just 'give me all' these have to be met by the dynamic args. The very rudimentary split in the types is on behalf of named versus positional reflected in the @ versus % sigils. Using prefix:* at the call site just defers the matching to dispatch time unless the type inferencer knows that there is no chance of meeting the requirements! And parens are needed to itemize pairs syntactically. Note that the invocant zone does neither support slurpyness with * nor optionality with ?. And I'm not sure how explicit types like List or Pipe behave with respect to dispatch. I think I understand that prefix:* is available outside of parameter lists because that's the only place we need it to mean slurpiness. No, I think outside of parameter declarations prefix:* indicates lazy evaluation which I see as a snapshoting of the part of the state that is relevant for producing the actual values later in the program. But this might contradict the synopsis which talk of 'when a value becomes known' which sounds like a ASAP bound ref whose value at deref time depends on side-effects between the lazification and deref! So, is there a conceptual connection between imposing named argument interpretation on pairs in an arg list and slurping up the end of a parameter list? Are there other meanings of prefix:* that relate to one or the other of these two meanings? I see the following type correspondences: *$ Item of List # accessible through the $ variable *@ List of Item # accessible through the @ variable *% List of Pair # accessible through the % variable and perhaps * Item of Code # accessible through the variable but this last one is not slurping up more than one block. Hmm, I'm also unsure if a single *$ param suffices to bind a complete list of args into an Item of Ref of List. OTOH, it is clearly stated that *$ after a *@ or *% never receive values. --
Re: relationship between slurpy parameters and named args?
Stuart Cook [EMAIL PROTECTED] writes: On 29/12/05, Austin Frank [EMAIL PROTECTED] wrote: So, is there a conceptual connection between imposing named argument interpretation on pairs in an arg list and slurping up the end of a parameter list? Are there other meanings of prefix:* that relate to one or the other of these two meanings? The missing link is that prefix:* in an argument list also causes things like arrays to be treated as a sequence of separate parameters, rather than as a single array parameter. See Flattening argument lists in S06. (This was the original meaning of prefix:* in arglists; the named-pair behaviour was added later, when pair values ceased to have named behaviour automatically.) Personally, I think that prefix * in an arglist should only flatten array arguments if there is only one array. And if it doesn't, how do I declare parameter that is 'a slurpy list of arrays' or 'the rest of the arguments, without flattening'. If I *really* want aggressive flattening then I can call, say, @slurpy_param.flatten -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/
Re: relationship between slurpy parameters and named args?
On 12/30/05, Piers Cawley [EMAIL PROTECTED] wrote: Stuart Cook [EMAIL PROTECTED] writes: On 29/12/05, Austin Frank [EMAIL PROTECTED] wrote: So, is there a conceptual connection between imposing named argument interpretation on pairs in an arg list and slurping up the end of a parameter list? Are there other meanings of prefix:* that relate to one or the other of these two meanings? The missing link is that prefix:* in an argument list also causes things like arrays to be treated as a sequence of separate parameters, rather than as a single array parameter. See Flattening argument lists in S06. (This was the original meaning of prefix:* in arglists; the named-pair behaviour was added later, when pair values ceased to have named behaviour automatically.) Personally, I think that prefix * in an arglist should only flatten array arguments if there is only one array. And if it doesn't, how do I declare parameter that is 'a slurpy list of arrays' or 'the rest of the arguments, without flattening'. If I *really* want aggressive flattening then I can call, say, @slurpy_param.flatten Does this imply that [EMAIL PROTECTED] === @slurpy.flatten ? Or, put another way, can't we just say that prefixed * is symbolic notation for flatten() in the same way that postfixed [] is symbolic notation for slice()? Rob
relationship between slurpy parameters and named args?
Hello all! In reading S06 from the svn repository I had some questions about the use of prefix:* in different contexts. When used in an argument list, it forces pairs to be interpreted as named args. When used in a parameter list, it causes slurpiness. It seems to me like these are related contexts-- arguments to a sub are supposed to fulfill its parameter list. This makes the overloading of prefix:* confusing to me. I'm pretty sure we don't need slurpiness in argument lists, and I don't know if the prefix:* notation for named arguments would be useful in parameter lists. But just because I can reason that, for example, prefix:* in an argument list can't mean slurpiness, that doesn't make it clear to me what prefix:* _does_ mean in that context. I think I understand that prefix:* is available outside of parameter lists because that's the only place we need it to mean slurpiness. This particular overloading, however, seems like one that I'm likely to forget or mess up because I don't see the connection between the two different meanings. So, is there a conceptual connection between imposing named argument interpretation on pairs in an arg list and slurping up the end of a parameter list? Are there other meanings of prefix:* that relate to one or the other of these two meanings? Any explanations are appreciated! Thanks, /au
Re: relationship between slurpy parameters and named args?
On 29/12/05, Austin Frank [EMAIL PROTECTED] wrote: So, is there a conceptual connection between imposing named argument interpretation on pairs in an arg list and slurping up the end of a parameter list? Are there other meanings of prefix:* that relate to one or the other of these two meanings? The missing link is that prefix:* in an argument list also causes things like arrays to be treated as a sequence of separate parameters, rather than as a single array parameter. See Flattening argument lists in S06. (This was the original meaning of prefix:* in arglists; the named-pair behaviour was added later, when pair values ceased to have named behaviour automatically.) Stuart
