Re: Do slurpy parameters auto-flatten arrays?

2005-08-04 Thread TSa (Thomas Sandlaß)

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?

2005-08-04 Thread TSa (Thomas Sandlaß)

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?

2005-08-03 Thread Piers Cawley
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 = a b c d;
   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?

2005-08-03 Thread Miroslav Silovic

[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?

2005-07-27 Thread TSa (Thomas Sandlaß)

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 = a b c d;
  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ß)




Re: Do slurpy parameters auto-flatten arrays?

2005-07-27 Thread Luke Palmer
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 = a b c d;
   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