Re: sub my_zip (...?) {}
On Thu, Jun 16, 2005 at 10:28:26PM +, Luke Palmer wrote: : You know, before I read this part of the message, I was thinking : precisely that. Nullary splat should do it, so that @foo[*] will : work. Unary splat would of course get our favor if it can be : interpreted that way, but in cases like: : : @foo[*] : bar(*) : : It is unambiguous, and you can always say (*) to disambiguate. I like : the look of that too. Except I've still got my eye on nullary * to mean all keys in this dimension, and that would conflict if you want that meaning for part of an expression but pipe to a different part. One character that *would* work in that position is the Unix pipe character: |. @foo[|] bar(|) On the other hand, that kind of points out the fact that we *aren't* using | for pipes in Perl 6. It'd be nice to have some kind of visual reference to == and ==. Perhaps @foo[] bar() could be forced into that duty, on the assumption that if you really want a null string, there's always some kind of '' workaround. But that's concentrating on the pointy parts of the pipe operators. How 'bout focusing on the pipey parts instead and use a nullary iterator: @foo[=] bar(=) I kind of like that, particularly since the pointy end of a pipe *is* an iterator. Larry
Re: sub my_zip (...?) {}
On Thu, Jun 16, 2005 at 05:40:31PM +0800, Autrijus Tang wrote:
: Currently in Pugs *zip has no signature -- it simply rewrites its
: arguments into the listfix (i.e. Y) function.
:
: That is bad because it can't be introspected, and you can't define
: something like that yourself. It also makes it uncompilable to Parrot
: as I don't control the runloop there. :)
I think something like
sub zip (Pipe [EMAIL PROTECTED]) {...}
is probably sufficient.
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.
: Also, currently the following code does not flatten @a and @b together,
: which I'm not exactly sure is correct or not:
:
: zip(@a, @b);
That should flatten into a single slice/pipe, so zip should probably
have the option of complaining about it somehow. On the other hand,
you don't want warnings for the default on any such binding, since
subscripts use the same binding, and we'll often have subscripts with
a single slice.
We also have this construct to allow indirect semicolon lists:
zip( [;] @lists )
(The [;] reduction operator takes the place of semi in S09.)
This does imply that we can pipe into a subscript somehow. If we
choose something like () for our placeholder meaning pipe into this
location, then
@[EMAIL PROTECTED]; @b; @c]
is the same as
@foo[()] == @a == @b == @c
or
@c ==
@foo[()] == @a == @b
or
@c ==
(@b ==
@foo[()] == @a
)
or
@c ==
(@b ==
(@a ==
@foo[()]
)
)
though perhaps there's some ambiguity problems with using a single ()
as the target of multiple ==. Note that every list has an implied ()
at the end, which is the default target of pipe operators. That says
to me that we probably make a rule that == binds to the leftmost ()
it sees (if it sees one), so we can differentiate
@a ==
@foo[$x].print()
from
@a ==
@foo[()].print
And in the absence of an explicit (), the rightmost implicit () is
the target, so
@a ==
@foo[$x].print
should feed the pipe to the print, not the subscript, even though
$x is officially part of a one-element slice with an implicit ()
at the end. I think this is closest to what people will expect.
Larry
Re: sub my_zip (...?) {}
[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.] 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. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: sub my_zip (...?) {}
Larry Wall writes: This does imply that we can pipe into a subscript somehow. Why? Or rather, why is that desirable? If we choose something like () for our placeholder meaning pipe into this location, then @[EMAIL PROTECTED]; @b; @c] is the same as @foo[()] == @a == @b == @c That placeholder just looks to me like it's asking for people to be confused by action at a distance. Under what circumstances does using the latter, with n pipes, give an advantage over the former, with n semicolons? Especially given: though perhaps there's some ambiguity problems with using a single () as the target of multiple ==. Note that every list has an implied () at the end, which is the default target of pipe operators. That says to me that we probably make a rule that == binds to the leftmost () it sees (if it sees one) ... And in the absence of an explicit (), the rightmost implicit () is the target That seems to be a lot of rule to remember for some relatively obscure feature, and it's giving a non-intuitive amount of meaning to the innocent-looking empty list (). I think this is closest to what people will expect. Hmmm. I'm not convinced that many people would expect being able to pipe into subscripts at all. Except that you've almost certainly thought about this more than I have, and you are rather good at this language design lark -- so I'm also not convinced by my own criticism of this feature ... Smylers
Re: sub my_zip (...?) {}
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
Re: sub my_zip (...?) {}
Larry Wall wrote: You must specify @foo[[;[EMAIL PROTECTED] or @foo[()] == @bar to get the special mark. I'm uncomfortable with the specific syntax of @a[()] because generated code might sometimes want to generate an empty list, and special-casing that sort of thing is always a pain (and fragile). An empty list of subscripts should return an empty slice. What this mark is really trying to say is The definition of the indices is coming from elsewhere. I'm wondering if these semtantics would make it appropriate to use the yada operator here: @foo[...] == @bar; Dave.
Re: sub my_zip (...?) {}
On Thu, Jun 16, 2005 at 01:05:22PM -0700, Dave Whipp wrote: : Larry Wall wrote: : You must : specify @foo[[;[EMAIL PROTECTED] or @foo[()] == @bar to get the special mark. : : I'm uncomfortable with the specific syntax of @a[()] because generated : code might sometimes want to generate an empty list, and special-casing : that sort of thing is always a pain (and fragile). An empty list of : subscripts should return an empty slice. If you don't actually pipe to it, a null list is exactly what it would be interpreted as, so I don't think it's a very big problem. And outside of generated code, () is always intentional. If there's a potential problem, it's with expecting @a == foo().bar() to feed bar() rather than foo(). So maybe that would have to be written @a == foo().bar(()) or @a == foo(()).bar() Or maybe as you say we just need a special term, though I don't think ... is it. : What this mark is really trying to say is The definition of the indices : is coming from elsewhere. I'm wondering if these semtantics would make : it appropriate to use the yada operator here: : :@foo[...] == @bar; That's cute, but I think that might be overloading the ... token a bit too much, and it's also rather likely to be confused with the postfix ... operator within subscripts. These would be too close, visually speaking: @foo[...] @foo[0...] I suppose a case could be made for @[EMAIL PROTECTED] or some such, since it's an inside out iterator. But () is prettier. Alternately we could go with the unix pipe character: @foo[|] Or maybe a splat @foo[*] Or go with the parens with something in them to indicate the positive absence of something. @foo[(*)] Anyone else want to have a go at this bikeshed? Larry
Re: sub my_zip (...?) {}
On 6/16/05, Larry Wall [EMAIL PROTECTED] wrote: Or maybe a splat @foo[*] Or go with the parens with something in them to indicate the positive absence of something. @foo[(*)] Anyone else want to have a go at this bikeshed? You know, before I read this part of the message, I was thinking precisely that. Nullary splat should do it, so that @foo[*] will work. Unary splat would of course get our favor if it can be interpreted that way, but in cases like: @foo[*] bar(*) It is unambiguous, and you can always say (*) to disambiguate. I like the look of that too. Luke
