Re: zip with ()

2005-08-04 Thread Larry Wall
On Mon, Aug 01, 2005 at 01:13:52PM +0200, "TSa (Thomas Sandlaß)" wrote:
: BTW, you didn't mean originally:
: 
:   say zip (@odd), (@even); # prints 13572468 or 12345678?

That doesn't work, since () in list context does not enforce scalar context.
It's exactly equivalent to

say zip @odd, @even;

which is also wrong, because zip is requires "multidimentional slice"
syntax.  Ordinary commas will be taken to separate items of the first
slice.  To separate slices requires semicolon or pipes.

: Does &zip now interleave two array refs instead
: of flattened arrays?

No, but separating the arrays with comma doesn't work either, so Pugs
currently has it wrong.  The correct syntax will eventually be:

zip(@odd; @even)
zip @odd <== @even

The parens are required only at the top statement level.  Inside other
bracketing structures you can omit the parens:

(zip @odd; @even)

just as in subscripts the semicolon separates multiple dimensions:

@[EMAIL PROTECTED]; @b]

Larry


Re: zip with ()

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

HaloO,

Luke Palmer wrote:

On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:


In general, (@foo, @bar) returns a new list with the element joined,
i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED], 
[EMAIL PROTECTED]). But of course, I could
be totally wrong. :)



I think that's right.  However, it might be a good idea not to
auto-enreference such bare lists:


I don't like this notion of auto enreference/dereference at all.
Either the type system manages to dispatch things correctly or
you get an error. For the List versus Array problem this dispatch
is IMHO decideable at compile time by strictly typing @ vars as
Array and subtypes thereof. The List type to me is a Code subtype
and as such travels in & vars. I'm only unsure how easily such
variables should enter name space, that is how they behave without
sigil.


sub foo ($x) {...}
foo (1,2,3,4,5);   # foo gets called with [1,2,3,4,5]


Yes, the $x makes foo an Item or even Value taker of arity 1.
The call foo (1,2,3,4,5) OTOH calls it with a List. This should
result in a type error. But sub foo (&x) might then work for a List
but not for an Item|Value call foo(1).

Since I think that * in a signature is for extending the arity of
the sub to infinity I wonder if it is possible to capture the caller's
list into a single *$arg?

   sub foo (*$x) {...}
   foo (1,2,3,4,5); # type of $x is now Ref of List of Int?

But with an additional array the slurpy item gets at most one value.

   sub foo (*$x, [EMAIL PROTECTED]) {...}
   foo (1,2,3,4,5); # $x == 1; [EMAIL PROTECTED] == 4
   foo @array; # type of $x is now Ref of Array; @a is undef



When you could just as easily have said:

foo [1,2,3,4,5];

And we'll probably catch a lot of Perl 5 switchers that way.  That
actually makes a lot of sense to me.  The statement:

my $x = (1,2,3,4,5);

Looks like an error more than anything else.


Yep. I opt for type error "Can't assign List to Item".
By the same token I would disallow

  my @a = 3; # type error "Can't assign Item to Array".

It should be

  my @a = *3;

or

  my @a = (3,);

Hmm, wasn't there a nullary *?

  my @a = *;
  say [EMAIL PROTECTED];  # prints 0



 That's the "scalar
comma", which has been specified to return a list.  But maybe it
should be an error.


Sorry, I don't understand this.  I thought comma just is *the*
List constructor per se. Parens required to lift precedence :)
Same applies to semi-colon. (1,2,3;4,5,6) is a List of List of Int.



 The main reason that we've kept a scalar comma is
for:

loop (my $x = 0, my $y = 0; $x*$y <= 16; $x++, $y++)
{...}

However, I think we can afford to hack around that.  Make the first
and last arguments to loop take lists and just throw them away.


My interpretation of the loop block controler special form is that
it gets a 4-tupel (Block,Block,Block,Block). The last one is of course
the loop's body. The first is the initializer that is executed in a
scope outside the body. The second and third are the condition and
the stepper and also scoped outside the body.

Now to the comma. It should be parsed as List of Block. In your example
the argument type of loop is (List of Block,Block,List of Block,Block).
The loop instanciates an Iterator[List of Block] and uses it to
execute the Blocks one at a time. The only special case is in the
condition which evaluates only the last Block from the List of Block
for truth and the others in Void context.

Is loop supposed to be a topicalizer? Does it bind the block owner?
Does a pointy body block make sense?

   loop (my $x = 0; $x < 10; $x++) -> {...}  # current count in $_?
   loop (my $x = 0; $x < 10; $x++){...}  # $_ unchanged from outside?

   loop (my $x = 0; $x < 10; $x++)
   {
   .blubber   # what is the invocant?
   }

Can the last Block also be separated with semi-colon? I guess not.
How about a Code var?

  loop my $x = 0; $x < 10; $x++; say $x;  # works?

  loop my $x = 0; $x < 10; $x++; &foo; # works?

  loop( my $x = 0; $x < 10; $x++; &foo ) # perhaps as function call?

  loop
 my $x = 0;
 $x < 10;
 $x++;

  say $x; # still the loop body? Or does it need { say $x }?

  loop foo; bar; blubb ->
  {
  say  # prints return value of blubb while bar returns true
   # first iteration prints return value of foo
  }


 Can
anyone think of any other common uses of the scalar comma?


Not me. It's a C relict.
--
$TSa.greeting := "HaloO"; # mind the echo!


Re[2]: zip with ()

2005-08-01 Thread Andrew Shitov
LP> my $x = (1,2,3,4,5);
LP> Looks like an error more than anything else.

'Perl 6 and Parrot Essentials' think different ;-)

--
___
Andrew, [EMAIL PROTECTED]
___



Re: zip with ()

2005-08-01 Thread Luke Palmer
On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> In general, (@foo, @bar) returns a new list with the element joined,
> i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
> you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED], 
> [EMAIL PROTECTED]). But of course, I could
> be totally wrong. :)

I think that's right.  However, it might be a good idea not to
auto-enreference such bare lists:

sub foo ($x) {...}
foo (1,2,3,4,5);   # foo gets called with [1,2,3,4,5]

When you could just as easily have said:

foo [1,2,3,4,5];

And we'll probably catch a lot of Perl 5 switchers that way.  That
actually makes a lot of sense to me.  The statement:

my $x = (1,2,3,4,5);

Looks like an error more than anything else.  That's the "scalar
comma", which has been specified to return a list.  But maybe it
should be an error.  The main reason that we've kept a scalar comma is
for:

loop (my $x = 0, my $y = 0; $x*$y <= 16; $x++, $y++)
{...}

However, I think we can afford to hack around that.  Make the first
and last arguments to loop take lists and just throw them away.  Can
anyone think of any other common uses of the scalar comma?

Luke


Re: zip with ()

2005-08-01 Thread Ingo Blechschmidt
Hi,

TSa (Thomas Sandlaß  orthogon.com> writes:
> Ingo Blechschmidt wrote:
> > say zip (@odd, @even);  # &zip gets only one argument, the flattened
> > # list ( @odd, @even), containing the
> 
> Why flattened? Shouldn't that be *(@odd, @even)?

IIUC:
say zip *(@odd, @even);
# &zip gets called with the parameters 1, 3, 5, 7, 2, 4, 6, 8.

say zip (@odd, @even);
# &zip gets called with one argument, (1, 3, 5, 7, 2, 4, 6, 8).

say zip ([EMAIL PROTECTED], [EMAIL PROTECTED]);
# &zip gets called with one argument, ([1, 3, 5, 7], [2, 4, 6, 8]).

In general, (@foo, @bar) returns a new list with the element joined,
i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED], 
[EMAIL PROTECTED]). But of course, I could
be totally wrong. :)

> > # elements (1,3,5,7,2,4,6,8). Then &zip
> 
> Why not ([1,3,5,7],[2,4,6,8]) list of two array refs?

Because you'd have to explicitly take reference to them:
say zip ([EMAIL PROTECTED], [EMAIL PROTECTED]).

(Can somebody confirm my thoughts?)


--Ingo



Re: zip with ()

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

HaloO,

Andrew Shitov wrote:

TTS> BTW, you didn't mean originally:

TTS>say zip (@odd), (@even); # prints 13572468 or 12345678?

That is exactly like with similar printing result of sub() call:

 print sqrt (16), 5; # shout print 45.


That all hinges on the type of the symbol. I guess &sqrt
is a unary prefix. Then

   print sqrt 16, 5; # should print 45 as well.

The point is, to not let &sqrt 'swallow' the 5 unless
it is declared listop.
--
$TSa.greeting := "HaloO"; # mind the echo!


Re: zip with ()

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

HaloO,

Ingo Blechschmidt wrote:

Whitespace is significant:

say zip @odd, @even;# &zip gets two arguments, result is
# 12345678.
say zip(@odd, @even);   # &zip gets two arguments, result is
# 12345678.
say zip (@odd, @even);  # &zip gets only one argument, the flattened
# list (@odd, @even), containing the


Why flattened? Shouldn't that be *(@odd, @even)?



# elements (1,3,5,7,2,4,6,8). Then &zip


Why not ([1,3,5,7],[2,4,6,8]) list of two array refs?

# tries to zip this one list, resulting in 
# 13572468.


If the list of two array refs is not flattened, the result should be
12345678 because how should &zip distinguish it from the other cases?

The crux of the first case not requiring parens is that &zip is declared
as listop and as such consumes the @even after the , which otherwise would
be left for &say. And if &say weren't declared/assumed listop, the @even
would be evaluated in Void context and not appear in the print at all.

Or do I miss something important? E.g. has () become a circumfix deref op?
--
$TSa.greeting := "HaloO"; # mind the echo!


Re[2]: zip with ()

2005-08-01 Thread Andrew Shitov
TTS> BTW, you didn't mean originally:

TTS>say zip (@odd), (@even); # prints 13572468 or 12345678?

That is exactly like with similar printing result of sub() call:

 print sqrt (16), 5; # shout print 45.



--
___
Андрей, [EMAIL PROTECTED]
___



Re: zip with ()

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

HaloO,

Andrew Shitov wrote:

Is it possible to avoid significance of whitespaces?


Yes, with:

  say zip .(@odd, @even);

Looks like a method and *is* a method in my eyes.
First &zip is looked-up and then bound as block owner.
Arguments are of course two array refs to @odd and @even
respectively.

BTW, you didn't mean originally:

  say zip (@odd), (@even); # prints 13572468 or 12345678?

Does &zip now interleave two array refs instead
of flattened arrays?


I think, such an aspect of Perl 6 would be awful.



IB> Whitespace is significant:

IB> say zip(@odd, @even);
IB> say zip (@odd, @even);

--
$TSa.greeting := "HaloO"; # mind the echo!


Re[2]: zip with ()

2005-08-01 Thread Andrew Shitov
Is it possible to avoid significance of whitespaces?

I think, such an aspect of Perl 6 would be awful.

IB> Whitespace is significant:

IB> say zip(@odd, @even);
IB> say zip (@odd, @even);

--
___
Andrew, [EMAIL PROTECTED]
___



Re: zip with ()

2005-08-01 Thread Ingo Blechschmidt
Hi,

Andrew Shitov wrote:
> I tried zip under pugs.
> 
> my @odd = (1, 3, 5, 7);
> my @even = (2, 4, 6, 8);
> my @bothA = zip @odd, @even;
> print @bothA;
> 
> This code prints 12345678 as expected.
> 
> After parenthesis were used to group zip arguments, results changes
> to 13572468. Is it right?

Whitespace is significant:

say zip @odd, @even;# &zip gets two arguments, result is
# 12345678.
say zip(@odd, @even);   # &zip gets two arguments, result is
# 12345678.
say zip (@odd, @even);  # &zip gets only one argument, the flattened
# list (@odd, @even), containing the
# elements (1,3,5,7,2,4,6,8). Then &zip
# tries to zip this one list, resulting in 
# 13572468.


--Ingo

-- 
Linux, the choice of a GNU | To understand recursion, you must first
generation on a dual AMD   | understand recursion.  
Athlon!| 



zip with ()

2005-07-31 Thread Andrew Shitov
Hi,

I tried zip under pugs.

my @odd = (1, 3, 5, 7);
my @even = (2, 4, 6, 8);
my @bothA = zip @odd, @even;
print @bothA;

This code prints 12345678 as expected.

After parenthesis were used to group zip arguments, results changes
to 13572468. Is it right?

--
___
Andrew, [EMAIL PROTECTED]
___