Re: Do slurpy parameters auto-flatten arrays?
HaloO, Piers Cawley wrote: By the way, if flattening that way, what's the prototype for zip? We can after all do: zip @ary1, @ary2, @ary3, ... @aryn How about sub zip( List [EMAIL PROTECTED] ) {...} a slurpy List of Array of List. The return value is a not yet iterated Code object that knows how to produce tuples from the outer lists. This implies that zip(@array) basically returns an unstarted iterator on @array. -- $TSa.greeting := "HaloO"; # mind the echo!
Re: Do slurpy parameters auto-flatten arrays?
HaloO, Luke Palmer wrote: On 8/3/05, Aankhen <[EMAIL PROTECTED]> wrote: On 8/3/05, Piers Cawley <[EMAIL PROTECTED]> wrote: So how *do* I pass an unflattened array to a function with a slurpy parameter? Good question. I would have thought that one of the major gains from turning arrays and hashes into references in scalar context is the ability to specify an unflattened array or a hash in a sub call without any special syntax... I thought that the obsoletion of special syntax stems from the type system. Piers seems to have the same view. See his example of &map in his parallel reply. Well, you can, usually. This is particularly in the flattening context. In most cases, for instance: sub foo ($a, $b) { say $a } my @a = (1,2,3); foo(@a, "3"); Passes the array into $a. If nothing flattened by default, then you'd have to say, for example: map {...} [EMAIL PROTECTED]; And even: for [EMAIL PROTECTED] -> $x {...} Which I'm not sure people want. Ups, I thought the for special form would work as follows. 0. the syntax: for expression &block 1. determine (return) type of expression 2. create an iterator for that type 3. Use the iterator until it runs out (is that when it returns undef?) 4. bind the block owner to successive return values of the iterator and call the block; if the block is pointy bind its environment as well. With the above for @a -> $x {...} # use Iterator of Array and for [EMAIL PROTECTED] -> $x {...} # use Iterator of List produc the same sequence of values in $x but through different paths in type space. As long as no user defined types are involved, I dought they are distinguishable at all. Here's an idea how a sub becomes its own iterator: sub foo() does Iterator[foo] { random; } for foo() -> $x { say } # endless loop of random output How are roles/types composed into Code subtypes? And the way you pass an array in slurpy context as a single reference is to backwhack it. What it comes down to is that either you're backwhacking things a lot or you're flattening things a lot. Perl currently solves it by making the common case the default in each "zone" of parameters. I would be interested to hear arguments to the contrary, however. OK, I gave my 0.02. -- $TSa.greeting := "HaloO"; # mind the echo!
Re: Do slurpy parameters auto-flatten arrays?
Luke Palmer <[EMAIL PROTECTED]> writes: > On 8/3/05, Aankhen <[EMAIL PROTECTED]> wrote: >> On 8/3/05, Piers Cawley <[EMAIL PROTECTED]> wrote: >> > So how *do* I pass an unflattened array to a function with a slurpy >> > parameter? >> >> Good question. I would have thought that one of the major gains from >> turning arrays and hashes into references in scalar context is the >> ability to specify an unflattened array or a hash in a sub call >> without any special syntax... > > Well, you can, usually. This is particularly in the flattening > context. In most cases, for instance: > > sub foo ($a, $b) { say $a } > my @a = (1,2,3); > foo(@a, "3"); > > Passes the array into $a. If nothing flattened by default, then you'd > have to say, for example: > > map {...} [EMAIL PROTECTED]; > I would assume that the way to implement map is: multi sub map(&block, @array) { map &block, [EMAIL PROTECTED] } multi sub map(&block, [EMAIL PROTECTED]) { ... } If I call map like: map {...} @a, @b, @c; then I would expect the block to be called three times with @a, @b and @c as the respective arguments. I think the problem I have with this is that unless I missed something, the default prototype for a block is [EMAIL PROTECTED] If slurpiness works as described, then $func = { [EMAIL PROTECTED] } $func.(@array) doesn't return the length of the array, but the numification of its first element. It seems to me that a slurpy parameter spec should simply say "Grab the rest of the arguments and stick 'em in this array/hash", a function's caller should control the flattening of a particular array argument, not the thing it calls. One of us has obviously misread the appropriate Apocalypse/Synopsis/Exegesis. I have the horrible feeling that it's probably me, but I do think that the interpretation I propose is the least surprising and most useful. By the way, if flattening that way, what's the prototype for zip? We can after all do: zip @ary1, @ary2, @ary3, ... @aryn
Re: Do slurpy parameters auto-flatten arrays?
[EMAIL PROTECTED] wrote: So how *do* I pass an unflattened array to a function with a slurpy parameter? I don't ~~ @larry, but my guess(es) would be bar([EMAIL PROTECTED]) or bar([EMAIL PROTECTED]) Miro
Re: Do slurpy parameters auto-flatten arrays?
On 8/3/05, Aankhen <[EMAIL PROTECTED]> wrote: > On 8/3/05, Piers Cawley <[EMAIL PROTECTED]> wrote: > > So how *do* I pass an unflattened array to a function with a slurpy > > parameter? > > Good question. I would have thought that one of the major gains from > turning arrays and hashes into references in scalar context is the > ability to specify an unflattened array or a hash in a sub call > without any special syntax... Well, you can, usually. This is particularly in the flattening context. In most cases, for instance: sub foo ($a, $b) { say $a } my @a = (1,2,3); foo(@a, "3"); Passes the array into $a. If nothing flattened by default, then you'd have to say, for example: map {...} [EMAIL PROTECTED]; And even: for [EMAIL PROTECTED] -> $x {...} Which I'm not sure people want. And the way you pass an array in slurpy context as a single reference is to backwhack it. What it comes down to is that either you're backwhacking things a lot or you're flattening things a lot. Perl currently solves it by making the common case the default in each "zone" of parameters. I would be interested to hear arguments to the contrary, however. Luke
Re: Do slurpy parameters auto-flatten arrays?
On 8/3/05, Piers Cawley <[EMAIL PROTECTED]> wrote: > So how *do* I pass an unflattened array to a function with a slurpy parameter? Good question. I would have thought that one of the major gains from turning arrays and hashes into references in scalar context is the ability to specify an unflattened array or a hash in a sub call without any special syntax... Aankhen
Re: Do slurpy parameters auto-flatten arrays?
Luke Palmer <[EMAIL PROTECTED]> writes: > On 7/26/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote: >> Hi, >> >> are the following assumptions correct? >> >> sub foo ([EMAIL PROTECTED]) { @args[0] } >> >> say ~foo("a", "b", "c"); # "a" > > Yep. > >> my @array = ; >> say ~foo(@array);# "a b c d" (or "a"?) >> say ~foo(@array, "z"); # "a b c d" (or "a"?) > > "a" for both of these. The *@ area behaves just like Perl 5's calling > conventions. I could argue for never auto flattening arrays, but then > there'd really be no difference between @ and $. > >> say ~foo([EMAIL PROTECTED]); # "a" >> say ~foo(*(@array, "z"));# "a" > > Hmm, *(@array, "z")... what does that mean? Whatever it means, you're > correct in both of these. In the latter, the @array is in a > flattening context, so it gets, well, flattened. > >> sub bar ([EMAIL PROTECTED]) { [EMAIL PROTECTED] } >> >> say bar(1,2,3); # 3 >> say bar(@array); # 1 (or 4?) > > 4 Wha? And I mean that sincerely. That's cockeyed. Surely a [EMAIL PROTECTED] in the signature simply says 'gather up the rest of the args and stick 'em in this list'. In this case @array is a single argument, so @args should be equal to [EMAIL PROTECTED] If I'm calling the function and I want @array to be treated as anything but a single argument I use [EMAIL PROTECTED] >> say bar(@array, "z");# 2 (or 5?) > > 5 Double wha? That's even worse. Do you claim that say bar('z', @array) also emits 5? Ick. >> say bar([EMAIL PROTECTED]);# 4 > > Yep. So how *do* I pass an unflattened array to a function with a slurpy parameter?
Re: Do slurpy parameters auto-flatten arrays?
On 7/26/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote: > Hi, > > are the following assumptions correct? > > sub foo ([EMAIL PROTECTED]) { @args[0] } > > say ~foo("a", "b", "c"); # "a" Yep. > my @array = ; > say ~foo(@array);# "a b c d" (or "a"?) > say ~foo(@array, "z"); # "a b c d" (or "a"?) "a" for both of these. The *@ area behaves just like Perl 5's calling conventions. I could argue for never auto flattening arrays, but then there'd really be no difference between @ and $. > say ~foo([EMAIL PROTECTED]); # "a" > say ~foo(*(@array, "z"));# "a" Hmm, *(@array, "z")... what does that mean? Whatever it means, you're correct in both of these. In the latter, the @array is in a flattening context, so it gets, well, flattened. > sub bar ([EMAIL PROTECTED]) { [EMAIL PROTECTED] } > > say bar(1,2,3); # 3 > say bar(@array); # 1 (or 4?) 4 > say bar(@array, "z");# 2 (or 5?) 5 > say bar([EMAIL PROTECTED]);# 4 Yep. Luke
Re: Do slurpy parameters auto-flatten arrays?
Ingo Blechschmidt wrote: Hi, ReHi, are the following assumptions correct? I don't know in general. But see my assumptions below for comparison. They are derived from my type theoretic approach and as such might collide with Perl6's referential semantics. In particular with the auto-ref/deref and how far it follows links. sub foo ([EMAIL PROTECTED]) { @args[0] } say ~foo("a", "b", "c"); # "a" foo( List of Str ) my @array = ; say ~foo(@array);# "a b c d" (or "a"?) foo( Ref of Array ) # @args[0] derefs the array ref # I guess you need @args[0][0] to get "a" But I don't like this level of reference preservation. E.g. one then needs to know how far out the flat array resides, to use the right number of dereferencers. Here type theory doesn't constrain the definitional freedom because both interpretations are compatible with [EMAIL PROTECTED] Actually that unspecificity could be preserved, see below. say ~foo(@array, "z"); # "a b c d" (or "a"?) foo( Ref of Array, Str ) # @args[0] as above Here typing constrains the interpretation to be the one that needs @args[0][0] to get at "a". This is slightly untrue. The problem is actually shifted to the question: "How does comma handle a Ref of Array?". say ~foo([EMAIL PROTECTED]); # "a" foo( List of Str build from Array of Str) say ~foo(*(@array, "z"));# "a" sub bar ([EMAIL PROTECTED]) { [EMAIL PROTECTED] } say bar(1,2,3); # 3 say bar(@array); # 1 (or 4?) Type theory actually should come up with any(1|4) :) And yes, any(1|4) is a type literal and any($x,$y) is a parametric type which is fixed whenever $x and $y are. Side node: A nice test for hidden assumptions in code is to replace functions which return Any to behave randomly. A Vogon optimizer OTOH, might blow away a complete planet and return 42 everywhere :) For this very reason the default signature of the ideal sub is of course ::Any --> ::All where All is pure specificity. And---even thow I should start a 'type theory foundations of Perl6' thread, I mention it here---the ideal method is ::All . ::Any --> ::All A multi sub/method is in that view a *metric* dispatcher on the middle ::Any between the selector before the dot and the return type after the arrow. say bar(@array, "z");# 2 (or 5?) I opt for 2. say bar([EMAIL PROTECTED]);# 4 Yep. -- TSa (Thomas Sandlaß)
Do slurpy parameters auto-flatten arrays?
Hi, are the following assumptions correct? sub foo ([EMAIL PROTECTED]) { @args[0] } say ~foo("a", "b", "c"); # "a" my @array = ; say ~foo(@array);# "a b c d" (or "a"?) say ~foo(@array, "z"); # "a b c d" (or "a"?) say ~foo([EMAIL PROTECTED]); # "a" say ~foo(*(@array, "z"));# "a" sub bar ([EMAIL PROTECTED]) { [EMAIL PROTECTED] } say bar(1,2,3); # 3 say bar(@array); # 1 (or 4?) say bar(@array, "z");# 2 (or 5?) say bar([EMAIL PROTECTED]);# 4 --Ingo -- Linux, the choice of a GNU | There are no answers, only generation on a dual AMD | cross-references. Athlon!|