Re: Y not
Chromatic
> 'Course, if someone goes ahead and adds the Y combinator, one must
> naturally begin to wonder what the YY combinator would be... :-)
Obviously it generates a function so anonymous that it can't even refer to
itself. I call it the depressed existentialist solipsist operator.
-- c
Larry Wall
The current Y has at least four strikes against it:
* It's an ASCII version of a cute Unicode picture, but other than that,
the picture it doesn't remind you of "zip" at all, especially in
the Y form.
* Functional programmers are likely to continually confuse it with the
Y combinator, and they'll be confused enough as it is.
* It violates the item-vs-list meme that we acquired with x vs xx and
X vs XX.
* Huffmanly speaking, it's rather short for its weight.
Those last reasons suggest that we want something spelled with a double
letter like XX. I thought about replacing it with YY (and letting Y
be the string form of zip), but that looks even less like a zipper.
But I do like the double letter idea for infix listops. It helps them
stand out more. I suspect we'll have a lot of
for @foo XX @bar XX @baz -> $x, $y, $z {...}
as list comprehensions of cross operators, so you'd like to have something
similar for "zip" semantics, and I think the obvious thing is:
for @foo ZZ @bar ZZ @baz -> $x, $y, $z {...}
You'll note that this has association of using the same letter, but
for those who mourn the loss of the word picture, note that the two
Z's form a pair of parallel lines in the middle, indicating that zip
treats the arrays in parallel. Plus the Z itself can be taken to be
a picture of "row major" visitation order: "first you go across, then
go to the beginning of the next row, then go across again."
The Z operator would presumably be the equivalent of >>~<< except that,
as a list infix, it would take a list on either side rather than two
scalar objects as hyperops do.
One could go as far as to say that Z*Z is the list infix form of >>*<<.
Anyway, I think we're close to establishing a convention that a list
infix should generally be formed from two capital letters, with the
additional proviso that if the list infix promotes to a meta operator,
the base operator goes in the middle. And if there's a stringwise or
scalar form, it's the single letter.
'Course, if someone goes ahead and adds the Y combinator, one must
naturally begin to wonder what the YY combinator would be... :-)
Larry
Thomas Wittek
> I think the ¥ and Y operators are going to have to change to something else.
Very probably I missed something as I'm only a distant observer of the
Perl6 development: Why not just call it "zip"?!
There is a function called zip, wouldn't it be possible to create an
operator with the same name?
zip(@a; @b) -> function
@a zip @b -> operator
Or would that lead to grammar ambiguities, that are impossible to resolve?
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: strea...@jabber.i-pobox.net
Jonathan Lang
> Larry Wall schrieb:
> > I think the ¥ and Y operators are going to have to change to something else.
>
> Very probably I missed something as I'm only a distant observer of the
> Perl6 development: Why not just call it "zip"?!
> There is a function called zip, wouldn't it be possible to create an
> operator with the same name?
>
> zip(@a; @b) -> function
> @a zip @b -> operator
>
> Or would that lead to grammar ambiguities, that are impossible to resolve?
more generally, could we say that any function that has no parameters
other than a list - i.e., :(*@) - automatically gets a list-infix
operator form as well? e.g.:
my sub zip(*@list) { ... }
could be called with
zip (@a; @b; @c)
or
@a zip @b zip @c
--
Jonathan "Dataweaver" Lang
Larry Wall
: Larry Wall schrieb:
: > I think the ¥ and Y operators are going to have to change to something else.
:
: Very probably I missed something as I'm only a distant observer of the
: Perl6 development: Why not just call it "zip"?!
: There is a function called zip, wouldn't it be possible to create an
: operator with the same name?
:
: zip(@a; @b) -> function
: @a zip @b -> operator
:
: Or would that lead to grammar ambiguities, that are impossible to resolve?
Hmm, but then what corresponds to XX? I'd be more inclined to go
the other way and say that you can transform any list infix form to
the corresponding function form:
@a ZZ @b ZZ @c -> zip operator
ZZ(@a; @b; @c) -> zip function
@a XX @b XX @c -> cross operator
XX(@a; @b; @c) -> cross function
@a X*X @b X*X @c -> cross product operator
X*X(@a; @b; @c) -> cross product function
@a MM @b MM @c -> minmax operator
MM(@a; @b; @c) -> minmax function
Larry
Joe Gottman
> Hmm, but then what corresponds to XX? I'd be more inclined to go
> the other way and say that you can transform any list infix form to
> the corresponding function form:
>
> @a ZZ @b ZZ @c -> zip operator
> ZZ(@a; @b; @c) -> zip function
>
> @a XX @b XX @c -> cross operator
> XX(@a; @b; @c) -> cross function
>
> @a X*X @b X*X @c -> cross product operator
> X*X(@a; @b; @c) -> cross product function
>
> @a MM @b MM @c -> minmax operator
> MM(@a; @b; @c) -> minmax function
>
>
>
>
Maybe you could use DD instead (for dot product).
Joe Gottman
Damian Conway
> I'd be more inclined to go
> the other way and say that you can transform any list infix form to
> the corresponding function form:
>
> @a ZZ @b ZZ @c -> zip operator
> ZZ(@a; @b; @c) -> zip function
>
> @a XX @b XX @c -> cross operator
> XX(@a; @b; @c) -> cross function
>
> @a X*X @b X*X @c -> cross product operator
> X*X(@a; @b; @c) -> cross product function
>
> @a MM @b MM @c -> minmax operator
> MM(@a; @b; @c) -> minmax function
I'm not strongly opposed to this, unless they're the *only* forms of
the functions. If the very much more readable 'zip' and 'minmax' are
to be replaced with 'ZZ' and 'MM', then I think that's a serious step
backwards in usability.
Damian
Damian Conway
> [Off-list]
Apparently not.
Just pretend I'm not here.
;-)
Damian
Larry Wall
Oh, sorry, I mean "cross product" in the literal cross-multiply sense,
not in the mathematical sense of dot product. But yeah, this would
also a way for mathematicians to add similar vector operators in a
somewhat consistent naming style. 'Course, if they're going to go
to that extreme they'll probably just use ⋅ or some such.
Larry
Jonathan Lang
> > I'd be more inclined to go
> > the other way and say that you can transform any list infix form to
> > the corresponding function form:
> >
> > @a ZZ @b ZZ @c -> zip operator
> > ZZ(@a; @b; @c) -> zip function
> >
> > @a XX @b XX @c -> cross operator
> > XX(@a; @b; @c) -> cross function
> >
> > @a X*X @b X*X @c -> cross product operator
> > X*X(@a; @b; @c) -> cross product function
> >
> > @a MM @b MM @c -> minmax operator
> > MM(@a; @b; @c) -> minmax function
Can't you already do this, with square braces?
@a XX @b XX @c
[XX] (@a; @b; @c)
etc? Or am I missing something about the reduction metaoperator?
> I'm not strongly opposed to this, unless they're the *only* forms of
> the functions. If the very much more readable 'zip' and 'minmax' are
> to be replaced with 'ZZ' and 'MM', then I think that's a serious step
> backwards in usability.
Hear, hear. I very much prefer 'zip' and 'minmax' to 'ZZ' and 'MM'.
--
Jonathan "Dataweaver" Lang
Jesse Vincent
On Feb 20, 2007, at 3:42 PM, Larry Wall wrote:
> I think the ¥ and Y operators are going to have to change to
> something else.
> The current Y has at least four strikes against it:
>
> * It's an ASCII version of a cute Unicode picture, but other
> than that,
> the picture it doesn't remind you of "zip" at all, especially in
> the Y form.
I bet calling it "ykk" would be Wrong. Pity.
-jesse
Thomas Wittek
> If the very much more readable 'zip' and 'minmax' are
> to be replaced with 'ZZ' and 'MM', then I think that's a serious step
> backwards in usability.
Fully agree here and I think that there are still even more places,
where the usability could be improved:
Say more words/letters, less symbols/special characters.
Especially special characters (shift + num: !@#$%^&*...) are harder to
type (I think I can type a 5-char word a lot faster than shift-5 = % -
additionally the shift-wrench disturbs the typing flow) and above all
harder to read/intuitively understand/learn/remeber than plaintext keywords.
Of course there will always be a trade-off and special characters are
the most usable choice in many cases. But I also think that in many
other cases "words" will be more usable.
As the usability of a tool greatly influences it's acceptance and usage,
this is a point, where we really should think about.
Luke Palmer
> Damian Conway schrieb:
> > If the very much more readable 'zip' and 'minmax' are
> > to be replaced with 'ZZ' and 'MM', then I think that's a serious step
> > backwards in usability.
>
> Fully agree here and I think that there are still even more places,
> where the usability could be improved:
> Say more words/letters, less symbols/special characters.
> Especially special characters (shift + num: !@#$%^&*...) are harder to
> type (I think I can type a 5-char word a lot faster than shift-5 = % -
> additionally the shift-wrench disturbs the typing flow) and above all
> harder to read/intuitively understand/learn/remeber than plaintext keywords.
Well, (IMO, of couse, but I can defend it!) typability is not nearly
as important as readability. And not Java readability, where you can
right-click on anything and read the documentation, but readability
where, after sufficient orientation, you can look at most and not need
any documentation; i.e. it is completely obvious what it is doing.
Many times this can not be done simply by naming appropriately,
although I admit Perl often takes this too far.
> Of course there will always be a trade-off and special characters are
> the most usable choice in many cases. But I also think that in many
> other cases "words" will be more usable.
% as the "mod" operator is a good example of what you describe.
There's no need for mod to be a symbolic operator: when you read 5 % 3
you say "5 mod 3". Why would we not write "5 mod 3": it is just as
obvious what and how we are doing this operation. And % is uncommon
enough that no huffman coding principals may apply. The only thing we
have here is cultural baggage.
As a good example of what I am referring to is hyper operators.
Naming hyper operators would ultimately be detremental to readability
among experienced programmers. Consider the difference between:
my @data = @reading >>+<< @bias; # old hyper syntax; I don't
know the new form yet
my @data = hyper &infix:<+>, @reading, @bias;
In which one of these is it more obvious what is going on? Now, if
you're a beginner, neither may be totally obvious, but the first makes
you think of addition, and the second makes you think of function
references.
> As the usability of a tool greatly influences it's acceptance and usage,
> this is a point, where we really should think about.
I completely agree. I am for operator-centric languages. As a
mathematician and a human, I think an operator-centric language maps
very closely to my brain, as opposed to a name-centric language (for
some reason, I'm not sure why, but as an experienced perl and ruby
programmer, perl just "flows" better). But I do think that Perl 6 is
gathering some operator bloat, in that we are defining symbols for
things that are not adding to the "obviousness" of the code. They may
not be taking away, but all else being equal, we should choose the
option of lower abstraction (as far as what level the user needs to be
in order to understand what is *really* going on, for some definiton
of "really").
Luke
Mark A. Biggar
It's madness, MADNESS I tell you!
Beware: this way leads to PERLBOL! :-)
Jonathan Lang
> % as the "mod" operator is a good example of what you describe.
> There's no need for mod to be a symbolic operator: when you read 5 % 3
> you say "5 mod 3". Why would we not write "5 mod 3": it is just as
> obvious what and how we are doing this operation. And % is uncommon
> enough that no huffman coding principals may apply. The only thing we
> have here is cultural baggage.
I can think of one case where % would be preferable to 'mod': when you
want to ask for a 'remainder' in the form of a non-integer. That is,
'4.5 % 3' returns 1.5 (and parallels '/'), while '4.5 mod 3' returns 1
(and parallels 'div'). That said, if it's decided that the latter
definition is inappropriate or unnecessary, then I'd be all in favor
of completely dropping '%' in favor of 'mod' for the former
definition.
> But I do think that Perl 6 is
> gathering some operator bloat, in that we are defining symbols for
> things that are not adding to the "obviousness" of the code. They may
> not be taking away, but all else being equal, we should choose the
> option of lower abstraction
Hear, hear. Huffman coding is all well and good; but not when taken
to the point that it starts interfering with legibility. That said,
six-character words are the longest that I'd want to see, and I'd much
prefer three- or four-character words if reasonable.
Mind you, there are some cases where I'd like to see the symbol-based
operators supplemented by name-based ones instead of being replaced by
them. For instance, I could live with a few more word-based
contextualizers: 'scalar' (same as '$:'), 'hash' (same as '%:'), and
'nested' (same as '@@:'); but I wouldn't want to remove '$:', '%:', or
'@@:'. The only reason I don't also suggest 'sub' to supplement '&:'
is the confusion that could arise between contextualization and
declaration.
--
Jonathan "Dataweaver" Lang
Uri Guttman
DC> On 21/02/07, Damian Conway <dam...@conway.org> wrote:
>> [Off-list]
DC> Apparently not.
DC> Just pretend I'm not here.
DC> ;-)
we can't pretend as we can sense your mad scientist brain across the big
waters. there ain't enough aluminum foil to protect us all! :)
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org