Perl 6 Summary for 2004-01-03 through 2004-01-11

[Matt Fowles]

Perl 6 Summary for 2004-01-03 through 2004-01-11
Welcome to another Perl 6 summary. In this summary, we will explore such
thrilling issues as multi-dimensional slices of Chinese food. After all,
the amount of sauce any piece of Chinese food can absorb is proportional
to its surface area, which is a direct function of the number of
dimensions in which it is sliced (provided that we ignore degenerate
cases like fractal cuts of Peking duck).

  Perl 6 Language
   1x6 vs 6
Craig DeForest wondered how to disambiguate a 1x6 2D array slice from a
6 element 1D array slice. He suggested a syntax inspired by PDL. Larry
admitted to not having examined this particular issue and stated that he
was open to suggestions. Some suggestions arrived.



   code as comment
Stéphane Payrard wanted to know if there is an easy way to alias
arguments to a function. Thus allowing a longer version for readability
when calling the function and a short version inside the function. Larry
suggested "$s is named", which I like. The thread then devolved
into punning in French.

 -- main thread on p6l

 -- initial post on p6c

  Perl 6 Compiler
   Pascal -> Pcode -> Parrot -> Profit
Sven Schubert asked about the feasibility of putting Pascal on Parrot.
He noted that with the infrastructure mentioned in "Perl 6 and Parrot
Essentials" the problem would not be too bad. Apparently "Essentials"
makes a few promises that we have yet to live up to. But we are working
towards it. In the mean time, Stéphane Payrard suggested a way for him
to kill to bird with one stone: Pcode.

 -- Pcode suggestion

 -- initial post

   Grammar improvements
Luke Blanshard submitted some rules for Perl6::Grammar. Luke Palmer
committed a slight variantion of his work, and the hacking commences...



  Parrot
   pop_pad
Peter Christopher wondered why pop_pad had not been implemented last
week. This week Leo implemented it and asked for tests.



   Resizable arrays
Simon Glover asked why ResizablePMCArray was so different from all of it
Resizable*Array bretheren. The answer is the Leo improved it. This
brings up an obvious task for someone looking for a reasonably friendly
chunk of Parrot to work on. Rationalizing the implementation of the
various Resizable*Arrays would probably be a good task for a novice
looking to dig into something. Perhaps one who is on winter break...



   Parrot 0.1.1 nci troubles
Ian Joyce noticed that parrot 0.1.1 was having some trouble with nci.t.
Leo admitted that this was the case, but it is fixed in CVS.



   test or benchmark
Nicholas Clark wondered if resizablestringarray.t was actually a
benchmark, because it had a big number which was really hurting his poor
machine. Simon Glover admitted to the copy paste error.



   x86 solaris 2.5.1 and 2.7
Andy Bach and Nicholas Clark worked towards getting parrot happier on
the aforementioned architecture. This thread seemed to peter out when
Nicholas asked "how do we run a callback unconditionally after
gccversion is known, independent of its value?".



   VTABLE_call_method
Leo and Sam had a disagreement about whether a call_method vtable would
make sense. I think that we are waiting for higher intervention...



   updated perlhist.txt
Will Coleda applied Bernhard's patch updating perlhist.txt and
streams.t.



   Warnock Warnocked
Will Coleda applied the long Warnocked update to Warnock's contact
information with only a trace of irony.



   gcov of perlarray.pmc reaches 100%
Simon Glover got perlarray.pmc to have full test coverage. Nifty. Some
brave soul (possibly fitting an earlier description) should try this
with the Fixed*Arrays...



   Parrot under Solaris 9
Nicholas Clark, Andy Doughery, and Christian Aperghis-Tramoni all tried
to convince Parrot to work on Solaris. They are brave souls.



   parrot-config updates
Peter Christopher asked questions about the parrot-config.imc. He also
provided an initial solution.

 -- questions

 -- solutions

   Key Question
Simon Glover noticed some bad behavior with respect to Key PMCs. Leo and
Sam both admitted that it was bad and that some work needed to be done.



   Parrot PDL
Bernhard Schmalhofer posted a pointer to PDL. Luke Palmer pondered
Piddles as Parrot PMCs. Craig DeForest proposed a path passing through
PDL's PP and pausing at Parrot. (Parenthetically, 

Re: Dimension of slices; scalars versus 1-element arrays?

[Dave Whipp]

Larry Wall wrote:
On Sat, Jan 08, 2005 at 11:37:06AM -0700, Craig DeForest wrote:

: Is the perl6 expression
:   @a[4; 0..5];
: a 1x6 array (probably correct)?  Or a 6 array (probably not correct)?
Certainly the former.  I don't think dimensions should ever disappear
accidentally.
Except when you assign in scalar context -- which I guess isn't accidental.
We know that
@a = (1, 2, 3);
$b = @a[1];
Loses the dimension as a DWIM.
So perhaps we could say that assigning to a lower dimension always gets 
rid of a dimension of size 1 -- or error if it can't:

@c = ( 1,2,3 ; 4,5,6 );
@d[*;*] = @c[ 1 ; * ]; # @d is 2d
@e[*] = @c[ 1 ; * ];  # @e is 1d
@f = @c[1;1];  # @f is 2d: no dimensions lost
@g[*] = @c[ 0,1 ; 0,1 ]; # error: cannot collapse
as our disambiguator.
{ @c[;*] but shape(*) } wouldn't work, because the :shape option leaves 
additional dimensions open.

Dave.

Re: Dimension of slices; scalars versus 1-element arrays?

[Craig DeForest]

On Tuesday 11 January 2005 10:06 pm, Dave Whipp wrote:
> We know that
>
> @a = (1, 2, 3);
> $b = @a[1];
>
> Loses the dimension as a DWIM.
>
> So perhaps we could say that assigning to a lower dimension always gets
> rid of a dimension of size 1 -- or error if it can't:
>
> @c = ( 1,2,3 ; 4,5,6 );
> @d[*;*] = @c[ 1 ; * ]; # @d is 2d
> @e[*] = @c[ 1 ; * ];  # @e is 1d
> @f = @c[1;1];  # @f is 2d: no dimensions lost

Hmmm   I'm sorry, but I'm not quite following what you mean by 
the '=' in this case.  I've been thinking of '=' as a full-on, 
dimensional-context-free assignment, and of ':=' as a shaped, elementwise 
assignment, by analogy to the current perl5/PDL setup.  In that paradigm, 
"@e[*] = @c[1;*]" doesn't mean anything, since the LHS isn't really a
full-on lvalue -- it's an array slice with (already) a definite shape (an 
"l2value"?).

But I could just be confused about intent here. I'm used to thinking of 
piddles, which are pretty regimented -- they have a definite size along each 
axis.  Do perl6 multi-dimensional arrays have definite sizes, or are they 
"just" lists of lists of whatevers, under the hood?  Each of those structures 
would be very useful for an almost completely different set of things.

I guess Larry was right when he hinted that there're still dragons here... so,
er, sorry to have opened a can of wyrms...