Re: slurpy scalar parameter?
On Sat, Apr 12, 2008 at 05:06:53AM -, John M. Dlugosz wrote: What is the difference between: sub head(*$head, [EMAIL PROTECTED]) and sub head($head?, [EMAIL PROTECTED]) If you call head(@foo), in the first $head gets @foo[0] and in the second it gets nothing (you didn't pass a scalar). -ryan
Re: cross operator and empty list
[EMAIL PROTECTED] wrote: Technically the Cartesian cross operator doesn't have an identity value. It has. The set which contains only the emty set, or in perl terms ([]); Or am I missing something? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: slurpy scalar parameter?
On Sat, Apr 12, 2008 at 02:10:48AM -0400, Ryan Richter wrote: : On Sat, Apr 12, 2008 at 05:06:53AM -, John M. Dlugosz wrote: : What is the difference between: : : sub head(*$head, [EMAIL PROTECTED]) : : and : : sub head($head?, [EMAIL PROTECTED]) : : : If you call head(@foo), in the first $head gets @foo[0] and in the : second it gets nothing (you didn't pass a scalar). Nope, second one gets @foo as a scalar, and nothing in the list. Larry
Re: quick ones on subs
On Sat, Apr 12, 2008 at 04:58:57AM -, John M. Dlugosz wrote: : In S06, a wrong word: : : Alternately, optional fields may be marked by supplying a default value. : should be parameters, not fields. : : Now here is my question: : Params are bound in declaration order, not call order, and may refer to previous parameters. But what if a multi makes use of your intentional mechanism of having value constraints, namely the use of named subtypes. You don't know if the parameter is suitable for the subtype until its value is known. And the multis have their named parameters in opposite orders, or similar names with different contexts. It's not supposed to process the argument list until after it decides with function to call. But you also want a mechanism to distinguish alternatives based on values. What gives? What gives (in the sense of breaking) is the notion that you can do multiple dispatch on randomly ordered arguments. That's the main reason we invented proto multis, so that the compiler can rearrange supposedly randomly ordered arguments into positional slots so that you can to multiple dispatch on them. Other than that, we make no promises about supporting multiple dispatch on named args other than by excluding candidates that can't bind at all. Larry
Re: What is the self pragma?
On Sat, Apr 12, 2008 at 04:49:39AM -, John M. Dlugosz wrote: : In S06, A method's invocant always has the alias self. Other styles of self can be declared with the self pragma. : : What is the self pragma, and what are other styles of self, prey tell? Seemingly a placeholder for future generations to decide. In reality, a sop for all the losers in the long, drawn out what-do-we-call-the-invocant battle. :) It's probably just a wrapper for a term:this kind of macro in any case. And not terribly important. It's just we have a vague policy that when some pragma is changing a built-in keyword, we usually name it the same as the keyword, and we're claiming that a self pragma is the right name for modifying self. Or something like that. Now that people have gotten used to self.foo and $.foo, it may be that the demand for the pragma has fallen off a bit... :) Larry
Re: Symbolic references and OUTER
On Fri, Apr 11, 2008 at 05:08:58PM -0400, Bob Rogers wrote: : I don't see that this is any harder; unless I'm misunderstanding you, : this is just another normal closure usage case. The OUTER scope is : always the one defined by outersub, no matter how many calls back in the : dynamic chain it might be. Yes, OUTER is necessarily always a particular lexical scope known at compile time. Which is why we have CALLER for the other case. :) Larry
Re: What is the self pragma?
Larry Wall skribis 2008-04-12 9:26 (-0700): Now that people have gotten used to self.foo and $.foo, it may be that the demand for the pragma has fallen off a bit... :) I hope it has. Perl 6 would be less confusing without this pragma. -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: What is the self pragma?
On Sat, Apr 12, 2008 at 2:18 PM, Juerd Waalboer [EMAIL PROTECTED] wrote: Larry Wall skribis 2008-04-12 9:26 (-0700): Now that people have gotten used to self.foo and $.foo, it may be that the demand for the pragma has fallen off a bit... :) I hope it has. Perl 6 would be less confusing without this pragma. Agreed. Being able to change the invocant name strikes me as one of those things that sounds like a good idea at first but might not be -like $[. Although of course much better since pragmas are lexically scoped. -- Mark J. Reed [EMAIL PROTECTED]
Question (mistake?) in S06 Multidimensional argument list binding
The section contrasts
sub foo (*@@slice) { ... }
sub foo (\$slice) { ... }
but he latter is never explained anywhere. Did you mean to use | instead of \
in that section?
If not, what am I missing?
Re: quick ones on subs
Larry Wall larry-at-wall.org |Perl 6| wrote: What gives (in the sense of breaking) is the notion that you can do multiple dispatch on randomly ordered arguments. That's the main reason we invented proto multis, so that the compiler can rearrange supposedly randomly ordered arguments into positional slots so that you can to multiple dispatch on them. Other than that, we make no promises about supporting multiple dispatch on named args other than by excluding candidates that can't bind at all. Larry OK, I got it. Now what about excluding? Will it execute the code in the constraint check for a subtype to see if it _might_ bind?
Clarify Design by Contract
PRE/POST on methods: When applied to a method, the semantics provide support for the Design by Contract style of OO programming: a precondition of a particular method is met if all the PRE blocks associated with that method return true. Otherwise, the precondition is met if all of the parent classes' preconditions are met (which may include the preconditions of their parent classes if they fail, and so on recursively.) In contrast, a method's postcondition is met if all the method's POST blocks return true and all its parents' postconditions are also met recursively. If the PRE blocks on the method don't all return true, it appeals to the preconditions on the base class of the class defining the method? I don't get it. Why would a class-level precondition override a method-level precondition? Why bother defining them on the method, if they are ignored if they are false anyway? --John
Q on function returning
In S06, it is explained how the parameter list to 'return' is preserved as a Capture. So, what is the role of the inner and outer return types that are declared on the function?
'returns' vs 'of'
I don't like the assignments of 'returns' and 'of'. I think it is easily confused. I've written foo (Int $x) returns Int in examples and nobody noticed. As formal documentation, that scans right as the outer perceived return value type. But no, it's supposed to be foo (Int $x) of Int instead. The returns keyword affects the implementation of the function, not the external contract. Yet, if returns is missing it uses the of value by default, but if the of is missing it does not give static type checking to the caller, rather than using the same as the returns. Will other programmers make the same mistake? I think it's going to be a problem. It's like thinking you used strict but did not, and the compiler wasn't telling you things it should have. --John
