Re: Y not
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: [EMAIL PROTECTED]*...) 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. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Y not
On 2/21/07, Thomas Wittek [EMAIL PROTECTED] wrote: 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: [EMAIL PROTECTED]*...) 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
Re: Y not
Thomas Wittek wrote: 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: [EMAIL PROTECTED]*...) 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. It's madness, MADNESS I tell you! Beware: this way leads to PERLBOL! :-) -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Y not
DC == Damian Conway [EMAIL PROTECTED] writes: DC On 21/02/07, Damian Conway [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Y not
On Tuesday 20 February 2007 12:42, Larry Wall wrote: '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
Re: Y not
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? -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Y not
Thomas Wittek wrote:
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([EMAIL PROTECTED]) { ... }
could be called with
zip (@a; @b; @c)
or
@a zip @b zip @c
--
Jonathan Dataweaver Lang
Re: Y not
On Wed, Feb 21, 2007 at 12:49:20AM +0100, Thomas Wittek wrote: : 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
Re: Y not
Larry Wall wrote: 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 But the X*X already has a meaning: * under the cross metaoperator. Maybe you could use DD instead (for dot product). Joe Gottman
Re: Y not
On 21/02/07, Damian Conway [EMAIL PROTECTED] wrote: [Off-list] Apparently not. Just pretend I'm not here. ;-) Damian
Re: Y not
Damian Conway wrote: 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
Re: Y [was: Re: new sigil]
Speaking of which the advantage of, say, « over is that the former is _one_ charachter. But Y, compared to ¥, is one charachter only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the official one?!? Do you even need to ask? It's because it *looks cool* :) We need *more* of these. I can't wait until the day when I can finally code in overloaded Tagalog or Gujarati: http://www.iam.uni-bonn.de/~alt/html/unicode_23.html
Re: Y [was: Re: new sigil]
On Thu, 20 Oct 2005, Rutger Vos wrote: _one_ charachter. But Y, compared to ¥, is one charachter only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the official one?!? Do you even need to ask? It's because it *looks cool* :) Does it? Guillemets _do_ look kool, but I don't by the argument for the Yen symbol... Michele -- Is e+pi a rational or irrational number? Yes, it is. - Robert Israel in sci.math, Re: A Number Problem
Re: Y [was: Re: new sigil]
Speaking of which, the advantage of, say, « over is that the former is _one_ character. But Y, compared to ¥, is one character only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the official one?!? I can't speak for anyone else, but personally I prefer ¥ because I don't like infix operators that look like identifiers. It's idiosyncratic, admittedly, but I dislike Pascal's mod and Perl5's x for the same reason. Even with the ability to use Unicode names, ¥ can't be an identifier, because it's not a letter, it's a currency symbol. Now that we've opened up the Pandora's box of Unicode, we have lots more letters, but also lots more non-letters, and I'd rather see the latter used for operators. Just my 2¢. :)
