This week's summary

[The Perl 6 Summarizer]

The Perl 6 summary for the week ending 2006-01-01
Another year, another summary. You might think I'm going to summarize
the events of the whole year, but it turns out that chromatic's already
done it. So in the spirit of laziness, I'll just point you at his year
end summary.



Sadly for us all, he doesn't go into enough detail on the events of the
last week for me to go straight into the coda. I shall have to talk to
him about next year.

This week sees a big non-technical change in the Pugs camp, lots of
roadmapping and implementation in the Parrot camp, and a more and more
concrete feel of what the language is going to look like in the
perl6-language camp.

Pretty much business as usual really.

This week in perl6-compiler
  Runtime typecasting
Autrijus Tang is now Audrey Tang. Read her explanation on her blog.
Speaking personally I'm delighted that she's found the courage to make
the change and wish her the best of luck and happiness in her new/true
identity.



  Pugs on Cygwin
There was a fair amount of discussion on getting pugs and parrot running
in the Cygwin environment this week. Last time I looked, things were
working again.



  This week's Pugs developments
Audrey's taken to summarizing pugs developments on her blog and to
posting digests of these posts on the list. She wrote about PIL and
Rules this week.

 -- Pugs-PIL developments

 -- Pugs-Rule developments

 -- Pugs-Rule: Grammar support

Meanwhile, in perl6-internals
  Threading PDD?
Patrick Michaud suggested, after a question from Klaas-Jan Stol, that it
might be a good idea to create a placeholder Threading PDD (Parrot
Design Document) noting that threading hasn't been specced yet and that
a draft would be welcomed. Warnock applies.



  Pugs is the official Perl 6?
Or am I putting words into Luke's mouth? Read, then decide.



  .imc or .pir? There can only be one
As part of the great Parrot reorganization, Chip declared that the IMC
vs PIR ambiguity had to be resolved. As he put it:

IMC vs. PIR

Two names enter

One name leaves

The name that left was PIR, any files you find with .imc extensions
should be cruelly laughed at while you kick sand in their faces.



  Dynamic binding patch
Bob Rogers offered up a patch to implement dynamic binding of globals
for the list's consideration. Leo thought the patch was mostly sound,
but that the whole dynamic binding thing needed more thought and
infrastructure. Which is probably a broad hint to Chip and possibly
@Larry (said hint hasn't been taken yet though, well, not in public).



  Smoke testing
Leo pointed everyone at the Perl Image Testing Architecture, which has
possibly the coolest acronym of any Perl project in recent years. He
thought it would be useful to use for additional Parrot platform testing
as well.





  Lots and lots of TODOs
I'm not going to enumerate them here, but Will Coleda, Matt Diephouse
and others have been adding loads of TODO entries to the Parrot
bugtracker. Which is nice.

  IMCC optimizer instruction duplication and opcode write/reads
Amos Robinson wanted to know how to go about duplicating instructions
and wondered about the correct semantics of in/out/inout arguments. Leo
came through with the answers.



Meanwhile in perl6-language
  Iterating over complex structures
Rob Kinyon applied the 'What does Ruby do?' pattern to the problem of
iterating over complex structures. Mostly it looks good, but I'm hoping
that someone else considers applying the 'What does Smalltalk do?'
pattern as well. Subject to tuit supply, I might even do that myself.



  Match objects
"Who is Match, and to what does he object?"

Sorry. Couldn't resist.

Patrick and Luke discussed the behaviour of match objects.

  (Array) introspection
Ilmari Vacklin wondered about how to introspect on the structure of
arrays and other data structures. Warnock applies.



  Array/list transformations
Rob Kinyon pointed out the difficulties of dealing with binding array
slices and other such goodies. Larry thought it wasn't really that
difficult (from the point of view of the perl programmer, things might
be different for the implementers)



  Relationship between slurpy parameters
Austin Frank wondered about the different uses of "prefix:<*>" in
parameter lists and elsewhere. Stuart Cook had answers. Piers Cawley
worried about the current behaviour of "prefix:<*>"

Re: Junctions again (was Re: binding arguments)

[TSa]

HaloO,

Luke Palmer wrote:
Which "reads nicely", but it is quite opaque to the naive user. 


I guess many things are opaque to naive users ;)



Whatever solution we end up with for Junctions, Larry wants it to
support this:

if $x == 1 | 2 | 3 {...}

And I'm almost sure that I agree with him.


This actually would be easy if Larry decided that *all* operators
are recognized syntactically and dispatched at runtime. But he likes
to have == strictly mean numeric comparison. Well, with the twist
that the numericy is imposed on the values retrieved from the list
backing the any-junction and the whole thing beeing settled at compile
time syntactically.

But if we assume that all information that is available to the
compiler is available to the runtime as well, then I don't see
any reason why the evaluation of the condition above might not be
a dispatch on the if flow controller multi sub or some such with
some JITing and auto-loading thrown in.

Let me illustrate the point with the well know set of the two
inner operators of nums + and * where * is sort of defined in
terms of +:

  3 * 4 --> 12   # symmetric MMD, infix notation,
 # atomic evaluation

 (3 *)4 --> 4+4+4 # asymmetric prefix, left adjoined operator,
  # two step evaluation (addition used for illustration)
  #   1: curry lhs to form prefix op
  #   2: apply op from step 1

  3(* 4) --> 3+3+3+3 # asymmetric postfix, right adjoined operator,
 # two step evaluation

I think the compiler decides which of the alternatives is applicable
and generates code accordingly. But why shouldn't it defer the
generation of the semantic tree until dispatch time where the
associativity of the op and the involved types are known? I would
call that syntax tree dispatch or perhaps multi stage MMD. With caching
the results in a local multi this appears as doable to me.



There is a conflict of design interest here.  We would like to maintain:

* Function abstraction
* Variable abstraction


With container types these two are embedded into the type system
which I still hope supports arrow types properly. I've sort of developed
the mental model of --> being a co-variant forward flow of control
or program execution and <-- beeing a contra-variant keeping of achieved
state:

   -->   sub junction /   iteration / implication  / flow
  <--  resub junction / reiteration / replication  / keep
  <--> bisub junction / equivalence / rw container / sync / snap (shot)

The latter two are not yet Perl 6, and the --> has a contra-variant part
in the non-invocant params, which are of course sync or snap points of
a program. Note that lazy params aren't snapped valueish but typeish in
the sense that the imposed constraints *at that moment* in execution
time hold. Well, and if they don't then we have of course 'ex falso quod
libet' later on :)



There's got to be a good solution lying around here somewhere...


Hmm, operator junctions perhaps? I think that the three relations <, ==
and > are the prototypical order ops. I do not see a priori numerics in
them. This is at best Perl 5 legacy. Note that <=, != and >= are two
element any-junctions from the set of the three primary comparators.
And <=> is a one-junction of all three with succeeding mapping of the
ops to -1, 0 and +1.

Together with negation as center point we get the Fano Plane of the
comparison ops in a crude ASCII chart:

 -1|0 00|+1
 {<=}---{==}---{>=}
   \/
\   {! }   /
{<}  {>}
 none(0,1) <-- -1 \  / +1 --> none(-1,0)
   \/
{!=}
-1|+1 --> none(0)

 <=> --> one(-1,0,+1) as circle connecting {<} {==} {>}

can theory theory capture these things in a systematic framework?
--

Re: This week's summary

[Ilmari Vacklin]

ti, 2006-01-03 kello 13:57 +, The Perl 6 Summarizer kirjoitti:
> Planet Perl Six is a handy news aggregator of several Perl 6 related
> sources.
> 
> 

I believe that is actually 

Thanks for the great summary!

-- 
wolverian <[EMAIL PROTECTED]>

Re: Junctions again (was Re: binding arguments)

[Jonathan Lang]

Luke Palmer wrote:
> Whatever solution we end up with for Junctions, Larry wants it to
> support this:
>
> if $x == 1 | 2 | 3 {...}
>
> And I'm almost sure that I agree with him.  It's too bad, because
> except for that little "detail", fmap was looking pretty darn nice for
> junctions.

Not really.  If I read the fmap proposal correctly,

  if any($x, $y, $z) »==« any(1, 2, 3) {...}

would do the same thing as

  if $x == 1 || $y == 2 || $z == 3 {...}

...which fails to dwim.  Not to mention

  if all($x, $y, $z) »==« any(1, 2, 3) {...}
  if any($x, $y, $z) »~~« all($a, $b, $c) {...}

...which ought to work like

  if ($x == 1 || $x == 2 || $x == 3)
  && ($y == 1 || $y == 2 || $y == 3)
  && ($z == 1 || $z == 2 || $z == 3)
  {...}
  if ($x ~~ $a && $x ~~ $b && $x ~~ $c)
  || ($y ~~ $a && $y ~~ $b && $y ~~ $c)
  || ($z ~~ $a && $z ~~ $b && $z ~~ $c)
  {...}

And then there's the (minor) ugliness of having to remember to include
hyperspanners (» and/or «) whenever you want to evaluate junctions.

--

Side note: "any(1, 2, 3)" is indistinguishable from "one(1, 2, 3)",
because the values 1, 2, and 3 are mutually exclusive.  People often
use the inclusive disjunction when they mean the exclusive one, and
get away with it only because the values that they're dealing with are
mutually exclusive.  Another issue is that one-junctions conceptually
represent a single value at a time - though which one is unknowable -
whereas any-junctions can also represent several values at once,
all-junctions usually do so, and none-junctions can even represent no
values.  Conceptually, one-junctions are scalar-like, while the other
kinds of junctions are list-like; so one ought to think of "$a ~~
one(@set)" as matching a scalar to a scalar, whereas "$a ~~ any(@set)"
would be matching a scalar to a list (and thus would more properly be
"$a ~~« any(@set)"). But because the distinction between inclusive and
exclusive disjunctions is moot when the component choices are already
mutually exclusive, there's an advantage to any-junctions and
one-junctions behaving in the same way.

--
Jonathan "Dataweaver" Lang

Re: Junctions again (was Re: binding arguments)

[Luke Palmer]

On 1/4/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> > And I'm almost sure that I agree with him.  It's too bad, because
> > except for that little "detail", fmap was looking pretty darn nice for
> > junctions.
>
> Not really.  If I read the fmap proposal correctly,

You didn't :-)

>   if any($x, $y, $z) »==« any(1, 2, 3) {...}
>
> would do the same thing as
>
>   if $x == 1 || $y == 2 || $z == 3 {...}

The key point is that >>==<< just threads == through the (binary in
this case) functor, and it's up to the functor to decide what that
means.  For lists:

(1,2) >>+<< (3,4) === (4,6)

But for junctions:

1|2  >>+<<  3|4  === 4|5|5|6 === 4|5|6

The thing that makes lists "zip-thread" is the definition the
Functor{List} instance, not anything fundamental about functors.

> Side note: "any(1, 2, 3)" is indistinguishable from "one(1, 2, 3)",
> because the values 1, 2, and 3 are mutually exclusive.

That's only true when you're thinking about equality:

1 < any(1,2,3)   # true
1 < one(1,2,3)   # false (1 < 2 and 1 < 3)



  People often
> use the inclusive disjunction when they mean the exclusive one, and
> get away with it only because the values that they're dealing with are
> mutually exclusive.  Another issue is that one-junctions conceptually
> represent a single value at a time - though which one is unknowable -

Junctions are frightfully more abstract than that.  They only take on
meaning when you evaluate them in boolean context.  Before that, they
represent only a potential to become a boolean test.  You could think
of them like an "operator voltage": a comparison divided by the
operator and one of the operands.

Luke

S3 vs. S4: parallel lists

[Jonathan Lang]

I think there might be a discrepency between S3 and S4.

S3:
> In order to support parallel iteration over multiple arrays,
> Perl 6 has a zip function that builds tuples of the elements of
> two or more arrays.
>
> for zip(@names; @codes) -> [$name, $zip] {
> print "Name: $name;   Zip code: $zip\n";
> }
>
> zip has an infix synonym, the Unicode operator ¥.
>
> To read arrays in parallel like zip but just sequence the
> values rather than generating tuples, use each instead of zip.
>
> for each(@names; @codes) -> $name, $zip {
> print "Name: $name;   Zip code: $zip\n";
> }

S4:
> To process two arrays in parallel, use either the zip function:
>
> for zip(@a;@b) -> $a, $b { print "[$a, $b]\n" }
>
> or the "zipper" operator to interleave them:

Shouldn't S4 replace "zip" with "each"?

--
Jonathan "Dataweaver" Lang