Autothreading generalization

[Luke Palmer]

S09 states (in "Parallelized parameters and autothreading") that if you
use a parameter as an array subscript in a closure, the closure is a
candidate for autothreading.

-> $x, $y { @foo[$x;$y] }

Means:

-> ?$x = @foo.shape[0].range,
   ?$y = @foo.shape[1].range { @foo[$x;$y] }

And each range is automatically iterated.

This is considered by some to be far too subtle.  A simple error in
number of parameters passed could result in very strange semantics;
also, declaring some dimensions for efficiency can wildly change some
semantics. The situation is made somewhat better by the fact that this
only happens on arrays that have predeclared dimensions (though I'd
argue that that's even more subtle).

I have a different idea.

Let's put the current meaning of the qw   aside for the moment.  We'll
now use them as threading brackets.

The bracketing construct  @foo[$^i]  makes a junction-like object
threaded over all reasonable values of $^i.  Similarly, 
 @foo[$^i] * @bar[$^j]  creates a two-dimensional object which is the
outer product of @foo and @bar under multiplication (just iterating over
all values of $^i and $^j).

In the case that the values of $^i and $^j cannot be determined from the
way they are used, some extra syntax will be necessary.  I'm not sure
what that is (suggestions welcome).

In list context, the objects expand out into appropriately-dimensioned
lists.  In scalar context they behave much like junctions, threading all
operations, but they perform inner products as many times as necessary.

So:

my @result = Â @foo[$^i] + @bar[$^i] Â

Is the same as:

my @result = Â @foo[$^i] Â + Â @foo[$^i] Â

If you give it a statement without placeholders:

If it's a plain array, it creates an appropriately dimensioned
object.

If it's a scalar and an iterator, then it iterates it.  If it's any
other scalar there is an error.

These are lexical distinctions (except for checking whether something is
an iterator).

Here comes the fun part.

The typical hyper operation now looks like:

my @result =  @foo  +  @bar Â;

And we can drop the outer brackets, saying that they're implied in this
simple case.

my @result = @foo Â+Â @bar;

And we also have a list iterator notation:

for Â$fh {
say .uc;
}

Unfortunately, the scalar iterator notation would have to be different.
But perhaps it should be.

Here are some examples derived from S09:

To write a typical tensor product:

C_{ijkl} = A_{ij} * B_{kl}

You write either of:

 @C[$^i; $^j; $^k; $^l] = @A[$^i; $^j] * @B[$^k; $^l] Â
@C = Â @A[$^i; $^j] * @B[$^k; $^l] Â

Or to write another typical tensor product:

a^j = L_i^j b^i

You write either of:

 @a[$^j] = @L[$^i; $^j] * @b[$^i] Â
@a = @L Â*Â @b;

(The last one works because the first index of @L is the one we want to
iterate over---like PDL threading)

As for stealing the french brackets, I think that it's a justified
cause.  They're already used for hyper operations, and this is just
generalizing that.  I argue that the interpolating qwÂÂ meaning will be
the most neglected quote around.  For it to be useful, you have to be
slicing on variables and constants at the same time, which is quite
uncommon.

Luke

Re: Autothreading generalization

[Craig DeForest]

Quoth Luke Palmer on Monday 31 January 2005 03:46 pm,
> C_{ijkl} = A_{ij} * B_{kl}
>
> You write either of:
>
> Â @C[$^i; $^j; $^k; $^l] = @A[$^i; $^j] * @B[$^k; $^l] Â
> @C = Â @A[$^i; $^j] * @B[$^k; $^l] Â

Hmm... This is both insanely great and also greatly insane.  

The issue is that, although the tensor notation is powerful, the readability 
is becoming lost in all the sigils/funny_characters on the thread variables.

Most of the non-perl-geek scientific-computing people I know already balk at 
the '$' and '@' characters because they increase the amount of black noise in 
scientific code too much; constructions like that just might send them all 
screaming back to FORTRAN.  Is there a way to generalize that reduces the 
amount of black noise so that the expression shines through?

   << @C[ ^i; ^j; ^k; ^l ] = @A[ ^i; ^j ] * @B[ ^k; ^l ] >>

is much better from a readability standpoint since the j's and k's are 
actually visible, but may be horrific from a parsing perspective.

Re: Autothreading generalization

[Luke Palmer]

Luke Palmer writes:
> Or to write another typical tensor product:
> 
> a^j = L_i^j b^i
> 
> You write either of:
> 
> Â @a[$^j] = @L[$^i; $^j] * @b[$^i] Â
> @a = @L Â*Â @b;

Or not.  There's that implicit Einstein summation involved, and a
general purpose programming language isn't about to give dibbs to
summation.

I think it would have to be:

@a = reduce { @^a Â+Â @^b } @L Â*Â @b;

And that ain't so bad (much more explicit, certainly).

Luke

Re: Autothreading generalization

[Luke Palmer]

Craig DeForest writes:
> Quoth Luke Palmer on Monday 31 January 2005 03:46 pm,
> > C_{ijkl} = A_{ij} * B_{kl}
> >
> > You write either of:
> >
> > Â @C[$^i; $^j; $^k; $^l] = @A[$^i; $^j] * @B[$^k; $^l] Â
> > @C = Â @A[$^i; $^j] * @B[$^k; $^l] Â
> 
> Hmm... This is both insanely great and also greatly insane.  
> 
> The issue is that, although the tensor notation is powerful, the readability 
> is becoming lost in all the sigils/funny_characters on the thread variables.
> 
> Most of the non-perl-geek scientific-computing people I know already balk at 
> the '$' and '@' characters because they increase the amount of black noise in 
> scientific code too much; constructions like that just might send them all 
> screaming back to FORTRAN.  Is there a way to generalize that reduces the 
> amount of black noise so that the expression shines through?
> 
><< @C[ ^i; ^j; ^k; ^l ] = @A[ ^i; ^j ] * @B[ ^k; ^l ] >>
> 
> is much better from a readability standpoint since the j's and k's are 
> actually visible, but may be horrific from a parsing perspective.

Yeah, the sigils do get in the way for small placeholder variables like
these.

 @C[ $i; $j; $k; $l ] = @A[ $i; $j ] * @B[ $k; $l ] Â

Losing the carets doesn't do much for us (and would force us to use the
explicit syntax, whatever that might be).  Hmm, on the other hand, ^
doesn't mean anything in term context yet.  I feel uncomfortable about
allowing ^ as a shorthand for $^, since every other variable in the
whole damn language has one of the four standard sigils.

Luke

Perl 6 Summary for 2005-01-18 through 2005-01-31

[Matt Fowles]

Perl 6 Summary for 2005-01-18 through 2005-01-31
All~

Welcome to another double feature summary. Sadly, this one was delayed
because of an argument that I was/am having with my connection.
Fortunately, a generous neighbor has allowed me to use his connection
for the time being. So, with that random act of kindness in mind, I
bring you

  Perl 6 Language
   Perl 6 on E
Rich Morin wondered if features of the language E would be supported on
Perl 6. Larry told him that many would, and "As a limiting case, you can
always back out the entire Perl grammar and install the E grammar in its
place". This was left as an exercise for the reader.

 -- the thread

 -- E's homepage

   challenge the Palmer...
Luke Palmer produced answers to Austin Hastings's "How do I" questions.
Anyone else with such questions should send them to the list lest Luke's
learnedness loses luster.



   refactoring Perl automatically
Matisse Enzer re-re-raised the thread on refactoring Perl. This time he
posted a link to EPIC an Eclipse plugin that uses Devel::Refactor.
Unfortunately, I think that he is still using the google groups
interface to post the language. I shall repeat, emails posted via google
groups do NOT make it to the list itself.

 --
thread  -- EPIC 

   loops, bare blocks, and my head hurts
Juerd wondered if last/redo could be used outside loops. Larry provided
the long answer. The short answer is no, things act basically rationally
so that return, next, and last all behave as expected.



   where without type
Juerd wondered if he could use a where clause with a type. The answer is
yes, as it will often be wanted to restrict values admitted to a
multimethod. This led me to the evil thought of putting side-effects in
a where clause on several multi-methods and watching the pain of
resolution cause very difficult to find bugs. Sometime I think that my
mind looks for nasty ways to write bad code a little too much.



   Autothreading
Luke Palmer posted his musing about autothreading. I must say it looks
powerful enough to blow off your entire lower body if you shoot yourself
in the foot.



  Perl 6 Compiler
   Pugs
Not just ugly dogs anymore, they are also P6 interpreters written in
Haskel. Sounds really cool to me.



  Parrot
   MMD and meta-stuff
In a thread that was also posted to p6l (sorry about that), I attempt to
explain how parrot object system is already very close to the Common
Lisp Object System and why it should become even closer. I am not sure
if I succeeded or not. My ability to express really abstract thoughts
without a white board is poor.



   RT clean up
Will Coleda has been putting an extensive amount of work into cleaning
up part for public presentation with a focus on RT and organization.

 -- Hall of Shame 15308

 -- ROADMAP



























   argv[0]
Wukk (who is Will when I get off key) wants the name of the invoked
executable. Dan upped the anti by offering the full and base name
variants of the interpreter, the program, and the invoked thing.



   OSCON
Robert Spier put out a call for OSCON proposals.



   read and readline
Matt Diephouse has been working on getting read and readline cleaned up.

 -- RT ticket

 -- discussion

 -- partial resolution

 -- an offered patch

   test_main.c
Bloves posted a patch updating test_main.c. Unfortunately, it turns out
that this file is obsolete and needs to be removed.



   MinGW support
François Perrad provided a patch to improve MinGW support. Leo applied
it.



   Compile problems
Will Coleda has a failing fresh build. Warnock applies.



   NCI improvements
Bernhard Schmalhofer provided a patch improving NCI stuff. Leo applied
it.



   VS.NET 2003
Sriram Krishnan fought throu