Re: Y not
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 PGP.sig Description: This is a digitally signed message part
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]
Y not
Luke Palmer wrote: % 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
[svn:perl6-synopsis] r13699 - doc/trunk/design/syn
Author: larry
Date: Wed Feb 21 09:25:37 2007
New Revision: 13699
Modified:
doc/trunk/design/syn/S03.pod
Log:
¥ is replaced by Z. XX becomes simply X and old X must now be spelled X~X.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podWed Feb 21 09:25:37 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 8 Feb 2007
+ Last Modified: 21 Feb 2007
Number: 3
- Version: 100
+ Version: 101
=head1 Overview
@@ -46,7 +46,7 @@
Item assignment = := ::= => += -= **= xx= .=
Loose unary true not
Comma operator ,
-List infix ¥ minmax X XX X~X X*X XeqvX
+List infix Z minmax X X~X X*X XeqvX
List prefix = : print push say die map substr ... [+] [*] any all
Loose and and
Loose oror xor err
@@ -1069,13 +1069,13 @@
=item *
-infix:<¥>, the zip operator
+infix:, the zip operator
-1,2 ¥ 3,4 # (1,3),(2,4)
+1,2 Z 3,4 # (1,3),(2,4)
=item *
-The minmax operator
+infix:, the minmax operator
$min0, $max0 minmax $min1, $max1# ($min0 min $min1, $max0 max $max1)
@@ -1094,30 +1094,19 @@
=item *
-List and string cross operators
+infix:, the cross operator
-1,2 XX 3,4 # (1,3), (1,4), (2,3), (2,4)
-1,2 X 3,4 # '13', '14', '23', '24'
+1,2 X 3,4 # (1,3), (1,4), (2,3), (2,4)
-In contrast to the zip operator, the C operator returns all the
+In contrast to the zip operator, the C operator returns all the
permutations of its sublists. Hence you may say:
- XX <1 2>
+ X <1 2>
and you end up with
('a', '1'), ('a', '2'), ('b', '1'), ('b', '2')
-The C variant crosses the arrays but concatenates strings:
-
- X <1 2>
-
-produces
-
-'a1', 'a2', 'b1', 'b2'
-
-The resemblance to C and C is not entirely accidental.
-
=item *
Cross hyperoperators
@@ -1234,14 +1223,14 @@
precedence on the right sufficiently to govern list infix
operators:
- $: 1,2 ¥ 3,4 # [[1,3],[2,4]]
- @: 1,2 ¥ 3,4 # 1,3,2,4
-@@: 1,2 ¥ 3,4 # [1,3],[2,4]
- %: 1,2 ¥ 3,4 # { 1 => 3, 2 => 4 }
-
- $: 1,2 XX 3,4 # [[1,3],[1,4],[2,3],[2,4]]
- @: 1,2 XX 3,4 # 1,3,1,4,2,3,2,4
-@@: 1,2 XX 3,4 # [1,3],[1,4],[2,3],[2,4]
+ $: 1,2 Z 3,4 # [[1,3],[2,4]]
+ @: 1,2 Z 3,4 # 1,3,2,4
+@@: 1,2 Z 3,4 # [1,3],[2,4]
+ %: 1,2 Z 3,4 # { 1 => 3, 2 => 4 }
+
+ $: 1,2 X 3,4 # [[1,3],[1,4],[2,3],[2,4]]
+ @: 1,2 X 3,4 # 1,3,1,4,2,3,2,4
+@@: 1,2 X 3,4 # [1,3],[1,4],[2,3],[2,4]
These can also influence the result of functions that returns lists of
captures:
@@ -2892,7 +2881,7 @@
[//]() # undef
[=]() # undef(same for all assignment operators)
[,]() # []
-[¥]() # []
+[Z]() # []
User-defined operators may define their own identity values, but
there is no explicit identity property. The value is implicit in the
@@ -2998,17 +2987,17 @@
produces
-['a', 1, 'x'],
-['a', 1, 'y'],
-['a', 2, 'x'],
-['a', 2, 'y'],
-['b', 1, 'x'],
-['b', 1, 'y'],
-['b', 2, 'x'],
-['b', 2, 'y']
+('a', 1, 'x'),
+('a', 1, 'y'),
+('a', 2, 'x'),
+('a', 2, 'y'),
+('b', 1, 'x'),
+('b', 1, 'y'),
+('b', 2, 'x'),
+('b', 2, 'y')
-The string and list forms are common enough to have shortcuts, C
-and C respectively. See below.
+The list form is common enough to have a shortcut, C.
+See below.
For the general form, any existing, non-mutating infix operator
may be used.
@@ -3280,8 +3269,7 @@
print "Name: $name; Zip code: $zip\n";
}
-C has an infix synonym, the Unicode operator C<¥>, and its ASCII
-equivalent C.
+C has an infix synonym, the C operator.
To read arrays in parallel like C but just sequence the values
rather than generating tuples, use C instead of C.
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
Relief for rw/ro
Recently $larry asked for ideas for better naming
the several states of write access.
There are some tentative thoughts, I like to offer.
Larry Wall wrote:
> That being said, in writing the Perl 6 grammar I keep running into the
> need for rw context variables. I'm getting tired of writing things
> like:
>
> my @heredoc_stubs is context is rw = ()
>
> so maybe there's some general syntactic relief for rw/ro that is
> orthogonal to everything else. But that means it wouldn't be a
> trait, a type, a sigil, or a twigil, if it's really orthogonal.
> I don't just want to go with bare rw and ro markers because I think
> they're too easy to confuse. It's more like we want an initializer
> that says "lock this after I change it". If used on the initializer
> of a declaration it would have the force of a readonly declaration.
> Some variant on or near the =, in other words, that could also be
> a variant on normal assignment. But maybe it also has to
> stand alone to declare it as a "write once" variable, I expect.
> Currently "is readonly" only works on the declaration, and only on
> items that are initialized by the declaration. Maybe that's good
> enough for most purposes.
My approach is:
In terms of writeability a variable/reference can be
(1) a variable, (2) a constant or (3) a "final"
(Don't wonder if you never heard of that "final", just my proposal)
That means it can be writeable (1),
not writeable since compile time (2) or
not writeable since that moment in runtime when it gets "final" (3).
This approach could work with an optional second declarator.
In the usual case the second declarator, that would be 'variable',
is simply omitted and nobody feels a difference.
- snip
my $number = 3; # OK, of course
my variable $number = 3; # The same, not really useful, -> warning?
# context variables default to readonly,
# so the 'variable' declaration has an effect
my variable @heredoc_stubs is context = (); # Writeable context!
# Compile time constant with local scope:
my constant $pi = 3.14;
# Package scoped constants can be useful!
say $Math::euler; # Prints constant value from package Math
# This data from database has to be 'readonly':
my final $temperature = db_temperature_of( $date_time_loc);
# But this is possible as well:
my $temperature = db_temperature_of( $date_time_loc);
if is_fine($temperature) {
final $temperature;
}
else {
$temperature = db_default_temperature();
final $temperature;
}
- /snip
I think this approach is quite expressive, readable and orthogonal
to everything else. In particular it is orthogonal to the scope.
Whenever you see the 'variable' declarator, you should think:
Attention, it is really variable.
With the "final" declarator you can lock a variable at
initialization and with the "final" build-in multi sub, you can
lock it at any time.
There may be better words than "final". I just thought, it matches
the meaning to some extend, its short and it can be used as a
verb and as a noun.
The approach is even extensible. I could imagine an otional
declarator for predeclared variables that requires that this
variables will really become defined.
Kind Regards
Stefan
-
Need a quick answer? Get one in minutes from people who know. Ask your question
on Yahoo! Answers.
