[RFC] Perl6 Operator List, Take 5
Michael Lazzaro
Larry's latest inputs. ^ means xor again, and a few things have been
removed. Comments?
Note that I will next post a list of hyperoperators _separately_.
If the design team could take a look, esp. at the remaining questions,
in order to [APPROVE] a "final" list, that'd be wonderful. We'll then
get to work on reconstructing the operator precedence table that
started this monster thread and, hopefully, we can [APPROVE] that in
short order as well, and be done with it. (optimist optimist optimist
optimist...)
hyperoperators:
[op] - as prefix to any unary/binary operator, "vectorizes" the
operator
(is whitespace allowed inside the brackets, e.g. [ + ] vs. [+] ?)
unary (prefix) operators:
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not - force to bool context, negate
+ - force to numeric context
- - force to numeric context, negate
+^ - force to numeric context, complement
~ - force to string context
~^ - force to string context, complement
. - method call on current topic
++ - preincrement
-- - predecrement
unary (postfix) operators:
++ - postincrement
-- - postdecrement
... - [maybe] same as ..Inf [Damian votes Yes]
other postfix operators:
() - (when operator is expected)
[] - array access
{} - hash access
binary operators:
(do more of these have possible +~? prefix modifiers,
or only the boolean &|^ ops?)
+ - * / % ** x xx ~ - arithmetic
+= -= *= /= %= **= x= xx= ~=
< > <= >= == != <=> - comparision
lt gt le ge eq ne cmp
&& || ^^ // - boolean operations
&&= ||= ^^= //=
and or xor err
.& .| .^ << >> - bitwise (integer)
operations
.&= .|= .^= <<= >>=
~& ~| ~^ - charwise (string) operations
~&= ~|= ~^=
?& ?| ?^ - [maybe] C-like bool operations
?&= ?|= ?^= - (result is always just 1 or 0)
& | ^ - superpositional operations
&= |= ^= - conjunctive, disjunctive, exclusive
all any one none - conj, disj, excl, dismissive
sum prod cat reduce - [maybe]
~~ !~ - smart match, smart non-match
like unlike - [maybe] [Damian votes No]
=> - pair creator
, - list creator
; - "greater comma", list-of-lists creator
: - adverbial
. - method call
.. - range
... - [maybe] range, exclusive of endpoint [Damian votes No]
= - assignment
:= - binding
::= - binding, but more so
trinary operator:
?? :: - if/else
parens, misc, and quotelike operators
()
[] - [when term is expected]
{} - [when term is expected]
m// - shorthand, "matches"
s/// - shorthand, "substitute"
tr/// - shorthand, "transliterate"
'...' "..." `...` /.../ << >>
q qq qx rx qw [qm?]
[+ qr ?]
<...> - readline
(heredocs) - [exact format unknown]
named unary (prefix) operators, terms, and other important assorteds,
identified
when possible:
-X [-X] - [op] filetest operators
ref [ref] - [op]
exists [exists] - [op]
delete [delete] - [op]
defined [defined] - [op]
undef [undef] - [op]
undef - [term]
temp ? - [op]
let ? - [op]
but ? - [op] val properties
${ } - [deref] dereference scalarref
@{ } - [deref]
%{ } - [deref]
&{ } - [deref]
... - [term] yada**3
Inf - [term]
Nan - [term]
is - [declar] var properties
-> - [declar] like 'sub'
hash - [declar] force hash context
--- taken out, for now ----
magical whitespace modifier
_ - [maybe] remove whitespace/newline
(briefly discussed, but not an operator?)
explicit radix specifications for integers:
(we'll just handle this issue separately, OK?)
other uncategorized:
(no decisions are implied about these, e.g. are they
ops, listops, methods, whatever... decide later)
my our - [declar]
map grep
sqrt log sin cos tan (etc...) - math
lc lcfirst uc ucfirst
int ord oct hex bin
MikeL
Larry Wall
: (is whitespace allowed inside the brackets, e.g. [ + ] vs. [+] ?)
I don't think so.
: unary (prefix) operators:
: . - method call on current topic
I think we have to have unary .= as well, if we're to do the
.=replace
trick on $_.
: unary (postfix) operators:
: ... - [maybe] same as ..Inf [Damian votes Yes]
I wonder if we can possibly get the Rubyesque leaving out of
endpoints by saying something like 1..!10.
: other postfix operators:
:
: () - (when operator is expected)
: [] - array access
: {} - hash access
These now consistently require no space, and they're all
when an operator is expected, not just ().
: binary operators:
:
: (do more of these have possible +~? prefix modifiers,
: or only the boolean &|^ ops?)
Well, things like < already imply numeric, and things like lt already
imply string. The booleans are already officially polymorphic.
: + - * / % ** x xx ~ - arithmetic
: += -= *= /= %= **= x= xx= ~=
I don't think of x or ~ as arithmetic exactly...
: .& .| .^ << >> - bitwise (integer)
: operations
: .&= .|= .^= <<= >>=
These should be +& etc.
: sum prod cat reduce - [maybe]
That's Apocalypse 29. :-)
: ~~ !~ - smart match, smart non-match
: like unlike - [maybe] [Damian votes No]
Undecided.
: .. - range
: ... - [maybe] range, exclusive of endpoint [Damian votes No]
Still thinking about ..! or ..^ or some such. Could have ^..^ and ^..
too, for all that.
: ::= - binding, but more so
Cute, but nonexplanatory. Binding at compile time.
: trinary operator:
:
: ?? :: - if/else
:
: parens, misc, and quotelike operators
: ()
: [] - [when term is expected]
: {} - [when term is expected]
Again, all of these are when a term is expected, not just the latter two.
: m// - shorthand, "matches"
: s/// - shorthand, "substitute"
: tr/// - shorthand, "transliterate"
:
: '...' "..." `...` /.../ << >>
: q qq qx rx qw [qm?]
: [+ qr ?]
No, the qr is dead. Long live the rx.
: <...> - readline
Iterate interator.
: (heredocs) - [exact format unknown]
Probably still the same, at least until we start thinking about it...
: magical whitespace modifier
: _ - [maybe] remove whitespace/newline
: (briefly discussed, but not an operator?)
We need something here. Underline is available.
: explicit radix specifications for integers:
: (we'll just handle this issue separately, OK?)
Fine. I'm not sure we actually have to change anything here from Perl 5.
Syntactic mangling could easily work for anyone who wants base 42.
: other uncategorized:
: (no decisions are implied about these, e.g. are they
: ops, listops, methods, whatever... decide later)
:
: my our - [declar]
: map grep
: sqrt log sin cos tan (etc...) - math
: lc lcfirst uc ucfirst
: int ord oct hex bin
oct and hex are arguably backwards, typewise. They don't produce
octal or hex types, but rather consume them.
Larry
David Whipp
> : unary (postfix) operators:
> : ... - [maybe] same as ..Inf [Damian votes Yes]
>
> I wonder if we can possibly get the Rubyesque leaving out of
> endpoints by saying something like 1..!10.
Perhaps we could use the less-than symbol: 1 ..< 10
Similarly: 1 >..< 10 == 2..9
Dave.
Larry Wall
That front one is backwards--it would have to be 1 <..< 10.
But the biggest problem is that 1..<$iterator> is valid syntax.
Of course, ..! and ..^ have the same problem. But it just seems like
it's really unlikely that someone would use a unary ! or ^ on the
endpoint term. So with 1..!$x or 1..^$x it's likely to be right if
we guess (per the longest token rule) that the operator is ..! or ..^.
The same can't be said of ..<, alas. But at least it might produce
a syntax error when it tries to parse the >. Or no, it wouldn't
necessarily. This parses:
1..<$iterator> + 1;
but wrongly as
1 ..< $iterator > +1;
Ick.
Of course, Real Mathematicians will want [1..10) and (1..10] instead.
Double ick.
I kind like ..^ the best because ^ is currently read "exclusive of"
anyway, sort of...
And the arrow can be read "up to", at least on that end of it. I think
that ..^ is going to be much, much more common than ^.. will be.
There's also an issue of what (1..10) - 1 would or should mean, if anything.
Does it mean (1..9)? Does 1 + (1..10) mean (2..10)?
And what would ('a' .. 'z') - 1 mean?
I think I'd better go to bed now...
Larry
Me
> : > endpoints by saying something like 1..!10.
> :
> There's also an issue of what (1..10) - 1 would or should
> mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
> mean (2..10)?
>
> And what would ('a' .. 'z') - 1 mean?
1..10-1 # 1..9
1+1..--10 # 2..9
'a'..'z'-- # a - y
?
--
ralph
PS. [op] is such a sweet improvement. the [op=] vs [op]=
trick that then became possible, the move of ^ back to its
previous meaning, is nice icing.
Brent Dax
# Of course, Real Mathematicians will want [1..10) and (1..10] instead.
#
# Double ick.
Reminds me of the number-line notation you learn about *before*
precalculus (or whatever the value of
$you.schooling.grade[12].class{math}.name is) confuses everything, with
open vs. closed circles on a number line. How about:
1 oo 10 # (1, 10)
1 o. 10 # (1, 10]
1 .o 10 # [1, 10)
1 .. 10 # [1, 10]
(The scary part is that I'm not sure I'm joking any more...)
# There's also an issue of what (1..10) - 1 would or should
# mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
# mean (2..10)?
#
# And what would ('a' .. 'z') - 1 mean?
Er, I would hope that it would be the same as scalar('a' .. 'z') - 1, or
['a' .. 'z'] - 1, or +['a' .. 'z'] - 1, or 26 - 1, or 25. But that
wouldn't be weird enough, I suppose--it's looking like Perl 6 will be
the official language of *The Matrix*. Free your mind! :^)
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Michael Lazzaro
> Larry Wall:
> # There's also an issue of what (1..10) - 1 would or should
> # mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
Actually, I would at first glance think, based on the parens, that:
(1..10)-1
means
((1-1)..(10-1))
means
(0..9)
.... and if someone has been playing a lot with the superposition stuff,
that is probably what they would indeed expect. That's also a valuable
interpretation, since it means you can say things like
(1..$n) * 10
And get a list (10,20,...) without having to change $n.
However, by the same logic,
@array * 10
means
@array [*] 10
which it doesn't. So maybe the correct interpretation of the above is
indeed this:
(1..10)-1 # (1..10).length-1, e.g. 9 (oops!)
(1..10) [-] 1 # (0..9) (correct, if that's WYM)
meaning that (1..10)-1 almost always does The Wrong Thing(!)
MikeL
Michael Lazzaro
> : ... - [maybe] range, exclusive of endpoint [Damian votes No]
>
OK, I just gotta say, that's _d*mn_ clever. "Exclusive of endpoint" --
It looks like what it is, and vice versa. I guess that's why you're our
fearless leader. :-)
I'll revise according to the notes, do some cleanup, and repost the
single, re-condensed list.
I also want to say again, for the record, I'm *really* looking forward
to programming in this. It's going to be FUN. Bwah-ha-ha!
MikeL
Graham Barr
> unary (prefix) operators:
>
> \ - reference to
> * - list flattening
> ? - force to bool context
> ! - force to bool context, negate
> not - force to bool context, negate
> + - force to numeric context
> - - force to numeric context, negate
> +^ - force to numeric context, complement
> ~ - force to string context
> ~^ - force to string context, complement
Noe that we have gained ^ back from being a hyeroperator, could we not
have ^ as a polymorphic complement operator. It can always be combined
with ~ or + to force context, eg
$a = ^ +$b;
$a = ^ ~$b;
We would then have a complement operator that I would assume objects could
overload and do whatever they liked with.
Graham.
Simon Cozens
> Still thinking about ..! or ..^ or some such. Could have ^..^ and ^..
> too, for all that.
We could indeed have a whole range of Japanese smiley operators.
--
A year spent in artificial intelligence is enough to make one believe in God.
Angel Faus
>
> : <...> - readline
>
> Iterate interator.
>
Couldn't we go the python way and assume that <..> is implicit in
"for" statments:
$fh = open(..);
for $fh { # instead of for <$fh>
print $_;
}
For explicit iteration, we could well do just with a ".next" method:
while ($line = $fh.next) {
print $line;
}
And the old perl construct:
while (<>) {
print $_
};
Could be replaced with a open() without arguments, such as:
for open() {
print $_;
}
And then <..> could go back to being a gentler replacement of qw<..>.
Or is there any problem that my blind eyes can't see?
-angel
Jonathan Scott Duff
> So maybe the correct interpretation of the above is indeed this:
>
> (1..10)-1 # (1..10).length-1, e.g. 9 (oops!)
Do "range objects" return their length in scalar context?
> (1..10) [-] 1 # (0..9) (correct, if that's WYM)
That's how I would write it if that's what I meant.
> meaning that (1..10)-1 almost always does The Wrong Thing(!)
Indeed.
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Jonathan Scott Duff
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
> hyperoperators:
>
> [op] - as prefix to any unary/binary operator, "vectorizes" the
> operator
> . - method call on current topic
What would [.]method() mean?
> < > <= >= == != <=> - comparision
> lt gt le ge eq ne cmp
What do these do?
if $a [<] @b { ... } # if $a < all(*@b) ???
if @a [<] @b { ... } # if $a[0] < all(*@b) &&
# $a[1] < all(*@b) &&
# $a[2] < all(*@b) && ... ???
> & | ^ - superpositional operations
$a [&] @b # all($a,*@b) ???
@a [&] @b # all(*@a,*@b) ???
> => - pair creator
%hash = (@a [=>] @b); # %hash{@a} = @b; ???
%hash = (@a [=>] $b); # %hash{@a} = ($b) x @a; ???
> , - list creator
@a = ($b [,] @c); # @a = ($b, *@c); ???
> ; - "greater comma", list-of-lists creator
> : - adverbial
I'm not even sure how to hyper these two. I guess if I had an array
of "range objects" I could hyper ;
Would this write to several filehandles?
print @file_handles [:] "fooey!\n";
> .. - range
And this is the one that made me start thinking about hypering the
others
@a = @b[..]@c # @a = ($b[0]..$c[0], $b[1]..$c[1], ...) ???
@a = $b[..]@c # @a = ($b..$c[0], $b..$c[1], ...) ???
@a = @b[..]$c # @a = ($b[0]..$c, $b[1]..$c, ...) ???
I know that this stuff probably seems obvious to everyone, but I'd
rather have it explicit just in case :-)
Austin Hastings
--- Jonathan Scott Duff <du...@cbi.tamucc.edu> wrote:
> Maybe we've gone over this before but, if so, I don't remember ...
>
> On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
> > hyperoperators:
> >
> > [op] - as prefix to any unary/binary operator, "vectorizes" the
>
> > operator
>
> > . - method call on current topic
>
> What would [.]method() mean?
@a = @b[.]method(); # Sets each @a[x] to @b[x].method()
Thinking out loud ...
@a = @b[.method()]; # Sets @a to the value stored in @b indexed by
# current context.method()
>
> > < > <= >= == != <=> - comparision
> > lt gt le ge eq ne cmp
>
> What do these do?
>
> if $a [<] @b { ... } # if $a < all(*@b)
Credible.
> if @a [<] @b { ... } # if $a[0] < all(*@b) &&
> # $a[1] < all(*@b) &&
> # $a[2] < all(*@b)
My inclination here is that $a[0] < $b[0] && $a[1] < $b[1] ...
> $a [&] @b # all($a,*@b) ???
Questionable. Perhaps an array s.t. @result[x] = $a & @b[x] ?
On the other hand, I like the idea of being able to distribute an
operator using this syntax...
@a = @b op $c
versus
?? = @b [op] $c
What's the difference? One maybe produces @b[x] op $c while the other
produces -> { $result = $c; for @b -> $b { $c op= $b; } }
But then it's not legal any more in array context unless @b is a LoL.
Erk!
> @a [&] @b # all(*@a,*@b) ???
Array s.t. @result[x] = @a[x] & @b[x]
> @a = ($b [,] @c); # @a = ($b, *@c); ???
LoL: @a[x] = ($b, @c[x])
> I'm not even sure how to hyper these two. I guess if I had an array
> of "range objects" I could hyper ;
Hypersemi is probably just the same as hypercomma, since the
circumlocutions needed to use it are such that you'll probably specify
the construction clearly.
But if not:
@a = @b [;] @c --> @a[x] = ((@b[x]) ; (@c[x]))
> Would this write to several filehandles?
>
> print @file_handles [:] "fooey!\n";
>
> > .. - range
>
> And this is the one that made me start thinking about hypering the
> others
>
> @a = @b[..]@c # @a = ($b[0]..$c[0], $b[1]..$c[1], ...) ???
> @a = $b[..]@c # @a = ($b..$c[0], $b..$c[1], ...) ???
> @a = @b[..]$c # @a = ($b[0]..$c, $b[1]..$c, ...) ???
>
You, too? Range was the first thing I started trying to hyper.
> I know that this stuff probably seems obvious to everyone, but I'd
> rather have it explicit just in case :-)
if $x == any(@b[..]@c)
print "In one of the ranges...\n";
or
if $x ~~ any(@b[..]@c)
print "In one of the ranges...\n";
Does .. create an implicit flexpr in numeric context, or does it
require smartmatch?
=Austin
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
Brent Dax
an operator would be, I use this:
***BEGIN CODE***
{
use strict;
use warnings;
sub _is_arrayref { ref $_[0] && ref $_[0] eq 'ARRAY' }
sub hyper(&\@\@) {
my($code, $a, $b)=@_;
my @results;
if(_is_arrayref($a)) {
if(_is_arrayref($b)) {
my $alen=$#{$a};
my $blen=$#{$b};
my $maxlen=$alen;
if($alen > $blen) {
for($blen + 1 .. $alen) {
$b->[$_]='';
}
}
elsif($blen > $alen) {
for($alen + 1 .. $blen) {
$a->[$_]='';
}
$maxlen=$blen;
}
for(0..$maxlen) {
push @results, &vector($code, $a->[$_] ,
$b->[$_]);
}
if($alen > $blen) {
$#{$b}=$blen;
}
elsif($blen > $alen) {
$#{$a}=$alen;
}
}
else {
for(@$a) {
push @results, &vector($code, $_, $b);
}
}
}
elsif(_is_arrayref($b)) {
for(@$b) {
push @results, &vector($code, $a, $_);
}
}
else {
no strict 'refs';
no warnings 'once';
local *{caller().'::a'}=\$a;
local *{caller().'::b'}=\$b;
return $code->();
}
return @results;
}
}
my @a=qw(1 2 3); my @b=([qw(4 5 6)], [qw(7 8 9)], [qw(10 11 12)]);
print join ' ', hyper { $a + $b } @a, @b;
***END CODE***
With that in mind...
Jonathan Scott Duff:
# What would [.]method() mean?
Presumably, @foo[.]method() would call .method on each object.
# > < > <= >= == != <=> - comparision
# > lt gt le ge eq ne cmp
#
# What do these do?
#
# if $a [<] @b { ... } # if $a < all(*@b)
# ???
# if @a [<] @b { ... } # if $a[0] < all(*@b) &&
# # $a[1] < all(*@b) &&
# # $a[2] < all(*@b)
# && ... ???
Create a list of the results. For example:
@a=qw(1 2 3);
@b=qw(3 2 1);
print join ' ', hyper { $a < $b } @a, @b;
#prints 1 0 0
# > & | ^ - superpositional operations
#
# $a [&] @b # all($a,*@b) ???
# @a [&] @b # all(*@a,*@b) ???
#
# > => - pair creator
#
# %hash = (@a [=>] @b); # %hash{@a} = @b; ???
# %hash = (@a [=>] $b); # %hash{@a} = ($b) x
# @a; ???
I think that's correct. Actually, that's a really useful behavior...
# > , - list creator
#
# @a = ($b [,] @c); # @a = ($b, *@c); ???
#
# > ; - "greater comma", list-of-lists creator
# > : - adverbial
#
# I'm not even sure how to hyper these two. I guess if I had
# an array of "range objects" I could hyper ;
Aren't these more syntax than operator?
# Would this write to several filehandles?
#
# print @file_handles [:] "fooey!\n";
Perhaps.
# > .. - range
#
# And this is the one that made me start thinking about
# hypering the others
#
# @a = @b[..]@c # @a = ($b[0]..$c[0], $b[1]..$c[1], ...) ???
# @a = $b[..]@c # @a = ($b..$c[0], $b..$c[1], ...) ???
# @a = @b[..]$c # @a = ($b[0]..$c, $b[1]..$c, ...) ???
That's a really good one. My naive implementation gives this:
1 2 3 4 1 2 3 4 5 1 2 3 4 5 6 2 3 4 5 6 7 2 3 4 5 6 7 8 2 3 4 5 6 7 8 9
3 4 5 6 7 8 9 10 3 4 5 6 7 8 9 10 11 3 4 5 6 7 8 9 10 11 12
Perhaps that would be:
[1 2 3 4] [1 2 3 4 5] [1 2 3 4 5 6] [2 3 4 5 6 7 8] [2 3 4 5 6 7 8 9] [3
4 5 6 7 8 9 10] [3 4 5 6 7 8 9 10 11] [3 4 5 6 7 8 9 10 11 12]
Jonathan Scott Duff
> --- Jonathan Scott Duff <du...@cbi.tamucc.edu> wrote:
> > Maybe we've gone over this before but, if so, I don't remember ...
> >
> > On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
> > > hyperoperators:
> > >
> > > [op] - as prefix to any unary/binary operator, "vectorizes" the
> >
> > > operator
> >
> > > . - method call on current topic
> >
> > What would [.]method() mean?
>
> @a = @b[.]method(); # Sets each @a[x] to @b[x].method()
No, no. I'm talking about the unary . prefix
method blah {
.foo()
[.]foo() # What does this mean?
}
> > if @a [<] @b { ... } # if $a[0] < all(*@b) &&
> > # $a[1] < all(*@b) &&
> > # $a[2] < all(*@b)
>
> My inclination here is that $a[0] < $b[0] && $a[1] < $b[1] ...
Oops, that's what I meant. I had originally written
if all(*@a) < all(*@b)
but then realized that the semantics would be all wrong.
Michael Lazzaro
> [.]foo() # What does this mean?
One could argue that several ways, depending on what's in the current
topic. It's the exact same thing as the binary form of dot, but with
the left side being implied, as 'the current topic':
topic is a scalar: hyperdot does nothing (scalar hyperop scalar ==
scalar op scalar)
topic is a listref: listref is automatically dereferenced, foo method
is called on all elements.
(In other words, I imagine calling a hyper on scalars is not an error
-- it just doesn't do anything more interesting than the normal op.)
Note you could also perhaps say something like
[.]$methodlist()
to mean "call each of these methods on (each of) the current topic(s)",
tho I'm not sure the syntax is accurate there.
MikeL
Austin Hastings
--- Jonathan Scott Duff <du...@cbi.tamucc.edu> wrote:
> On Wed, Oct 30, 2002 at 09:13:02AM -0800, Austin Hastings wrote:
> > --- Jonathan Scott Duff <du...@cbi.tamucc.edu> wrote:
> > > Maybe we've gone over this before but, if so, I don't remember
> ...
> > >
> > > On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
> > > > hyperoperators:
> > > >
> > > > [op] - as prefix to any unary/binary operator, "vectorizes"
> the
> > >
> > > > operator
> > >
> > > > . - method call on current topic
> > >
> > > What would [.]method() mean?
> >
> > @a = @b[.]method(); # Sets each @a[x] to @b[x].method()
>
> No, no. I'm talking about the unary . prefix
>
> method blah {
> .foo()
> [.]foo() # What does this mean?
> }
Vector of invocations of the foo methods of the current topic.
Presumably you'd have an array in topic, or you'd use it in an array
context.
for @lol -> @onelist {
@a = [.]foo();
}
=Austin
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Larry Wall
: > No, no. I'm talking about the unary . prefix
: >
: > method blah {
: > .foo()
: > [.]foo() # What does this mean?
: > }
:
: Vector of invocations of the foo methods of the current topic.
Except that the topic is by definition singular in a method, and so
is a method name. So it'd be no different from ordinary dot. Maybe
it's an error to use a vector op on two scalars.
: Presumably you'd have an array in topic, or you'd use it in an array
: context.
:
: for @lol -> @onelist {
: @a = [.]foo();
: }
Yes, that would work, though I'd love to see it:
for @lol -> @onelist {
@a = «.»foo();
}
instead. Maybe ^[+] (or whatever) is just a workaround for people
who can't figure out how to write «+». I love the "shimmers" on
either side of the operator. That's a nice plural visual metaphor.
I'd even be willing to give up «foo bar baz» meaning qw(foo bar baz)
for this.
Larry
Austin Hastings
--- Larry Wall <la...@wall.org> wrote:
> On Wed, 30 Oct 2002, Austin Hastings wrote:
> : > No, no. I'm talking about the unary . prefix
> : >
> : > method blah {
> : > .foo()
> : > [.]foo() # What does this mean?
> : > }
> :
> : Vector of invocations of the foo methods of the current topic.
>
> Except that the topic is by definition singular in a method, and so
> is a method name. So it'd be no different from ordinary dot. Maybe
> it's an error to use a vector op on two scalars.
method blah()
{
@values = [.]@list_of_methods(); # Are method pointers meaningful?
}
>
> : Presumably you'd have an array in topic, or you'd use it in an
> array
> : context.
> :
> : for @lol -> @onelist {
> : @a = [.]foo();
> : }
>
> Yes, that would work, though I'd love to see it:
>
> for @lol -> @onelist {
> @a = «.»foo();
> }
How do you write a « in a Windows based environment? (Other than by
copying them from Larry's emails or loading MSWord to do
insert->symbol)
> instead. Maybe ^[+] (or whatever) is just a workaround for people
> who can't figure out how to write «+». I love the "shimmers" on
> either side of the operator. That's a nice plural visual metaphor.
Yeah, "This looks kind of fuzzy. You probably don't clearly see what's
going on." Works for me.
> I'd even be willing to give up «foo bar baz» meaning qw(foo bar baz)
> for this.
Holy rat-on-a-stick, Batman! That IS quite a sacrifice...
Michael Lazzaro
On Wednesday, October 30, 2002, at 11:58 AM, Larry Wall wrote:
> I'd even be willing to give up ´foo bar bazª meaning qw(foo bar baz)
> for this.
I can't see that right (MacOSX Jaguar) in the email; to me it looks
like a forwardtick and an, um, underlined 'a' -- but in spite of that,
I'm game. It's just so pretty (when it works!)
On my Mac, it's spelled «op» -- can others see that correctly, or do we
have a sorry disconnect in the fonts, here, for us Mac folks?
MikeL
David Wheeler
> I can't see that right (MacOSX Jaguar) in the email; to me it looks
> like a forwardtick and an, um, underlined 'a' -- but in spite of that,
> I'm game. It's just so pretty (when it works!)
>
> On my Mac, it's spelled «op» -- can others see that correctly, or do
> we have a sorry disconnect in the fonts, here, for us Mac folks?
I use Mail.app, and saw the same thing you did. When I looked at the
headers for Larry's email, I saw:
Content-Type: text/plain; charset=UTF-8;
But when I saw yours, you had:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
This tells me that Mail.app, for some reason, didn't know that it was
supposed to use UTF-8 when showing Larry's mail. When I pasted his mail
into a UTF-8 document in Emacs, it looked fine.
Given that it's probably UTF-8 that Perl 6 source code is written in, I
think that you and I might be better off using a smarter mailer.
David
--
David Wheeler AIM: dwTheory
da...@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: The...@jabber.org
Mark J. Reed
> This tells me that Mail.app, for some reason, didn't know that it was
> supposed to use UTF-8 when showing Larry's mail. When I pasted his mail
> into a UTF-8 document in Emacs, it looked fine.
>
> Given that it's probably UTF-8 that Perl 6 source code is written in, I
> think that you and I might be better off using a smarter mailer.
>
> David
had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore.
My mailer understand UTF-8 just fine, and so does vim (which I used to
look at my spool file to check for encoding oddities); in my copy of his
message, there's just nothing there. All I can think is that some MTA
along the way - possibly our very own Exchange server - stripped them out.
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
fear...@figaro.weizmann.ac.il
Proposal : Vector operations for Hashes
%a ^{+} %b
the direct generalization would be as follows :
@a ^[op] @b
for @a ; @b ->
$x ; $y {
$x op $y
}
%a op %b
# find common keys
@k = keys hash{ map { { _=>1 } } *( %a.keys , %b.keys ) };
#return hash
hash {
for @k -> $x {
{ $x => %a{$x} op %b{$x} }
}
}
so in words , find coomon keys and then vectorize op as if
hash keys are array indexes.
Probably that behaviour may be tuned or conrolled by properties of
hashes just like what happens inside <regexes> .
maybe this could be made more general , since
Larry noted that junctions ( 1 | 2 | 3 ) are similar to hashes
> %hash = ( 1 | 2 | 3 ) ;
dont have any Idea how.
arcadi.
Larry Wall
: # find common keys
: @k = keys hash{ map { { _=>1 } } *( %a.keys , %b.keys ) };
It seems a bit odd to privilege the intersection over the union.
Larry
fear...@wicc.weizmann.ac.il
!! Sorry, in previos post I had a mistake
Proposal : Vector operations for Hashes
(
this is just a joke
%a ^{+} %b
)
the direct generalization would be as follows :
@a ^[op] @b
for @a ; @b ->
$x ; $y {
$x op $y
}
%a ^[op] %b
# find common keys
@k = keys hash{ map { { _=>1 } } *( %a.keys , %b.keys ) };
#return hash
hash {
for @k -> $x {
{ $x => %a{$x} op %b{$x} }
}
}
so in words , find common keys and then vectorize op as if
Brian Ingerson
> On 2002-10-30 at 12:23:53, David Wheeler wrote:
> > This tells me that Mail.app, for some reason, didn't know that it was
> > supposed to use UTF-8 when showing Larry's mail. When I pasted his mail
> > into a UTF-8 document in Emacs, it looked fine.
> >
> > Given that it's probably UTF-8 that Perl 6 source code is written in, I
> > think that you and I might be better off using a smarter mailer.
> >
> > David
> Larry's mail was *marked* as UTF-8, but by the time I got it it
> had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore.
> My mailer understand UTF-8 just fine, and so does vim (which I used to
> look at my spool file to check for encoding oddities); in my copy of his
> message, there's just nothing there. All I can think is that some MTA
> along the way - possibly our very own Exchange server - stripped them out.
Wait. So you mean that a French quote isn't a question mark?
I take back all those things I've said about the French in the last 24 hours.
Cheers, Brian
Markus Laire
> Of course, Real Mathematicians will want [1..10) and (1..10] instead.
That seems familiar, I like it ;)
> There's also an issue of what (1..10) - 1 would or should mean, if
> anything. Does it mean (1..9)? Does 1 + (1..10) mean (2..10)?
>
> And what would ('a' .. 'z') - 1 mean?
If we are going to do math with ranges, we definitely need non-
discreet ranges also. Or at least make sure it's easy enough to
implement as a class.
(1.9 .. 2.1) + (5..7) * (72.49 .. 72.51);
--
Markus Laire 'malaire' <markus...@nic.fi>
Larry Wall
: Larry's mail was *marked* as UTF-8, but by the time I got it it
: had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore.
: My mailer understand UTF-8 just fine, and so does vim (which I used to
: look at my spool file to check for encoding oddities); in my copy of his
: message, there's just nothing there. All I can think is that some MTA
: along the way - possibly our very own Exchange server - stripped them out.
If no one saw them then it could well be a problem on my end.
I'm trying to use a mailer (pine) that doesn't know about UTF-8 in
an environment where vim does UTF-8. And I may have been in a UTF-8
window at the time. Things could easily get screwed up between them.
(Anybody know of a version of pine that does UTF-8?)
This is currently running in a window that does Latin-1 rather than UTF-8.
Do these French quotes come through?
@a «+» @b
Larry
Nicholas Clark
> On 2002-10-30 at 12:23:53, David Wheeler wrote:
> > This tells me that Mail.app, for some reason, didn't know that it was
> > supposed to use UTF-8 when showing Larry's mail. When I pasted his mail
> > into a UTF-8 document in Emacs, it looked fine.
> >
> > Given that it's probably UTF-8 that Perl 6 source code is written in, I
> > think that you and I might be better off using a smarter mailer.
> >
> > David
> Larry's mail was *marked* as UTF-8, but by the time I got it it
> had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore.
> My mailer understand UTF-8 just fine, and so does vim (which I used to
> look at my spool file to check for encoding oddities); in my copy of his
> message, there's just nothing there. All I can think is that some MTA
> along the way - possibly our very own Exchange server - stripped them out.
At the risk of getting very boring:
Larry's message:
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: 8BIT
but the body had literal 8 bit Latin 1 «+»
So the headers were not correct, as far as my mutt thinks, and it showed me a
question mark.
Austin Hastings' message:
Content-Type: text/plain; charset=us-ascii
but the body had literal 8 bit Latin 1 «+»
So the headers were also not correct.
Michael Lazzaro's message:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
body contains =ABop=BB which my mutt happily displays as «op»
His headers accurately describe the body.
I don't know what my mutt is going to do outgoing with this message.
Clearly 8 bit is even more troublesome for mailers than whitespace.
So maybe its a bad thing to use for a language. *However*, based on previous
experience, I do know that literal ASCII bel characters:
do pass quite successfully from 7 bit ASCII to EBCDIC and back again during
their travels. Maybe we can use them for something :-)
Nicholas Clark
--
C++ templates better than perl? http://www.perl.org/advocacy/spoofathon/
Austin Hastings
> Do these French quotes come through?
>
> @a «+» @b
Oui, M'sieu!
Jonathan Scott Duff
> If we are going to do math with ranges, we definitely need non-
> discreet ranges also. Or at least make sure it's easy enough to
> implement as a class.
>
> (1.9 .. 2.1) + (5..7) * (72.49 .. 72.51);
I don't think that "non-discrete ranges" is what you mean. Perhaps
you just want ranges whose step size is something other than 1
(1.9 .. 2.1 : 0.1) + (5..7) * (72.49 .. 72.51 : 0.01)
?
David Wheeler
> This is currently running in a window that does Latin-1 rather than
> UTF-8.
> Do these French quotes come through?
>
> @a ´+ª @b
Nope.
But given that I don't even know where to go to type them in, and doing
so will likely be a PITA...even though I *love* the idea of using these
characters, might it be better to abandon them for now?
Regards,
David
PS: What do they look like in this reply?
David Wheeler
> On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote:
>> --- Larry Wall <la...@wall.org> wrote:
>>
>>> Do these French quotes come through?
>>>
>>> @a «+» @b
>
> Odd, I see them in this message. But In the message from Larry I see
> ?'s
And I didn't see them in Austin's message, but I see them in yours.
Your mailer did the right thing, it looks like.
David
Michael Lazzaro
On Wednesday, October 30, 2002, at 01:28 PM, David Wheeler wrote:
> But given that I don't even know where to go to type them in, and
> doing so will likely be a PITA...even though I *love* the idea of
> using these characters, might it be better to abandon them for now?
Oh, don't say that! I already know what all of these should mean! :-)
≈ … ∫ § ¿ ∆ ∑ Ω ø ¶ º ≠ ≤ ≥ ‹ › ‡ Ø ˇ ¬ Ç Œ ∞ ¡ •
MikeL
Graham Barr
Odd, I see them in this message. But In the message from Larry I see ?'s
Graham.
David Wheeler
> Oh, don't say that! I already know what all of these should mean! :-)
>
> ≈ … ∫ § ¿ ∆ ∑ Ω ø ¶ º ≠ ≤ ≥ ‹ › ‡ Ø ˇ ¬ Ç Œ ∞ ¡ •
Nice, I can see all of those. Your mailer is the same as mine, Apple
Mail, and the headers are:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Which is correct.
But let me ask you -- how did you input those characters?
Michael Lazzaro
On Wednesday, October 30, 2002, at 01:46 PM, David Wheeler wrote:
> But let me ask you -- how did you input those characters?
Applications/Utilities/"Key Caps" (Again, OSX) which shows you where
they all are.
The «» quotes, for example, are option-\ and shift-option-\
:-)
MikeL
Markus Laire
> On Wed, Oct 30, 2002 at 11:10:54PM +0200, Markus Laire wrote:
> > If we are going to do math with ranges, we definitely need non-
> > discreet ranges also. Or at least make sure it's easy enough to
> > implement as a class.
> >
> > (1.9 .. 2.1) + (5..7) * (72.49 .. 72.51);
>
> I don't think that "non-discrete ranges" is what you mean. Perhaps
> you just want ranges whose step size is something other than 1
>
> (1.9 .. 2.1 : 0.1) + (5..7) * (72.49 .. 72.51 : 0.01)
That would also be usefull, but I definitely mean math with
non-discrete ranges. How else are you going to calculate with numbers
which have 'uncertainty-range' (not sure about right term) i.e. all
math in physics. There are bound to be other uses.
This should probably be a class, so only problem is then to be sure
that it's possible to create such a class and use it with easy
syntax.
Then there is a question of what such expressions should return.
A superposition of non-discrete anges encompassing all the possible
solutions would be the easy way. Adding probability distributions to
those ranges would also be usefull. Still this is an implementation
detail.
Damian Conway
> On Tue, 29 Oct 2002, David Whipp wrote:
> : Larry Wall [mailto:la...@wall.org] wrote:
> : > : unary (postfix) operators:
> : > : ... - [maybe] same as ..Inf [Damian votes Yes]
> : > : > I wonder if we can possibly get the Rubyesque leaving out of
> : > endpoints by saying something like 1..!10.
> :
> Of course, ..! and ..^ have the same problem. But it just seems like
> it's really unlikely that someone would use a unary ! or ^ on the
> endpoint term. So with 1..!$x or 1..^$x it's likely to be right if
> we guess (per the longest token rule) that the operator is ..! or ..^.
> The same can't be said of ..<, alas. But at least it might produce
> a syntax error when it tries to parse the >.
>
> Of course, Real Mathematicians will want [1..10) and (1..10] instead.
>
> I kind like ..^ the best because ^ is currently read "exclusive of"
> anyway, sort of...
>
> And the arrow can be read "up to", at least on that end of it. I think
> that ..^ is going to be much, much more common than ^.. will be.
Forgive me but is this syntax really necessary.
Does it buy us enough over +1 and -1?
Proposed Now
1..10 1..10
1..^10 1..9
1..^$x 1..$x-1
1^..10 2..10
$x^..10 $x+1..10
1^..^10 2..9
$x^..^$y $x+1..$y-1
I mean, for what it is, I do like the syntax, but is it useful enough to
warrant the extra cognitive load it brings with it?
Damian
Damian Conway
> Now that we have gained ^ back from being a hyeroperator, could we not
> have ^ as a polymorphic complement operator. It can always be combined
> with ~ or + to force context, eg
>
> $a = ^ +$b;
> $a = ^ ~$b;
>
> We would then have a complement operator that I would assume objects could
> overload and do whatever they liked with.
In creating my operator list I deliberated shied away from the unary and binary
multimorphic forms. But I do see Graham's point and would favour retaining
polymorphic unary C<^> at least.
Damian
Simon Cozens
Brent Dax
# This is currently running in a window that does Latin-1
# rather than UTF-8. Do these French quotes come through?
#
# @a + @b
No, but I'm running Outlook, so it's probably a bug on my end. :^) (It
does show up in that annoying variable-width font it switches to for
displaying UTF-8, though.)
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Simon Cozens
> Forgive me but is this syntax really necessary.
If you're going for user-definable operators, most of this syntax is
entirely unnecessary. Take all the hairy stuff out of core and be done
with it!
This won't stop people arguing about it, though. :)
--
Henry, I'm a Regent Master of the Ancient and Venerable House of Congregation.
Being eccentrically dull is practically my job description.
- Jonathan Jones
fear...@figaro.weizmann.ac.il
So is it usefull to make sence out of these :
hash ^[op] hash
hash ^[op] array
hash ^[op] scalar
array ^[op] array
array ^[op] scalar
Actually ,
I just want to understand , why so much accent is put on vectorizing
atomic operations with arrays . It seems that hashes are at least as
frequent . And automating operations on them may be just as usefull.
( my feeling is that the reason is not the same as in Matlab and such
.. Because it begin to look like Matlab .
)
with arrays we have to resolve the question :
what to do if @a, @b in @a ^[op] @b have different length
with hashes we will have this question
what to do if %a, %b in %a ^[op] %b have not the same set of keys
we can resolve it with properties on hashes.
%a is vector_intersect
%a is vector_unify
Now we have also this question :
what to do in %a ^[op] @a
this again can be resolved by hash property :
%a is vector_maptoindex { return int rand }
I am not shure we need all this ( and in this form ) , but if
vectorizing array operations make operators so heavy , we have to
probably take a ride on it. I dont know. Or probably to go on that
path we should introduce tenzor operators . There was a discussion
about Sets .
how about having
@a ???[op] @b = [ array of @a[x] op @a[y] for all pairs x,y ]
this path have no end, but where to stop ??
arcadi.
Michael Lazzaro
On Wednesday, October 30, 2002, at 03:07 PM, Damian Conway wrote:
> In creating my operator list I deliberated shied away from the unary
> and binary
> multimorphic forms. But I do see Graham's point and would favour
> retaining
> polymorphic unary C<^> at least.
Meaning that the list:
+ - force to numeric context
- - force to numeric context, negate
+^ - force to numeric context, complement
~ - force to string context
~^ - force to string context, complement
simply becomes:
^ - complement (type-specific)
+ - force to numeric context
- - force to numeric context, negate
~ - force to string context
Correct?
MikeL
Damian Conway
> Meaning that the list:
>
> + - force to numeric context
> - - force to numeric context, negate
> +^ - force to numeric context, complement
> ~ - force to string context
> ~^ - force to string context, complement
>
> simply becomes:
>
> ^ - complement (type-specific)
> + - force to numeric context
> - - force to numeric context, negate
> ~ - force to string context
>
> Correct?
that was what I was advocating, yes.
Damian
Me
> ...
> array ^[op] scalar
ie, generally:
term ^[op] term
> what to do if @a, @b in @a ^[op] @b have different length
> what to do if %a, %b in %a ^[op] %b have not the same set of keys
> what to do in %a ^[op] @a
>
> [what to do] resolved by hash property :
I'd expect adverbs rather than adjectives for these sorts
of issues, ie ':' modifiers of vectorization rather than use
of variable/value properties.
> @a ???[op] @b = [ array of @a[x] op @a[y] for all pairs x,y ]
>
> this path have no end, but where to stop ??
b4p6>J! ;> (http://jsoftware.com/)
Seriously, I also think it's worth seeing where this goes.
As noted above, I'd expect use of adverbs to allow
modification of hyperactivity:
%a ^[op] %b : union
Of course, this suffers the obtw problem. An alternative
might be:
%a ^:union[op] %b
I can definitely see scope for wanting separate adverbs
to influence how vectorization works on the lhs and rhs.
Perhaps
%a :foo[op]:bar %b
where I'm assuming :[op] instead of ^[op] as the base
syntax for vectorization.
--
ralph
Larry Wall
: Forgive me but is this syntax really necessary.
: Does it buy us enough over +1 and -1?
Well, that was my first thought, but...
: Proposed Now
:
: 1..10 1..10
: 1..^10 1..9
: 1..^$x 1..$x-1
: 1^..10 2..10
: $x^..10 $x+1..10
: 1^..^10 2..9
: $x^..^$y $x+1..$y-1
:
: I mean, for what it is, I do like the syntax, but is it useful enough to
: warrant the extra cognitive load it brings with it?
I think it helps a lot as soon as you get outside the realm of
integers. And I think it helps a lot with integers too. It seems
like you just want 0..^$size all the time in any C-derived language.
I don't think it's just Ruby envy...
In general, for any type, how do you write
[$min .. $max - $step : $step]
when you don't even necessarily have subtraction defined? We don't know
how to do "z" - 1 in Perl 5, for instance.
Larry
Uri Guttman
fc> So is it usefull to make sence out of these :
fc> hash ^[op] hash
fc> hash ^[op] array
fc> hash ^[op] scalar
fc> array ^[op] array
fc> array ^[op] scalar
well, you can't mung the keys to a hash, just the values. so why not
just use the values method as an [lr]value? this works already in perl5.
%hash.values [+]= 10 ;
%hash1.values [+]= %hash2.values ;
now that may fail as the order of the values would be different so use a
slice:
%hash1.values [+]= %hash2{%hash1.keys} ;
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway
> In general, for any type, how do you write
>
> [$min .. $max - $step : $step]
>
> when you don't even necessarily have subtraction defined? We don't know
> how to do "z" - 1 in Perl 5, for instance.
Okay. I buy that.
Damian
Brian Ingerson
> On Wednesday, October 30, 2002, at 01:35 PM, Graham Barr wrote:
>
> > On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote:
> >> --- Larry Wall <la...@wall.org> wrote:
> >>
> >>> Do these French quotes come through?
> >>>
> >>> @a «+» @b
> >
> > Odd, I see them in this message. But In the message from Larry I see
> > ?'s
>
> And I didn't see them in Austin's message, but I see them in yours.
> Your mailer did the right thing, it looks like.
And I see white question marks over black diamonds on a white background. Of
course the OS X termcap is imfamous.
Cheers, Brian
John Williams
> %a ^:union[op] %b
>
> %a :foo[op]:bar %b
I think that any operators over 10 characters should be banished, and
replaced with functions.
~ John Williams
Mark J. Reed
> (Anybody know of a version of pine that does UTF-8?)
Seriously, I do highly recommend switching from pine to mutt. It's not
a completely painless transition, since mutt is more ELMlike than PINElike,
but I know many who have made the switch and never looked back. And mutt
does do UTF-8 just fine, including converting automagically between
it and various other character sets (whichever ones your iconv library
knows about).
And I continue to see no French quotes whatsoever in your messages,
while those from other people either come through fine or come through
with Latin-1 French quotes marked as UTF-8. Very odd.
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
David Dyck
On Wed, 30 Oct 2002 at 12:17 -0800, Michael Lazzaro <mlazzaro@cognitivity..c...:
> On Wednesday, October 30, 2002, at 11:58 AM, Larry Wall wrote:
> > I'd even be willing to give up ´foo bar bazª meaning qw(foo bar baz)
> > for this.
>
> I can't see that right (MacOSX Jaguar) in the email; to me it looks
> like a forwardtick and an, um, underlined 'a' -- but in spite of that,
> I'm game. It's just so pretty (when it works!)
>
> On my Mac, it's spelled «op» -- can others see that correctly, or do we
> have a sorry disconnect in the fonts, here, for us Mac folks?
This concerns me, so forgive this partial digression.
When I tried to read Larry's message there were no characters
around the foo bar bas (which arrived as
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: 8BIT)
I just saw
"I'd even be willing to give up foo bar baz meaning qw(foo bar baz)
for this."
in both pine and lookout, and my spool files.
I was quite surprized when I saw Larry's message quoted with the
characters in question in Austin's message (arrived
as Content-Type: text/plain; charset=us-ascii)
> I'd even be willing to give up «foo bar baz» meaning qw(foo bar baz)
> for this.
How did they get transformed to the funny 0xb4 and 0xaa characters
in Micheal's quote. (arrived as Content-Transfer-Encoding: quoted-printable_
ISO_8859_1
253 171 AB « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
273 187 BB » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
David Dyck
> -----Original Message-----
> From: Austin Hastings [mailto:austin_...@yahoo.com]
>
> How do you write a < in a Windows based environment? (Other than by
> copying them from Larry's emails or loading MSWord to do
> insert->symbol)
You could use the Character Map accessory to put
the character into the clipboard, or
press the alt and hold the alt key while typing 0171 (or 0187)
< alt+0171
> alt+0187
Me
> >
> > %a :foo[op]:bar %b
>
> I think that any operators over 10 characters should
> be banished, and replaced with functions.
I'd agree with that. In fact probably anything over 4,
and even 4 is seriously pushing it.
I'll clarify that I am talking here about using adverbs.
From A3 (about the colon):
Hence, this operator modifies a preceding operator
adverbially. ... It can be used to supply a ``step'' to a
range operator, for instance.
I would expect the length of these adverbs to fall in a
range somewhat the same as properties. So a word
like 'union' is reasonable, and even 'intersection' too.
Ignoring hyperoperators, one might use an adverb thus:
$a / $b : dbz_Inf
to have a divide by zero be treated as Infinity.
I can see scope for a bunch of adverbs that control how
a particular hyperoperation works. Thus, perhaps:
@a ^[/] @b : short
to stop iteration when the shortest of two arrays is used up.
But this assumes that the adverb applies to the ^[]
hyperop, not the / op.
Perhaps this is resolved thus:
@a ^[/ : dbz_Inf] @b : short
But I also suspect it would be good to be able to
associate distinct adverbs with the lhs and rhs of
a binary operation.
So I thought perhaps one could go down the path of
@a ^ :step(2) [/ : dbz_Inf] :step(3) @b : short
Hmm. Perhaps hyperop adverbs are preceded with
a ^ and one gets instead:
@a ^[/] @b : dbz_Inf, ^short, ^step(2,3)
--
ralph
Markus Laire
I don't think there should be any upper limit for operator-lengths.
e.g. When teaching perl to my little brothers (still at primary
school) I might want to use alphabetical userdefined operators:
print 1 + 5 - 4 / 2
print one plus five minus four divided_by two
(and same in finnish)
näytä yksi plus viisi miinus neljä jaettuna kaksi
At least it wouldn't harm anyone to allow this.
Iain 'Spoon' Truskett
[...]
> You could use the Character Map accessory to put
> the character into the clipboard, or
> press the alt and hold the alt key while typing 0171 (or 0187)
> < alt+0171
> > alt+0187
To be honest, as easy as it is to type ^a^v<< or ^k<<,[1] it's still
typing an awful lot just to get a character. Surely the Perl operator
Huffman encoding should take into account the length of time it takes to
type the darn thing.
Personally, I'm against non US-ascii chars being part of the core
language. It's fine if people want their Unicode identifiers, or import
modules to change operators, but I'd like to think I can at least read
and write my own code in non-Latin-1 environments.
[1] screen and vim respectively, although I could always make vim treat
<< as an abbreviation for the guillemet, although that would
interfere with heredocs),
cheers,
--
Iain, who carefully didn't use any « or » chars until just then. Oops.
fear...@figaro.weizmann.ac.il
>
> %hash1.values [+]= %hash2{%hash1.keys} ;
>
but here is exactly example analogous to
my Dog $x = new Dog .
which was discusse dand turned to
my Dog $x .= new ;
It's (almost) clear what you want when you write
%hash1 [+]= %hash2 ;
so why to screen the meaning with several ( almost ) unnecessary
words .
And besides, If that will be usefull there will be somebody who will
make those shortcuts.
aracdi .
fear...@figaro.weizmann.ac.il
> > > %a ^:union[op] %b
> > >
> > > %a :foo[op]:bar %b
> >
> > I think that any operators over 10 characters should
> > be banished, and replaced with functions.
>
properties , just like hash behaviour in <regexps> is controlled by
properties .
e.g.
union:
(%a,%b) ^is no_strict_keys ;
(%a %b) ^is default_value ( 0 ) ;
%a ^[+] %b
intersection :
(%a,%b) ^is strict_keys ;
%a ^[+] %b
this maybe longer but clear : one line - one concept .
but I am not shure ...
arcadi .
Austin Hastings
Well, that certainly flows fluidly from the fingertips...
^[op], you say?
Or I could finally figure out how to program the function keys on my
keyboard, I guess...
APL, here we come...
=Austin
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
Austin Hastings
--- Iain 'Spoon' Truskett <pe...@dellah.anu.edu.au> wrote:
> * Dyck, David (d...@fluke.com) [31 Oct 2002 19:21]:
>
> [...]
> > You could use the Character Map accessory to put
> > the character into the clipboard, or
> > press the alt and hold the alt key while typing 0171 (or 0187)
> > < alt+0171
> > > alt+0187
>
> To be honest, as easy as it is to type ^a^v<< or ^k<<,[1] it's still
> typing an awful lot just to get a character. Surely the Perl operator
> Huffman encoding should take into account the length of time it takes
> to
> type the darn thing.
Somewhere, deep in the bowels of some Digital Equipment .. err ..
Compaq .. err .. HP building, there's a guy getting major wood because
ALL THAT WORK that he chipped in so many years ago on the 'X' keyboard
input routines is about to be justified. FINALLY, someone in the US is
going to actually use the [compose] key. Woo-hoo!
(Except for the PCLinux guys, who didn't get a "Compose" key. But maybe
they can liquid-paper over the "Windows" key and write in "Compose" and
«voila»!) [Note smooth, casual insertion of guillemets into daily
conversation ...]
How much of the "length of time it takes to type the darn thing" is
because right now we don't use those symbols? Most PC keyboards make
the tilde (~) character a PITA by putting it out at top-left or
top-right (or, worse, just below backspace). The reason -- most people
aren't writing perl or awk code, and so aren't using that symbol.
This is, IMO, one of those cases where if we suck it up and adopt the
operator, and if the operator's as useful as it seems, then it will
take about two weeks before this problem is history. Everyone will know
how to generate the symbol, with the same encoding, on however many
keyboards.
And Tim O'Reilly will be happy because for once newbies will actually
READ the preface chapter of the perl books, in which conventions and
fonts and such are explained -- that's where the first of the masonic
secrets (Perlish rite) will be illuminated.
=Austin
PS: MSIE doesn't like alt-####. I'm still doing copy and paste. But I
have CONFIDENCE...
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
David Wheeler
> Applications/Utilities/"Key Caps" (Again, OSX) which shows you where
> they all are.
>
> The «» quotes, for example, are option-\ and shift-option-\
Oh, well, I guess those aren't *too* far out of the way...
David
--
David Wheeler AIM: dwTheory
da...@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: The...@jabber.org
Austin Hastings
--- fear...@figaro.weizmann.ac.il wrote:
> I agree. But I think that we can get away here with just hash
> properties , just like hash behaviour in <regexps> is controlled by
> properties .
>
> e.g.
> union:
>
> (%a,%b) ^is no_strict_keys ;
> (%a %b) ^is default_value ( 0 ) ;
> %a ^[+] %b
>
> intersection :
>
> (%a,%b) ^is strict_keys ;
> %a ^[+] %b
>
>
> this maybe longer but clear : one line - one concept .
Arcadi,
How would this work for hashes with differing properties?
E.g.,
%a = ("apple" => 1, "abacus" => 2);
%b = ("banana" => 3, "abacus" => 2);
%a ^is strict_keys;
%b ^is no_strict_keys;
%c = %a ^[+] %b;
What would happen?
%a rules?: %c == ("abacus" => 4)
%b rules?: %c == ("apple" => 1, "abacus" => 4, "banana" => 3)
strict_keys filters result?: %c == ("apple" => 1, "abacus" => 4)
=Austin
Me
> > intersection :
>
> How would this work for hashes with differing properties?
>
> %b ^is no_strict_keys;
>
That's one reason why I suggested control of this sort
of thing should be a property of the operation, not of
the operands.
--
ralph
Brian Wheeler
> * Dyck, David (d...@fluke.com) [31 Oct 2002 19:21]:
>
> [...]
> > You could use the Character Map accessory to put
> > the character into the clipboard, or
> > press the alt and hold the alt key while typing 0171 (or 0187)
> > < alt+0171
> > > alt+0187
>
> To be honest, as easy as it is to type ^a^v<< or ^k<<,[1] it's still
> typing an awful lot just to get a character. Surely the Perl operator
> Huffman encoding should take into account the length of time it takes to
> type the darn thing.
>
> Personally, I'm against non US-ascii chars being part of the core
> language. It's fine if people want their Unicode identifiers, or import
> modules to change operators, but I'd like to think I can at least read
> and write my own code in non-Latin-1 environments.
I agree considering, this isn't APL and the problems people have had
mailing examples (let alone creating them!).
I've got to admit all of these operators are scaring me. Seems alot
like Brooks' second-system effect.
Brian Wheeler
bdwh...@indiana.edu
Larry Wall
: That's one reason why I suggested control of this sort
: of thing should be a property of the operation, not of
: the operands.
I think that by and large, the operator knows whether it wants to
do union or intersection. When you're doing «+», it's obviously
union that you want, with undef defaulting to 0. And «//» would
want intersection.
Larry
Larry Wall
: I agree considering, this isn't APL and the problems people have had
: mailing examples (let alone creating them!).
Nevertheless, it has already been decreed that Perl 6 programs are
written in Unicode. That's not gonna change...
: I've got to admit all of these operators are scaring me. Seems alot
: like Brooks' second-system effect.
But that's our slogan:
Perl 6 is second-system effect done right.
:-)
Larry
Larry Wall
: To be honest, as easy as it is to type ^a^v<< or ^k<<,[1] it's still
Thanks, I didn't know it was that «easy» in vim. :-)
: typing an awful lot just to get a character. Surely the Perl operator
: Huffman encoding should take into account the length of time it takes to
: type the darn thing.
Sure, but that's only one half of Huffman. You also have to consider
the frequency of use. (And as a second order effect, whether you want
to discourage frequent use. :-)
I personally think vector ops are pretty "special", and should
remain so. I have enough familiarity with (read: "contempt for")
APL that I don't want multi-dimensional operators to be the default,
regardless of how they're spelled. Special ops should look special.
: Personally, I'm against non US-ascii chars being part of the core
: language. It's fine if people want their Unicode identifiers, or import
: modules to change operators, but I'd like to think I can at least read
: and write my own code in non-Latin-1 environments.
Perl 6 is written in Unicode. This will cause more pain in the short term,
but I'm trying to optimize for twenty years from now. (Yes, this message
is in Latin-1, but that can be considered an encoding of the first 256
codepoints of Unicode.)
Larry
Larry Wall
: I don't think there should be any upper limit for operator-lengths.
There will never be any official limits. Perl is not about arbitrary
limits. But I will tell you that I only added <=> to Perl 5 because
I knew there would never be a <=>= operator. We'll have to relax that
a bit for Perl 6, but we're still trying vaguely to avoid the Icon trap.
Only compositions of operators will be allowed to get longer than 3 chars.
And we try to keep the basic operators at 2 or less.
The really great thing about the French quotes is that they visually
keep the user aware of the composition. «+=» is obviously a variety of
+=, whereas ^+= is not obvious, though shorter. (Square brackets are
even better at that, but have other problems.)
Larry
fear...@figaro.weizmann.ac.il
so is really going to the direction that many "official" operators
will be "wysiwig" Unicode staff like «+» , and then for some slice of the
comunity there will be ( TeX - like ?? ) ascii shortcuts , because we
need them ( what was the length of the tread to figure out how to
write and read them ) . So perl take placeholders from Mathematica ,
vector operations from Matlab , and greek and all other funny
characters from TeX :
use TeX;
@\gamma = @\alpha \hyper[\sum] @\beta ;
arcadi .
fear...@figaro.weizmann.ac.il
> > > union:
> > > intersection :
> >
> > How would this work for hashes with differing properties?
> >
> > %a ^is strict_keys;
> > %b ^is no_strict_keys;
> >
> > What would happen?
>
in the resulting hash only ( and all ) keys of %a will be present.
because %b *admits* unknown keys but %a does not.
although I admit that property names can be much better .
> That's one reason why I suggested control of this sort
> of thing should be a property of the operation, not of
> the operands.
>
> --
> ralph
>
>
arcadi .
fear...@figaro.weizmann.ac.il
> > but I am not shure ...
>
>
thanks . sorry that I write so badly . I'll try to be better .
> (Unless you do this on purpose :-)
>
> Cheers,
fear...@figaro.weizmann.ac.il
>
> --- fear...@figaro.weizmann.ac.il wrote:
> > I agree. But I think that we can get away here with just hash
> > properties , just like hash behaviour in <regexps> is controlled by
> > properties .
> >
> > e.g.
> > union:
> >
> > (%a,%b) ^is no_strict_keys ;
> > (%a %b) ^is default_value ( 0 ) ;
> > %a ^[+] %b
> >
> > intersection :
> >
> > (%a,%b) ^is strict_keys ;
> > %a ^[+] %b
> >
> >
> > this maybe longer but clear : one line - one concept .
>
> Arcadi,
>
> How would this work for hashes with differing properties?
>
> E.g.,
>
> %a = ("apple" => 1, "abacus" => 2);
> %b = ("banana" => 3, "abacus" => 2);
>
> %a ^is strict_keys;
> %b ^is no_strict_keys;
>
> %c = %a ^[+] %b;
>
> What would happen?
in the result hash there will be only keys of %a, because
%b *can admit unknown keys*, but %a - cannot
>
> %a rules?: %c == ("abacus" => 4)
> %b rules?: %c == ("apple" => 1, "abacus" => 4, "banana" => 3)
> strict_keys filters result?: %c == ("apple" => 1, "abacus" => 4)
>
> =Austin
>
arcadi
Me
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> union that you want, with undef defaulting to 0. And // would
> want intersection.
Ok. So I accidentally got something right! ;> ("control of this sort of
thing should be a property of the operation, not of the operands.")
There are clearly some operations where adverbs make sense.
Presumably one of the classes of op for which adverbs might
make sense is hyperop.
Assuming so, did my suggestion of ^adverb make sense to you
as a way to distinguish op and hyperop adverbs?
--
ralph
fear...@figaro.weizmann.ac.il
> > > > > union:
> > > > > intersection :
> > > >
> > > > %a ^is strict_keys;
> > > > %b ^is no_strict_keys;
> >
> > because %b *admits* unknown keys but %a does not.
>
> able to control nuances of (hyper)operations, and
> Larry introduced adverbs for precisely that reason.
>
> Just because one can get away with controlling this
> particular issue via noun adjectives (variable properties)
> does not mean one should. (Although, conversely, just
> because adverbs seem more more appropriate in this
> case doesn't mean one shouldn't for some reason use
> properties as you suggest.)
>
there is one mor epossibility :
temp sub infix:^[<op>] is force_hash_to_intersect ;
( I'm compleatly not sure about that sintax )
sinse "vectorization" of any op is orthogonal concept to details of
that particular op , maybe we can controll behavior of that
vectorization by ( ...? ) properties .
we need it not only for hashes ;
maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of
length 3 ;
arcadi
Brent Dax
# Perl 6 is written in Unicode.
Great. That's a wonderful policy. But it *shouldn't influence routine
coding in any way*. I have no problem with user-defined Unicode
operators. I have a *huge* problem with built-in Unicode operators, and
a gargantuan problem with built-in Unicode operators that are generally
useful.
I can honestly say at this point that I'd rather give up <$iterator>
than lose hyperops. And I consider relegating them to the << >>
digraphs losing them, because I'm never going to be able to remember how
to type them, and neither will anybody else.
Let's look at this logically. Here's all the punctuation (non-\w)
characters on my keyboard and what they do in Perl 6:
TERM OPERATOR DOUBLE
OPERATOR
` backticks none none
' string constants none** none
" string constants none none
# comment comment comment
$ scalar sigil none none
@ array sigil none none
% hash sigil modulo none
& sub sigil junction and** logical and
! logical not none (?) none
^ complement junction xor** logical xor**
| none junction or** logical or
/ regex divide defined or (in
5.9)
* list flatten* multiply exponent
- numify and negate subtraction
postdecrement
+ numify** addition
postincrement
~ stringify* concat** smart
match
= none assignment
comparison
\ get reference none none
.. method call** method call** range constructor
? force to bool* none** trinary operator
, none list composer list composer
; none statement end statement end
(in parentheses) super-comma none
: none super-comma package
separator, trinary operator
( ) expression grouping sub parameters yuck
{ } hash composing hash subscripts yuck
block composing block composing yuck
[ ] array composing array subscripts yuck
< > iterator syntax comparison ops shift-left, shift-right
UNUSED: 5 8 9
Items marked with a * are new, ** are changed. There are twenty-two
'none's on that list, but none of them line up. (Isn't Perl great?!?)
';;' is available (it doesn't mean anything in either term or operator
context), but it's really ugly. The other possibilities I see there
have the same problem.
There are potentially some meaningless sequences, especially with
sigils, but those'll look quite cluttered. Actually, one of the few
good meaningless ones is ^[op] (with the square brackets). In term
context it would normally mean "bitwise complement this array", and in
operator context it would mean "add this array to an xor junction". If
we lose xor junctions (which I'm not necessarily advocating, mind you),
this sequence is pretty much open.
Damn. Larry, I don't envy you your job. :^)
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Me
Right. A property used as you suggest is effectively
an adverb applied at op definition rather than use.
> maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of
> length 3 ;
Right. It's quite plausible that one would want to be
able to control this at op use, rather than definition.
--
ralph
Austin Hastings
I'm still unconvinced that square brackets won't work.
But compared to Larry giving up «foo bar baz», «sont petits pommes de
terre»
Erik Steven Harrison
--
On Thu, 31 Oct 2002 11:26:13
Brent Dax wrote:
>I can honestly say at this point that I'd rather give up <$iterator>
>than lose hyperops.
I was thinking the same thing not long ago. But now
that I think about it, is <operator> ever going to be
confused for <$File_Handle>? The vector operation cosy
up well to the concept of iteration anyway. Hell, if
were desperate (and I think we are) then why not just
double the brackets to <[op]> or [<op>]. Sure it's
ugly, but I prefer it to ^[op] any day of the week,
and it's not going to be ambiguous.
All that said, can anyone come up with a case to
confuse <op> with <$File_Handle>?
-Erik
____________________________________________________________
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Brent Dax
# All that said, can anyone come up with a case to
# confuse <op> with <$File_Handle>?
If you assume infinite lookahead, it's fine, but if not...
<something> ...
Is that a call to
sub something() returns(IO::Handle)
or a hypered
sub operator:something($operand:)
?
fear...@figaro.weizmann.ac.il
>
>
> All that said, can anyone come up with a case to
> confuse <op> with <$File_Handle>?
>
>
it seems that parser cannot confuse them because <op> is operator and
parser expect operator, while <$File_Handle> is a term .
but human can confuse .
I personally also like <op> sintax.
arcadi .
Luke Palmer
> Date: Thu, 31 Oct 2002 14:45:16 -0800
> From: "Erik Steven Harrison" <pu...@angelfire.com>
> Cc: perl6-l...@perl.org
> X-Sent-Mail: off
> Reply-To: pu...@angelfire.com
> X-Sender-Ip: 152.18.50.63
> Organization: Angelfire (http://email.angelfire.mailcity.lycos.com:80)
> Content-Language: en
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
>
> --
>
> On Thu, 31 Oct 2002 11:26:13
> Brent Dax wrote:
>
> >I can honestly say at this point that I'd rather give up <$iterator>
> >than lose hyperops.
>
> I was thinking the same thing not long ago. But now
> that I think about it, is <operator> ever going to be
> confused for <$File_Handle>? The vector operation cosy
> up well to the concept of iteration anyway. Hell, if
> were desperate (and I think we are) then why not just
> double the brackets to <[op]> or [<op>]. Sure it's
> ugly, but I prefer it to ^[op] any day of the week,
> and it's not going to be ambiguous.
>
> All that said, can anyone come up with a case to
> confuse <op> with <$File_Handle>?
sub postfix:bar returns handle;
$y = undef <bar>;
That has two syntactically valid interpretations. It wouldn't take
even that much to confuse the parser, though.
Luke
Larry Wall
: Erik Steven Harrison writes:
: >
: >
: > All that said, can anyone come up with a case to
: > confuse <op> with <$File_Handle>?
: >
: >
:
: it seems that parser cannot confuse them because <op> is operator and
: parser expect operator, while <$File_Handle> is a term .
All unary operators show up when a term is expected, not an operator.
Larry
Dave Storrs
On Wed, 30 Oct 2002, Larry Wall wrote:
> If no one saw them then it could well be a problem on my end.
> I'm trying to use a mailer (pine) that doesn't know about UTF-8 in
>
> @a «+» @b
I'm using Pine 4.33 on FreeBSD 4.3, and I see these fine.
--Dks
Larry Wall
I sent those as Latin-1, not UTF-8.
Larry
Iain 'Spoon' Truskett
[...]
> This is currently running in a window that does Latin-1 rather than
> UTF-8. Do these French quotes come through?
> @a «+» @b
The window may say Latin-1, but the mail header said UTF-8.
As it happens, I couldn't see them until I piped the message through
less. That said, I've probably got a misconfiguration somewhere.
I usually have trouble with top-bit set chars, and ms codepagisms.
cheers,
--
Iain.
Larry Wall
: > This is currently running in a window that does Latin-1 rather than
: > UTF-8. Do these French quotes come through?
:
: > @a «+» @b
:
: The window may say Latin-1, but the mail header said UTF-8.
:
: As it happens, I couldn't see them until I piped the message through
: less. That said, I've probably got a misconfiguration somewhere.
: I usually have trouble with top-bit set chars, and ms codepagisms.
I was misconfigured here. My pine was marking it as UTF-8 even though
the window was Latin-1. So you ought to be able to see this: @a «*» @b.
I'm definitely going to look into mutt though...gotta have Unicode email.
Larry
Iain 'Spoon' Truskett
[...]
> I was misconfigured here. My pine was marking it as UTF-8 even though
> the window was Latin-1. So you ought to be able to see this: @a «*» @b.
That appeared perfectly.
> I'm definitely going to look into mutt though...gotta have Unicode email.
So I'm told =) Me? I'd be happy if more mailers supported the
Mail-Followup-To header.
I'm not too concerned about unicode since my xterm doesn't support it
anyway =) Obviously, I'll look into it one of these days. Soon after
Perl 6 is released, I imagine.
cheers,
--
Iain.
Brian Wheeler
> On 31 Oct 2002, brian wheeler wrote:
> : I agree considering, this isn't APL and the problems people have had
> : mailing examples (let alone creating them!).
>
> Nevertheless, it has already been decreed that Perl 6 programs are
> written in Unicode. That's not gonna change...
>
Fair enough. However it seems the world isn't ready for unicode
operators. Ok, maybe its me that's not ready. Being a boring American
from the midwest I don't need no stinking French quotes! :) The fries
are good, though.
Anyway, I think that this is a good discussion (despite there being too
many threads to try to follow) and an important one. However,
considering I've spent the last 45 minutes trying to figure a quick way
to enter french quotes into my mailer and editor without them both being
very different and without resorting to cutting and pasting is showing
me that there are big problems with my environment (redhat 8, emacs,
evolution) and I suspect I'm not the only one. Displaying the glyphs
has been ok, for the most part, but its been hit and miss, depending on
other people's configuration. Some tables of operators have had lots of
holes.
It seems that to write effective perl using the new features requires me
to change not only how I think in the language, but also how I use my
computer. I think this might be too big of a leap for some. Unless
there's a compromise. Which brings up a question I hesitate to ask:
will there be the equivalent of trigraphs to cover the non-ascii
characters used? While ??< is a terrible substitute for {, it did get
the job done when people weren't able to press the '{' key. It gave
some visual clue as to what was going on, and was fairly easy to
remember. It doesn't bother me if someone wants to use @Straße for an
array, but it gets bad if when instructing others I have to pull some
voodoo key sequence (especially one which is different for each platform
and/or program being used) in order to get the job done. Explaining
emacs' M-x was bad enough for some of the non-programmers in my
organization.
I'm going to go back to lurking now, because I do trust (most) of you.
Though Dan is pretty odd sometimes. :) I know that all of this will get
resolved in a (hopefully) sane fashion. I just wanted to voice my
concerns.
> : I've got to admit all of these operators are scaring me. Seems alot
> : like Brooks' second-system effect.
>
> But that's our slogan:
>
> Perl 6 is second-system effect done right.
>
> :-)
>
But, doesn't *everyone* say that? :)
Brian
> Larry
fear...@figaro.weizmann.ac.il
> >
> > All that said, can anyone come up with a case to
> > confuse <op> with <$File_Handle>?
>
> sub postfix:bar returns handle;
> $y = undef <bar>;
>
> That has two syntactically valid interpretations. It wouldn't take
> even that much to confuse the parser, though.
>
> Luke
>
>
it seems that this example does not work because :
if <bar> is postfix op then it have to be "attached"
$y = undef _<bar>
and "_" is just (optional) part of the name of all postfix operators.
or
$y = undef<bar>
the first interpretation canneot work because unary undef op requires
lvalue expression as its argument , and <iterator> is not .
but it seems , that anyway , the problem here is not with <op> sintax
but with the fact that undef is *term* or *unary prefix op* .
(and it is the only one ( ... ?? ) )
arcadi .
Mark J. Reed
> I'm not too concerned about unicode since my xterm doesn't support it
> anyway =)
If course, you need a Uniciode/ISO-10646 X11 font, but there are plenty of
those around; several came with my RedHat 7.2 Linux distribution.
Unfortunately the nicer X terminal emulators that come with KDE and Gnome
don't seem to do UTF-8 yet.
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
Erik Steven Harrison
--
On Thu, 31 Oct 2002 15:08:06
Brent Dax wrote:
>Erik Steven Harrison:
># All that said, can anyone come up with a case to
># confuse <op> with <$File_Handle>?
>
>If you assume infinite lookahead, it's fine, but if not...
>
> <something> ...
>
>Is that a call to
>
> sub something() returns(IO::Handle)
>
>or a hypered
>
> sub operator:something($operand:)
>
Granted. So, I'm not as bright as I'd like to be. But
it's not unreasonable to ask for the parens to
disambiguate, and I think that I could live with a
required <something()> as opposed to girly French
angles I can't type, especially since (at least for
me) the vector ops are the common case.
I'll be up front and honest: I don't know enough about parsers. But don't we know what operators were using before we parse, and use that knowledge to disambiguate? Sure we can define new operators, but aren't we already assuming infinite lookahead if we can define new operators and use them without a foreward declaration?
-Erik
>?
>
>--Brent Dax <bren...@cpan.org>
>@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>
>Wire telegraph is a kind of a very, very long cat. You pull his tail in
>New York and his head is meowing in Los Angeles. And radio operates
>exactly the same way. The only difference is that there is no cat.
> --Albert Einstein (explaining radio)
>
>
Garrett Goebel
> I was misconfigured here. My pine was marking it as UTF-8 even though
> the window was Latin-1. So you ought to be able to see this:
> @a «*» @b.
>
> Unicode email.
In the quest for keys anyone can reach on any keyboard...
instead of «*» why not: (>*<), <)*(>, >)*(<, [>*<], or [)*(]
Which stands out best?
@a «*» @b
@a (>*<) @b
@a <)*(> @b
@a >)*(< @b
@a [>*<] @b
@a [)*(] @b
IMHO [>*<]
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com gar...@scriptpro.com
Unknown
> In the quest for keys anyone can reach on any keyboard...
>
> instead of «*» why not: (>*<), <)*(>, >)*(<, [>*<], or [)*(]
>
> Which stands out best?
> @a «*» @b
> @a (>*<) @b
> @a <)*(> @b
> @a >)*(< @b
> @a [>*<] @b
> @a [)*(] @b
>
> IMHO [>*<]
That might or might not be a solution for the particular case, but
I think that, over the long term, it would be much better to have
a general solution to the problem of how to represent a character
that's not mapped to the keyboard. In five years, everyone's display
will be able to display any Unicode character. The keyboards will
necessarily lag behind. But if we had a general way to represent
a character as a sort of entity, we could translate to Unicode at
some point in a kind of "fixup" pass. I could see using backtick
as the "escape" code for things like `<< or `>> which would turn
into what some benighted soul called "girly" angles.
Larry
John Adams
> Which stands out best?
> @a «*» @b
> @a (>*<) @b
> @a <)*(> @b
> @a >)*(< @b
> @a [>*<] @b
> @a [)*(] @b
> IMHO [>*<]
I say go with the one with the cutest name.
Garrett's choice is the bow-tie operator--not bad.
This one: (>*<) is also a pretty good bow-tie.
This one: >)*(< would be the talking-out-of-both-sides-of-your-face operator.
Useful for marketing.
But this one: <)*(> can, in the TMTOWTDI spirit, be either the Madonna or the
Anna Nicole operator.
I think the choice is clear.
Thanks,
John A
see me fulminate at http://www.jzip.org/
Philippe 'Book' Bruhat
> Larry mused:
>
> > Of course, Real Mathematicians will want [1..10) and (1..10] instead.
> >
>
> Forgive me but is this syntax really necessary.
> Does it buy us enough over +1 and -1?
And for what it's worth, Real Mathematicians do not use open intervals for
integers!
(Sorry for the late post, but p6l is always 200 messages ahead of me)
--
Philippe "BooK" Bruhat
One lesson learned is never enough.
(Moral from Groo The Wanderer #104 (Epic))
Stéphane Payrard
> Date: Sat, 2 Nov 2002 11:18:22 +0100 (CET)
> From: Philippe 'BooK' Bruhat <Philipp...@free.fr>
> To: "perl6-l...@perl.org" <perl6-l...@perl.org>
> Subject: Re: [RFC] Perl6 Operator List, Take 5
>
> On Thu, 31 Oct 2002, Damian Conway wrote:
>
> > Larry mused:
> >
> > > Of course, Real Mathematicians will want [1..10) and (1..10] instead.
> > >
> >
> > Forgive me but is this syntax really necessary.
> > Does it buy us enough over +1 and -1?
>
> And for what it's worth, Real Mathematicians do not use open intervals for
> integers!
BooK, we are not talking topology here even if we are free to borrow
syntax from anywhere for notational convenience and mnemonic value.
But here, this will buy us not much, will confuse editors like vi or
emacs; Also the notation itself is not even universally adopted. In
French schools, we were writing [1..10[ for the [1..10). I find the
French notation more mnemonic because it shows clearly that the right
bracket is "porous".
--
stef
Peter Haworth
> Meaning that the list:
>
> +^ - force to numeric context, complement
> ~^ - force to string context, complement
>
> simply becomes:
>
> ^ - complement (type-specific)
Does this include booleans? I really liked the idea that not and xor were
just the same operator, but unary/binary. Otherwise, we have ! for boolean
negation only, while ^ does the same thing for other types, as well as xor
for everything. I don't mind leaving ! in as a synonym.
--
Peter Haworth p...@edison.ioppublishing.com
"Send this via the BT scuz-a-filtron"
-- Andy Wardley