On Thu, Jun 16, 2005 at 07:24:42PM +0300, Gaal Yahas wrote:
: [Sent off-group by mistake. On #perl6 the impression was that now Pipe
: is becoming a Role for things that can lazily be read from; and thus any
: filehandle or lazy list fulfills them. Larry, please help us understand
: if this is the case.]
That's perhaps an overgeneralization. I don't care if there's a
special Pipe type or role, as long as there's some declaration for
binding that can determine the *syntactic* intent of the caller
to do something with multi-dimensional lazy lists, which implies
there's some kind of mark to convey that syntactic intent. If it is
a role, it's probably only applied to lazy containers implicitly by
the calling code. In fact, the actual data structure to be bound
to the slurpy is probably a Lazy of Lazys, but we want to avoid
two problems here by marking that structure as special. We don't
want to accidentally bind a Lazy of Lazys to the slurpy array merely
because the next parameter of the list accidentally happens to be one.
The intent to use semicolon or pipes has to be there syntactically to
get the special multidimensional mark. In @[EMAIL PROTECTED], @bar is always
a one-dimensional slice, even if it happens to be lazy. You must
specify @foo[[;[EMAIL PROTECTED] or @foo[()] <== @bar to get the special mark.
On the receiving end, we want to avoid the problem of feeding
multidimensional lists to parameters that are expecting flat lists.
So the default is that all the pipes into an ordinary slurpy flatten,
as if all the semicolon boundaries were actually commas. But for
those relatively rare cases where we do want to pay attention to the
semicolon boundaries, we want an explicit declaration that says not
to flatten those semicolon boundaries. That's what I was aiming at
with the Pipe declaration.
: On Thu, Jun 16, 2005 at 08:53:41AM -0700, Larry Wall wrote:
: > The semicolon operator no longer builds a list of lists, but a list
: > of pipes, which are specially marked Lazies that know they came from
: > pipe operators (including semicolons as a kind of pipe operator).
: > When bound to an ordinary splat array (or in fact any splat array whose
: > type isn't Pipe), the Pipes flatten as if they were comma separated.
: > When bound to an array of type Pipe, each pipe stays discrete.
:
: I thought the class Pipe was reserved for what the result of open-"foo|"
: is in Perl 5? That's what we call it in Prelude.pm at least; if it needs
: to be renamed maybe IPC could work.
I'm not stuck on using the word Pipe--it fact, if it's going to be
an implicit mark, it should maybe be Huffman coded to something
longer, MultidimensionalSliceComponent or some such... :-)
On the other hand, system pipes could be called SysPipe, and it would
be nice to think of these inner things as pipes, since that's what
we're calling ==> and <==.
But maybe declaring the type of the elements of the slurpy is the wrong
approach anyway. Maybe it's the container type:
sub zip ([EMAIL PROTECTED] is MultiDim) {...}
or maybe even just a shape:
sub zip ([EMAIL PROTECTED] is shape(*;Lazy) {...}
What I'm trying to do here is to make the meaning of semicolon and
pipes context-dependent, so that those contexts that want to care
about the boundaries can care, and those contexts that don't want to
care don't have to.
On the flip side, I'd like to avoid inflicting another mandatory
abstraction on the naive users, so I'm not really interesting in
advertising a Pipe role for general use. Most new users won't realize
that they're dealing with a dwimmy semicolon--they'll just cargo cult
the notion that zip() takes a semicolon list.
This does leave open the question of exactly which built-in list
contexts do pay attention to pipe lists. Obviously, subscripts do.
A list of values in parens doesn't. I think array and hash composers
probably should pay attention, just because they look like subscripts.
And because it's useful for readability to cut down the nesting of
brackets by one level. However, they should probably warn if the
only semicolon is at the end, on the assumption that it's accidental.
On the other hand, we were using semicolon to differentiate hash
composers from blocks, so that's a bit of an issue.
Larry
