Semantics of vector operations
Luke Palmer
[1,2,3] »+« [4,5,6]
At first glance, one might say [5,7,9]. But is that really the best
way to go? I'm beginning to think that it should be the same as
whatever [1,2,3]+[4,5,6] is, hopefully an error.
Here's my reasoning. Substitute $a = [1,2,3] and $b = [4,5,6]. Those
are list I<references>, after all. So now it becomes:
$a »+« $b
That might just be okay, since they're both listrefs, and you shouldn't
expect a vector on two scalars to do much besides dereference its
arguments. But now, instead of $a, use the real list (1,2,3):
(1,2,3) »+« $b
That looks extremely different from before. That looks like it's adding
$b to each of (1,2,3). Not only that, but say you have:
$x »+« $y
$x is a number, and $y is a listref. Extrapolating from before, you'd
think that this should add $x to each of $y's elements. But this is
starting to feel like run-time DWIMmery, which is almost always a Bad
Idea (favoring syntactic DWIMmery).
So I'm going to argue that:
[1,2,3] »+« [4,5,6]
either give an error because you can't add listrefs, or give a "useless
use of vector operation on two scalars" error. And if you want what
we originally thought, use:
(1,2,3) »+« (4,5,6)
@$a »+« @$b
$x »+« @$y
Luke
à
Larry Wall
: A thought occurred to me. What should this return:
:
: [1,2,3] »+« [4,5,6]
:
: At first glance, one might say [5,7,9]. But is that really the best
: way to go? I'm beginning to think that it should be the same as
: whatever [1,2,3]+[4,5,6] is, hopefully an error.
Doing what you expect at first glance is also called "not violating
the principle of least surprise".
: Here's my reasoning. Substitute $a = [1,2,3] and $b = [4,5,6]. Those
: are list I<references>, after all. So now it becomes:
:
: $a »+« $b
:
: That might just be okay, since they're both listrefs, and you shouldn't
: expect a vector on two scalars to do much besides dereference its
: arguments. But now, instead of $a, use the real list (1,2,3):
:
: (1,2,3) »+« $b
:
: That looks extremely different from before. That looks like it's adding
: $b to each of (1,2,3).
But the programmer probably knows whether $b contains a list ref or
a scalar. This is primarily a problem to the reader of the code.
And what if the programmer wants it to do the Right Thing regardless
of whether $b is a scalar or a list? I suspect that there are
mathematical operations that should generalize down to 0 dimensions,
not just 1 dimension...
: Not only that, but say you have:
:
: $x »+« $y
:
: $x is a number, and $y is a listref. Extrapolating from before, you'd
: think that this should add $x to each of $y's elements. But this is
: starting to feel like run-time DWIMmery, which is almost always a Bad
: Idea (favoring syntactic DWIMmery).
Well, you can say that, but the whole notion of method dispatch is
based on the idea that run-time dwimmery is better than syntactic
dwimmery. But see below for a syntactic proposal.
: So I'm going to argue that:
:
: [1,2,3] »+« [4,5,6]
:
: either give an error because you can't add listrefs, or give a "useless
: use of vector operation on two scalars" error. And if you want what
: we originally thought, use:
:
: (1,2,3) »+« (4,5,6)
: @$a »+« @$b
: $x »+« @$y
On the other hand, it's possible that we should extend the visual metaphor
of »« and apply it asymmetrically when one of the arguments is expected to
be scalar. That would mean that your last three lines would be written:
(1,2,3) »+« (4,5,6)
$a »+« $b
$x +« $y
What's more, a unary vector op would then just be
-« @bar
This also lets us use an array in its scalar sense for its length:
@foo »+ @bar
So to add the length of an array to each of its elements, you'd be
able to say:
@foo »+= @foo;
It might take some getting used to, but I kind of like this idea,
especially if you pronounce » and « as "each". (Doubtless some
joker will propose that we pronounce them "leach" and "reach"...)
So
@foo »= 0;
unambiguously means "@foo each equals 0". You can still say
@foo »=« 0;
but then you're relying on the dwimmery to realize that the thing
on the right is a scalar value. So the difference between
@foo »= $bar
and
@foo »=« $bar
is that the second one has to look at $bar at runtime to see if it
"does" the list thing, and if not, listify it.
Note that if we do take this approach, we'll have to require the
space after = in
@list = «a b c d e»;
Larry
Jonathan Lang
> Note that if we do take this approach, we'll have to require the space
> after = in
>
> @list = «a b c d e»;
Perl 6 has already set the precedent of the presence or absence of
whitespace being syntactically important (as opposed to Python, where the
amount and type of whitespace is syntactically important). As such, I'd
have no problem with this.
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
Austin Hastings
> -----Original Message-----
> From: Larry Wall [mailto:la...@wall.org]
> On the other hand, it's possible that we should extend the visual metaphor
> of »« and apply it asymmetrically when one of the arguments is expected to
> be scalar. That would mean that your last three lines would be written:
>
> (1,2,3) »+« (4,5,6)
> $a »+« $b
> $x +« $y
>
> What's more, a unary vector op would then just be
>
> -« @bar
>
> This also lets us use an array in its scalar sense for its length:
>
> @foo »+ @bar
If only from a syntax-highlighting point of view, this is a horrible
proposal. Make it die.
=Austin
Jonathan Lang
> Larry Wall wrote:
> > On the other hand, it's possible that we should extend the visual
> > metaphor of »« and apply it asymmetrically when one of the arguments
> > is expected to be scalar. That would mean that your last three lines
> > would be written:
> >
> > (1,2,3) »+« (4,5,6)
> > $a »+« $b
> > $x +« $y
> >
> > What's more, a unary vector op would then just be
> >
> > -« @bar
> >
> > This also lets us use an array in its scalar sense for its length:
> >
> > @foo »+ @bar
>
> If only from a syntax-highlighting point of view, this is a horrible
> proposal. Make it die.
How is this any worse than syntax-highlighting a full »« construct?
Incidently, it might make matters easier if you forbid whitespace between
the »« operator modifier and its operator. Indeed, you might want to look
into including a trait for operator declarations which allows you to
modify the importance of whitespace - something like:
sub circumfix:»« (&o is infix) is whitespace(forbidden) {...}
sub prefix:» (&o is postfix|infix) is whitespace(forbidden) {...}
sub postfix:« (&o is prefix|infix) is whitespace(forbidden) {...}
Luke Palmer
Larry Wall writes:
> On Tue, Jan 20, 2004 at 01:54:33AM -0700, Luke Palmer wrote:
> : A thought occurred to me. What should this return:
> :
> : [1,2,3] »+« [4,5,6]
> :
> : At first glance, one might say [5,7,9]. But is that really the best
> : way to go? I'm beginning to think that it should be the same as
> : whatever [1,2,3]+[4,5,6] is, hopefully an error.
>
> Doing what you expect at first glance is also called "not violating
> the principle of least surprise".
Touché.
> : Here's my reasoning. Substitute $a = [1,2,3] and $b = [4,5,6]. Those
> : are list I<references>, after all. So now it becomes:
> :
> : $a »+« $b
> :
> : That might just be okay, since they're both listrefs, and you shouldn't
> : expect a vector on two scalars to do much besides dereference its
> : arguments. But now, instead of $a, use the real list (1,2,3):
> :
> : (1,2,3) »+« $b
> :
> : That looks extremely different from before. That looks like it's adding
> : $b to each of (1,2,3).
>
> But the programmer probably knows whether $b contains a list ref or
> a scalar. This is primarily a problem to the reader of the code.
>
> And what if the programmer wants it to do the Right Thing regardless
> of whether $b is a scalar or a list? I suspect that there are
> mathematical operations that should generalize down to 0 dimensions,
> not just 1 dimension...
Oh, right. I forgot that vector operators generalize based on the
dimension of their arguments. In that case, 0 dimensions is clearly a
valid generalization.
However, I'm not sure I want it to generalize... it gives me the same
heebie-jeebies as the Q::S-style junction semantics, but to a lesser
extent.
As a vague correlation, I've found infinite use in the [ @$list ] shallow
copy. I've never needed deep copy. I'm not sure I'd know what module
to look in if I did. Vector operators at the moment are doing "deep"
operations.
In order to really see what's best, though, I think some concrete
applications are in order. I'm a tensor algebra sort of guy, so let's
do some of that.
Inner product of matrix $A and vector $b:
map -> $i { reduce { $^a + $^b } $A[$i] »*« $b } 0..^$A
(You'll see the use of my very favorite operator above, ..^)
Inner product of matrix $A and matrix $B:
map -> $i {
map -> $j {
$A[$i][$j] * $B[$j][$i]
} 0..^$B
} 0..^$A
Hmm, vector operators really helped out there... :-)
Well, hmm, those examples didn't accomplish much. It's clear that
multidimensionality didn't make anything easier, but it didn't make
anything harder either.
Keep in mind that:
$A »*« $B
Is a mathematically useless operation for two matrices, save for a
slight use or two in image processing. At the moment, I can't think of
anything you could substitute for C<*> to make it useful.
In summary, I'm not sure what I'm arguing anymore. One way is going to
end up being better than the other, but I don't know which one that is.
%-)
I don't think this buys us anything. It makes it look less like » is a
meta-operator acting on += and more like »+= is an operator in and of
itself. Something I'd rather not do, but opinion-driven once again.
But does this really say anything more than:
@foo »+=« +@foo
? Even if @foo happens to be spelled with 50 characters?
> It might take some getting used to, but I kind of like this idea,
> especially if you pronounce » and « as "each". (Doubtless some
> joker will propose that we pronounce them "leach" and "reach"...)
I wonder who that would be... :-p
> So
>
> @foo »= 0;
>
> unambiguously means "@foo each equals 0". You can still say
>
> @foo »=« 0;
>
> but then you're relying on the dwimmery to realize that the thing
> on the right is a scalar value. So the difference between
>
> @foo »= $bar
>
> and
>
> @foo »=« $bar
>
> is that the second one has to look at $bar at runtime to see if it
> "does" the list thing, and if not, listify it.
I think I see where this is going. After all,
@foo »= $bar
Is certainly cleaner than the current alternative:
@foo »=« $bar xx @foo
But you're right, it would take some getting used to, for sure.
> Note that if we do take this approach, we'll have to require the
> space after = in
>
> @list = «a b c d e»;
Meh. No problem.
Luke
à
A. Pagaltzis
> Note that if we do take this approach, we'll have to require the
> space after = in
>
> @list = «a b c d e»;
This shouldn't be a problem. The whitespace rule changes I
believe should be avoided (Abigail does have a point there) is if
whitespace between composite constructs were to be disallowed. I
don't see required whitespace being a problem outside golf/obfu.
That said, I'm not sure how keen I am on the idea of "one-sided"
vector operators. It seems to me that this is too big a
semantic choice to make merely by omission of a single (and quite
dainty) character. I'd rather express this by forcing a context
on the operand. The precedent so far also seems to be a
rule-of-thumb that "I have to write more when I want to be
explicit".
--
Regards,
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
Larry Wall
: If only from a syntax-highlighting point of view, this is a horrible
: proposal. Make it die.
This would be relatively straightforward for syntax highlighters,
I think. But Perl 6 will throw other curves at highlighters that
will be much more difficult to solve, such as the fact that any
C<use> potentially changes the subsequent syntax. Even an operator
declaration changes the subsequent syntax. Making things easy for
syntax highlighters is not a primary design goal for Perl 6--in this
Perl will remain the AntiLisp.
If the proposal dies, it'll be on semantic and/or psychological grounds.
(Not counting the psychological grounds of it being hard to get used to. :-)
Larry
Larry Wall
: That said, I'm not sure how keen I am on the idea of "one-sided"
: vector operators. It seems to me that this is too big a
: semantic choice to make merely by omission of a single (and quite
: dainty) character. I'd rather express this by forcing a context
: on the operand. The precedent so far also seems to be a
: rule-of-thumb that "I have to write more when I want to be
: explicit".
But I would argue that it's the vectorization of the argument that
is special, and that's precisely why it should only be used on the
argument that is to be considered "plural". The underlying psychology
here is that most people assume that all these operators take scalar
(singular) arguments.
Now, a mathematician might assume otherwise, but said mathematician
will probably put "use vectorops" at the front and leave out all the
"dainty" characters from the get-go.
Larry
Uri Guttman
LW> This would be relatively straightforward for syntax highlighters,
LW> I think. But Perl 6 will throw other curves at highlighters that
LW> will be much more difficult to solve, such as the fact that any
LW> C<use> potentially changes the subsequent syntax. Even an operator
LW> declaration changes the subsequent syntax. Making things easy for
LW> syntax highlighters is not a primary design goal for Perl 6--in this
LW> Perl will remain the AntiLisp.
and don't forget that since p6 will use the <perl> grammar to parse
perl, that will be available to syntax highlighters. no more wacko
heuristics and broken colors (i don't use them anyway. i can parse code
just fine with b&w :) depending on what the <perl> grammar produces
there might be some extra processing needed.
as for use changing the subsequent syntax, run the grammar with a -c
like option so those modules will get loaded and affect the generated
syntax tree.
another benefit of using the perl rules is that when changes are made to
the <perl> grammar, all highlighter which use it will be automatically
upgraded. they may have to add stuff for things which have new 'syntax
categories'.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Austin Hastings
> -----Original Message-----
> From: Larry Wall [mailto:la...@wall.org]
Perhaps the right way to vectorize the arguments is to delimit them with
vectorization markers?
@a + >>$b<<
=Austin
Piers Cawley
>>>>>> "LW" == Larry Wall <la...@wall.org> writes:
>
> LW> This would be relatively straightforward for syntax highlighters,
> LW> I think. But Perl 6 will throw other curves at highlighters that
> LW> will be much more difficult to solve, such as the fact that any
> LW> C<use> potentially changes the subsequent syntax. Even an operator
> LW> declaration changes the subsequent syntax. Making things easy for
> LW> syntax highlighters is not a primary design goal for Perl 6--in this
> LW> Perl will remain the AntiLisp.
>
> and don't forget that since p6 will use the <perl> grammar to parse
> perl, that will be available to syntax highlighters. no more wacko
> heuristics and broken colors (i don't use them anyway. i can parse code
> just fine with b&w :) depending on what the <perl> grammar produces
> there might be some extra processing needed.
I think you're only going to get truly accurate syntax highlighting
for all Perl in an image based IDE implemented in Perl since such an
editor will always know what grammar rules are in scope for a given
chunk of code. And once you go to an image based IDE and have access
to the bytecode of the code you're writing there's all *sorts* of
interesting things you can do. And that's before one starts to imagine
attaching the IDE/debugger to a running process...
--
Beware the Perl 6 early morning joggers -- Allison Randal
Dave Mitchell
> Perhaps the right way to vectorize the arguments is to delimit them with
> vectorization markers?
>
> @a + >>$b<<
or @a + @$b even!
--
Justice is when you get what you deserve.
Law is when you get what you pay for.
A. Pagaltzis
> On Wed, Jan 21, 2004 at 03:21:01PM +0100, A. Pagaltzis wrote:
> > It seems to me that this is too big a semantic choice to make
> > merely by omission of a single (and quite dainty) character.
> > I'd rather express this by forcing a context on the operand.
> > The precedent so far also seems to be a rule-of-thumb that "I
> > have to write more when I want to be explicit".
>
> But I would argue that it's the vectorization of the argument
> that is special, and that's precisely why it should only be
> used on the argument that is to be considered "plural". The
> underlying psychology here is that most people assume that all
> these operators take scalar (singular) arguments.
Good point; however, this means different way to think of the
vector ops than we had so far. Basically, we're moving from the
realm of vector ops to that of vectorized operands.
In light of this, I think Austin's proposal of marking the
operands as vectorized makes a lot of sense. It was an unexpected
that had me taken aback for a moment, but I like it more the more
I think about it. It *feels* right to emphasize vectorization as
something that happens to an operand, rather than something
that's a property of the operation.
A. Pagaltzis
> And once you go to an image based IDE and have access to the
> bytecode of the code you're writing there's all *sorts* of
> interesting things you can do. And that's before one starts to
> imagine attaching the IDE/debugger to a running process...
$smalltalkometer++ ? :)
A. Pagaltzis
proofreading make.
* A. Pagaltzis <paga...@gmx.de> [2004-01-22 03:55]:
> Good point; however, this means
a
> different way to think of the vector ops than we had so far.
> Basically, we're moving from the realm of vector ops to that of
> vectorized operands.
>
> In light of this, I think Austin's proposal of marking the
> operands as vectorized makes a lot of sense. It was an
> unexpected
twist
Larry Wall
: Good point; however, this means different way to think of the
: vector ops than we had so far. Basically, we're moving from the
: realm of vector ops to that of vectorized operands.
:
: In light of this, I think Austin's proposal of marking the
: operands as vectorized makes a lot of sense. It was an unexpected
: that had me taken aback for a moment, but I like it more the more
: I think about it. It *feels* right to emphasize vectorization as
: something that happens to an operand, rather than something
: that's a property of the operation.
I think some people will want to think of it one way, while others
will want to think of it the other way. If that's the case, the
proper place to put the marker is between the operand and the operator.
You might argue that we should force people to think of it one way or
the other. But there's a reason that some people will think of it
one way while others will think of it the other way--I'd argue that
vectorization is not something that happens to *either* the operand
or the operator. Vectorization is a different *relationship* between
the operator and the operand. As such, I still think it belongs
between.
Plus, in the symmetrical case, it *looks* symmetrical. Marking the
args in front makes everything look asymmetrical whether it is or not.
Larry
Larry Wall
: * Piers Cawley <pdca...@bofh.org.uk> [2004-01-21 23:33]:
: > And once you go to an image based IDE and have access to the
: > bytecode of the code you're writing there's all *sorts* of
: > interesting things you can do. And that's before one starts to
: > imagine attaching the IDE/debugger to a running process...
:
: $smalltalkometer++ ? :)
%languageometer.values »+=« rand;
Not to be confused with
%languageometer.values »+= rand;
which would presumably add the *same* number to all languageometers.
Larry
Austin Hastings
> -----Original Message-----
> From: Larry Wall [mailto:la...@wall.org]
> Sent: Thursday, January 22, 2004 12:50 PM
> To: Language List
> Subject: Re: Semantics of vector operations
>
>
In reverse order:
> %languageometer.values »+= rand;
This is the same as
all( %languageometer.values ) += rand;
right?
And is this
> %languageometer.values »+=« rand;
the same as
all( %languageometer.values ) += one( rand );
?
=Austin
Austin Hastings
> -----Original Message-----
> From: Larry Wall [mailto:la...@wall.org]
> Sent: Thursday, January 22, 2004 12:39 PM
> To: Language List
> Subject: Re: Semantics of vector operations
>
>
> On Thu, Jan 22, 2004 at 03:53:04AM +0100, A. Pagaltzis wrote:
> : Good point; however, this means different way to think of the
> : vector ops than we had so far. Basically, we're moving from the
> : realm of vector ops to that of vectorized operands.
> :
> : In light of this, I think Austin's proposal of marking the
> : operands as vectorized makes a lot of sense. It was an unexpected
> : that had me taken aback for a moment, but I like it more the more
> : I think about it. It *feels* right to emphasize vectorization as
> : something that happens to an operand, rather than something
> : that's a property of the operation.
>
> I think some people will want to think of it one way, while others
> will want to think of it the other way. If that's the case, the
> proper place to put the marker is between the operand and the operator.
>
How do you handle operator precedence/associativity?
That is,
$a + $b + $c
If you're going to vectorize, and combine, then you'll want to group. I
think making the vectorizer a grouper as well kills two birds with one
stone.
$a + >>$b + $c<<
vs.
$a +<< ($b + $c)
> You might argue that we should force people to think of it one way or
> the other. But there's a reason that some people will think of it
> one way while others will think of it the other way--I'd argue that
> vectorization is not something that happens to *either* the operand
> or the operator. Vectorization is a different *relationship* between
> the operator and the operand. As such, I still think it belongs
> between.
>
> Plus, in the symmetrical case, it *looks* symmetrical. Marking the
> args in front makes everything look asymmetrical whether it is or not.
Just a refresher, what *exactly* does vectorization do, again? I think of
it as smart list-plus-times behavior, but when we go into matrix arithmetic,
that doesn't hold up. Luke?
=Austin
Jonathan Scott Duff
> In reverse order:
>
> > %languageometer.values ?+= rand;
>
> This is the same as
>
> all( %languageometer.values ) += rand;
>
> right?
It's the same as
$r = rand;
$_ += $r for %languageometer.values
Your junction looks like it should work but I think you're really
adding the random number to the junction, not the elements that compose
the junction thus none of %languageometer.values are modified.
> And is this
>
> > %languageometer.values ?+=? rand;
>
> the same as
>
> all( %languageometer.values ) += one( rand );
I don't think so. It's like:
$_ += rand for %languageometer.values
perhaps if you had:
$j |= rand for (0..%languageometer.values)
any(%languageometer.values) += $j;
Though I'm not sure what that would mean.
I don't think junctions apply at all in vectorization. They seem to
be completely orthogonal.
-Scott
--
Jonathan Scott Duff
du...@lighthouse.tamucc.edu
Larry Wall
: > -----Original Message-----: > I think some people will want to think of it one way, while others
: > will want to think of it the other way. If that's the case, the
: > proper place to put the marker is between the operand and the operator.
:
: How do you handle operator precedence/associativity?
Me? I handle it by making it an adverb on the base operator. :-)
: That is,
:
: $a + $b + $c
:
: If you're going to vectorize, and combine, then you'll want to group. I
: think making the vectorizer a grouper as well kills two birds with one
: stone.
:
: $a + >>$b + $c<<
Er, pardon me, but bletch.
: vs.
:
: $a +<< ($b + $c)
That's much clearer to me. (Ignoring the fact that you can't add
references. :-)
: > You might argue that we should force people to think of it one way or
: > the other. But there's a reason that some people will think of it
: > one way while others will think of it the other way--I'd argue that
: > vectorization is not something that happens to *either* the operand
: > or the operator. Vectorization is a different *relationship* between
: > the operator and the operand. As such, I still think it belongs
: > between.
: >
: > Plus, in the symmetrical case, it *looks* symmetrical. Marking the
: > args in front makes everything look asymmetrical whether it is or not.
:
: Just a refresher, what *exactly* does vectorization do, again? I think of
: it as smart list-plus-times behavior, but when we go into matrix arithmetic,
: that doesn't hold up. Luke?
It really means "please dereference this scalar in an intelligent
fashion for this particular operator". The exact behavior is
allowed to depend on the operator and the types of both arguments
(if both sides are vectorized). That is, it's probably a multimethod
in disguise.
Actually, it's a bit misleading to call it a vectorizing operator.
It's really a dwim operator that will commonly be used for vectorizing
in the case of one-dimensional lists. For higher dimensional beasties,
it means "make these conform and then apply the operator in some kind
of distributed fashion, with a bias toward leaf operations".
I don't think that »X« means "Do whatever the mathematicians want X
to do." Unicode operators have to be good for something, after all.
So perhaps its best to call » and « "distribution modifiers" or
some such.
Larry
Luke Palmer
> On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> > In reverse order:
> >
> >
> > This is the same as
> >
> > all( %languageometer.values ) += rand;
> >
> > right?
Well, yes. It's also the same as each of:
any( %languageometer.values ) += rand;
none( %languageometer.values ) += rand;
one( %languageometer.values ) += rand;
Since the junctions aren't yet being evaluated in boolean context, the
type of the junction doesn't matter. Which is why making junctions
applicable lvalues might be a bad idea. I'm not sure, but this looks
like a potential confuser.
> It's the same as
>
> $r = rand;
> $_ += $r for %languageometer.values
>
> Your junction looks like it should work but I think you're really
> adding the random number to the junction, not the elements that compose
> the junction thus none of %languageometer.values are modified.
Hmm... that depends on whether junctions hold references, or what they
do in lvalue context, and a whole bunch of other, undecided things.
> > And is this
> >
> > > %languageometer.values »+=« rand;
> >
> > the same as
> >
> > all( %languageometer.values ) += one( rand );
No, what you just wrote is the same as:
all( %languageometer.values ) += rand;
> I don't think so. It's like:
>
> $_ += rand for %languageometer.values
Sortof. I think Larry was implying that rand returned an infinite list
of random numbers in list context. If not, then what he said was wrong,
because it would be sick to say that:
(1,2,3,4,5) »+« foo()
Calls foo() 5 times.
> perhaps if you had:
>
> $j |= rand for (0..%languageometer.values)
> any(%languageometer.values) += $j;
>
> Though I'm not sure what that would mean.
Nonononono! Don't do that! That adds *each* of the random numbers to
*each* of the values. That is, each of the values would increase by
approximately %languageometer/2.
> I don't think junctions apply at all in vectorization. They seem to
> be completely orthogonal.
I'd be happy if that were the case.
Luke
à
Austin Hastings
> -----Original Message-----
> From: Luke Palmer [mailto:fibo...@babylonia.flatirons.org]
> Sent: Thursday, January 22, 2004 3:52 PM
> To: Austin Hastings; Larry Wall; Language List
> Subject: Re: Semantics of vector operations (Damian)
>
>
> Jonathan Scott Duff writes:
> > On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> > > In reverse order:
> > >
> > > > %languageometer.values »+= rand;
> > >
> > > This is the same as
> > >
> > > all( %languageometer.values ) += rand;
> > >
> > > right?
>
> Well, yes. It's also the same as each of:
>
> any( %languageometer.values ) += rand;
> none( %languageometer.values ) += rand;
> one( %languageometer.values ) += rand;
>
> Since the junctions aren't yet being evaluated in boolean context, the
> type of the junction doesn't matter.
That is clear, once you've pointed it out, but really counterintuitive. Since all things are applicable, though, I don't object too much -- it's like "and" vs. "but" in English, I guess.
> Which is why making junctions applicable lvalues might be a bad idea. I'm not sure, but this
> looks like a potential confuser.
I think I disagree. With the caveat that there may be something to be said for discriminating between assigning TO a junction variable and assigning THROUGH one, I think that the presence or absence of assignment-operators is still the (obvious, sufficient) indicator that an assignment is taking place.
all(%languageometer.values) + 6
doesn't look like (and shouldn't be) an assignment.
all(%languageometer.values) += 6;
does.
> > It's the same as
> >
> > $r = rand;
> > $_ += $r for %languageometer.values
> >
> > Your junction looks like it should work but I think you're really
> > adding the random number to the junction, not the elements that compose
> > the junction thus none of %languageometer.values are modified.
>
> Hmm... that depends on whether junctions hold references, or what they
> do in lvalue context, and a whole bunch of other, undecided things.
>
> > > And is this
> > >
> > > > %languageometer.values »+=« rand;
> > >
> > > the same as
> > >
> > > all( %languageometer.values ) += one( rand );
>
> No, what you just wrote is the same as:
>
> all( %languageometer.values ) += rand;
So the vectorization op is providing the "call once per element" distribution service.
Which takes vectorization out of the MTOWTDI category and into the somewhat-orthogonal functionality category.
Vectorized operator: %languageometer.values »+=« rand;
Vectorized "sides": %languageometer.values »+=« rand;
Alt. Vectorized "sides": all(%languageometer.values) +=« rand;
Vectorized operands: »%languageometer.values« += »rand«;
Alt. Vectorized operands: all(%languageometer.values) += »rand«;
I withdraw my aesthetic objection: if vectorizing the operator isn't going to work, I don't like *any* of them very much.
> > I don't think so. It's like:
> >
> > $_ += rand for %languageometer.values
>
> Sortof. I think Larry was implying that rand returned an infinite list
> of random numbers in list context. If not, then what he said was wrong,
> because it would be sick to say that:
>
> (1,2,3,4,5) »+« foo()
>
> Calls foo() 5 times.
Why would it be sick, and in what context?
With Larry's new "vectorized sides" suggestion, putting a guillemot on the right side of the operator vectorizes the right side operand, which *should* call foo() five times.
(1,2,3,4,5) »+ foo() # do { my $x=foo(); (1+$x, 2+$x, 3+$x, 4+$x, 5+$x); }
(1,2,3,4,5) »+« foo() # (1+foo(), 2+foo(), 3+foo(), 4+foo(), 5+foo())
(1,2,3,4,5) +« foo() # Maybe the same as above? What does infix:+(@list,$scalar) do?
(1,2,3,4,5) + foo() # foo() in list context? What does infix:+(@list, @list2) do?
=Austin
A. Pagaltzis
> You might argue that we should force people to think of it one
> way or the other.
I wouldn't, because if I did I'd should've been talking to Guido
rather than you in the first place. :-)
And because I'm talking to you, I'll wonder whether maybe we
ought to have both options.
> I'd argue that vectorization is not something that happens to
> *either* the operand or the operator. Vectorization is a
> different *relationship* between the operator and the operand.
> As such, I still think it belongs between.
That makes a lot of sense; consider me convinced.
Even if I agree after all though, that doesn't make me like the
way »+ and particularly +« look any more than I liked them
before. I usually scoff at "line noise" remarks, but in this case
I'd feel forced to mutter it myself -- it just continues to feel
like too big a change in behaviour dictated by a single "magic
character".
While »+« is a little ugly as well, it does stand out boldly,
something that could not IMHO be said about the one-sided
variants. I'd argue that we really should use something more
visually prominent for the one-sided case.
Maybe »»+ and +«« or something? But the non-Unicode variant would
be, uh, less than pretty.
> Plus, in the symmetrical case, it *looks* symmetrical. Marking
> the args in front makes everything look asymmetrical whether it
> is or not.
I was actually thinking something like
»$a« + »$b«
in which case asymmetry would not be an issue.
Luke Palmer
> How do you handle operator precedence/associativity?
>
> That is,
>
> $a + $b + $c
>
> If you're going to vectorize, and combine, then you'll want to group. I
> think making the vectorizer a grouper as well kills two birds with one
> stone.
>
> $a + >>$b + $c<<
>
> vs.
>
> $a +<< ($b + $c)
I have to agree with Larry here, the latter is much cleaner.
I'm actually starting to like this proposal. I used to shiver at the
implementation of the old way, where people used the operator to group
arbitrary parts of the expression. I wouldn't even know how to parse
that, much less interpret it when it's parsed.
Now, we have a clear way to call a method on a list of values:
@list ».method
And a clear way to call a list of methods on a value:
$value.« @methods
It's turning out pretty nice.
> > You might argue that we should force people to think of it one way or
> > the other. But there's a reason that some people will think of it
> > one way while others will think of it the other way--I'd argue that
> > vectorization is not something that happens to *either* the operand
> > or the operator. Vectorization is a different *relationship* between
> > the operator and the operand. As such, I still think it belongs
> > between.
> >
> > Plus, in the symmetrical case, it *looks* symmetrical. Marking the
> > args in front makes everything look asymmetrical whether it is or not.
>
> Just a refresher, what *exactly* does vectorization do, again? I think of
> it as smart list-plus-times behavior, but when we go into matrix arithmetic,
> that doesn't hold up. Luke?
Well, for being called "vector operators", they're ending up pretty
useless as far as working with mathematical vectors. As a
mathematician, I'd want:
@vec1 »*« @vec2
To do an inner or an outer product (probably outer, as it has no
implicit connotations of the + operator). That is, it would come out
either a matrix or a scalar.
But there are other times when I'd want that to call the operator
respectively. Then you get this for the inner product:
sum(@vec1 »*« @vec2)
Which isn't so bad, after all.
Hmm, but if it does give an outer product, then a generic tensor product
is as easy as:
reduce { $^a »+« $^b } @A »*« @B
And nobody can fathom how happy that would make me.
Also, you'd get the nice consistency that:
@A »+« @B
Is the same as both:
map { @A »+ $^b } @B
map { $^a +« @B } @A
Which is undoubtedly what the mathematician would expect (It's very
reminiscent of how junctions currently work).
But then there's the problem of how you express the oft-wanted:
map -> $i { @A[$i] + @B[$i] } 0..^min(+@A, +@B)
(Hopefully when @A and @B are of equal length).
Maybe there's a way to do it so that we can both be happy: one syntax
that does one thing, another that does the other. Like:
@A »+« @B # One-at-a-time
@A «+» @B # Outer product
Or something. Hmm, then both:
@A »+ $b
@A «+ $b
Would mean the same thing.
Luke
à
Luke Palmer
> > Sortof. I think Larry was implying that rand returned an infinite list
> > of random numbers in list context. If not, then what he said was wrong,
> > because it would be sick to say that:
> >
> > (1,2,3,4,5) »+« foo()
> >
> > Calls foo() 5 times.
>
> Why would it be sick, and in what context?
>
> With Larry's new "vectorized sides" suggestion, putting a guillemot on the right side of the operator vectorizes the right side operand, which *should* call foo() five times.
>
> (1,2,3,4,5) »+ foo() # do { my $x=foo(); (1+$x, 2+$x, 3+$x, 4+$x, 5+$x); }
> (1,2,3,4,5) »+« foo() # (1+foo(), 2+foo(), 3+foo(), 4+foo(), 5+foo())
I think that one is:
do { my @x=foo(); (1+@x[1], 2+@x[2], 3+@x[3], 4+@x[4], 5+@x[5]) }
We've forgotten that foo() could return a list in list context. :-)
> (1,2,3,4,5) +« foo() # Maybe the same as above? What does infix:+(@list,$scalar) do?
Well, what does a list return in scalar context? In the presence of the
C comma, it returns 5 for the last thing evaluated. In its absence, it
returns 5 for the length.
> (1,2,3,4,5) + foo() # foo() in list context? What does infix:+(@list, @list2) do?
Same deal, 5 + $(foo())
Luke
à
Luke Palmer
> > (1,2,3,4,5) +« foo() # Maybe the same as above? What does infix:+(@list,$scalar) do?
>
> Well, what does a list return in scalar context? In the presence of the
> C comma, it returns 5 for the last thing evaluated. In its absence, it
> returns 5 for the length.
>
> > (1,2,3,4,5) + foo() # foo() in list context? What does infix:+(@list, @list2) do?
>
> Same deal, 5 + $(foo())
And of course I forgot to read you comments. So you want to add two
lists, as in:
[1,2,3,4,5] + [foo()]
Well, that's an error, I think. That or it adds the lengths.
Luke
à
Larry Wall
: Well, for being called "vector operators", they're ending up pretty
: useless as far as working with mathematical vectors.
Which is why I suggested calling them distributors or some such.
: As a
: mathematician, I'd want:
:
: @vec1 »*« @vec2
:
: To do an inner or an outer product (probably outer, as it has no
: implicit connotations of the + operator). That is, it would come out
: either a matrix or a scalar.
:
: But there are other times when I'd want that to call the operator
: respectively. Then you get this for the inner product:
:
: sum(@vec1 »*« @vec2)
:
: Which isn't so bad, after all.
Yes, and I think we have to stick with the naive view of what »*« would
do, since there are times you simply want to do a bunch of multiplications
in parallel.
: Hmm, but if it does give an outer product, then a generic tensor product
: is as easy as:
:
: reduce { $^a »+« $^b } @A »*« @B
:
: And nobody can fathom how happy that would make me.
I'd think it would make you even happier to just use the appropriate
Unicode operators directly (presuming there are such).
: Also, you'd get the nice consistency that:
:
: @A »+« @B
:
: Is the same as both:
:
: map { @A »+ $^b } @B
: map { $^a +« @B } @A
:
: Which is undoubtedly what the mathematician would expect (It's very
: reminiscent of how junctions currently work).
:
: But then there's the problem of how you express the oft-wanted:
:
: map -> $i { @A[$i] + @B[$i] } 0..^min(+@A, +@B)
:
: (Hopefully when @A and @B are of equal length).
Yes, though in fact »« is supposed to do max() rather than min() here.
Which, in the case of arrays of equal length, comes out to the same
thing...
: Maybe there's a way to do it so that we can both be happy: one syntax
: that does one thing, another that does the other. Like:
:
: @A »+« @B # One-at-a-time
: @A «+» @B # Outer product
:
: Or something. Hmm, then both:
:
: @A »+ $b
: @A «+ $b
:
: Would mean the same thing.
Which says to me that outer product really wants to be something like
X or ✕ or even ∘ (shades of APL). In the for-what-it's-worth department,
it looks like Python might be using @ for that.
Larry
Jonathan Scott Duff
> On Thu, Jan 22, 2004 at 01:10:25PM -0500, Austin Hastings wrote:
> : > -----Original Message-----
> : > From: Larry Wall [mailto:la...@wall.org]
> : > I think some people will want to think of it one way, while others
> : > will want to think of it the other way. If that's the case, the
> : > proper place to put the marker is between the operand and the operator.
> :
> : How do you handle operator precedence/associativity?
>
> Me? I handle it by making it an adverb on the base operator. :-)
Does that mean it should get the colon? :)
> I don't think that ?X? means "Do whatever the mathematicians want X
> to do." Unicode operators have to be good for something, after all.
>
> So perhaps its best to call ? and ? "distribution modifiers" or
> some such.
Could someone put the non-unicode variants up there so those of us
with unicode-ignorant MUAs can know what exactly we're talking about?
Or alternatively (and certainly better), could someone clue me on how
to make mutt unicode-aware?
thanks,
Larry Wall
: On Thu, Jan 22, 2004 at 11:25:41AM -0800, Larry Wall wrote:
: > Me? I handle it by making it an adverb on the base operator. :-)
:
: Does that mean it should get the colon? :)
Only if all adverbs in English end in -ly.
Of course, my name ends -ly in Japan--I had to learn to answer to "Rally"
when I was there. So maybe I still get the colon... :-)
: > I don't think that ?X? means "Do whatever the mathematicians want X
: > to do." Unicode operators have to be good for something, after all.
: >
: > So perhaps its best to call ? and ? "distribution modifiers" or
: > some such.
:
: Could someone put the non-unicode variants up there so those of us
: with unicode-ignorant MUAs can know what exactly we're talking about?
Those are just the German/French quotes that look like >> and <<.
: Or alternatively (and certainly better), could someone clue me on how
: to make mutt unicode-aware?
Modern versions of mutt are already unicode aware--that's what I'm using.
Make sure .muttrc has
set charset="utf-8"
set editor="vim" (or any editor that can handle utf-8)
set send_charset="us-ascii:iso-8859-1:utf-8"
The main thing is you have to make sure your xterm (or equivalent)
unicode aware. This starts a (reversed video) unicode terminal on
my machine:
LANG=en_US.UTF-8 xterm \
-fg white -bg black \
-u8 \
-fn '-Misc-Fixed-Medium-R-Normal--18-120-100-100-C-90-ISO10646-1'
I'm also using gnome-terminal 2.4.0.1, which knows how to do utf-8
if you tell it in the preferences.
Of course, this is all from the latest Fedora Core, so your software
might not be so up-to-date. And other folks might prefer something
other than en_US. It's the .UTF-8 that's the important part though.
I run some windows in ja_JP.UTF-8. And, actually, my send_charset is
set send_charset="us-ascii:iso-8859-1:iso-2022-jp:utf-8"
because I have Japanese friends who prefer iso-2022-jp because they
don't know how to read utf-8 yet.
Larry
Joe Gottman
I just realized a potential flaw here. Consider the code
$a >>= 1;
Will this right-shift the value of $a one bit and assign the result to $a
(the current meaning)? Or will it assign the value 1 to each element in the
array referenced by $a (as suggested by the new syntax). Both of these are
perfectly valid operations, and I don't think its acceptable to have the
same syntax mean both. I'm aware that using "»=" instead of ">>=" will
eliminate the inconsistency, but not everyone has easy access to Unicode
keyboards.
Joe Gottman
Edwin Steiner
> @A »+« @B # One-at-a-time
> @A «+» @B # Outer product
>
> Or something. Hmm, then both:
>
> @A »+ $b
> @A «+ $b
There is a page you may find inspiring:
http://www.ritsumei.ac.jp/~akitaoka/index-e.html
Sorry, I could not resist. :) The one-sided operators make sense to me
but combining this with both « and » seems hard on the eyes.
That being said I really like the general direction that Perl 6 is
going and I'm looking forward to using it. You're all doing great
work!
back to lurking-mode
-Edwin
Larry Wall
: I just realized a potential flaw here. Consider the code
: $a >>= 1;
:
: Will this right-shift the value of $a one bit and assign the result to $a
: (the current meaning)? Or will it assign the value 1 to each element in the
: array referenced by $a (as suggested by the new syntax). Both of these are
: perfectly valid operations, and I don't think its acceptable to have the
: same syntax mean both. I'm aware that using "»=" instead of ">>=" will
: eliminate the inconsistency, but not everyone has easy access to Unicode
: keyboards.
Well,
$a >>=<< 1
would still presumably be unambiguous, and do the right thing, albeit
with run-time dwimmery. On the other hand, we've renamed all the
other bitwise operators, so maybe we should rename these too:
+< bitwise left shift
+> bitwise right shift
which also gives us useful string bitshift ops:
~< stringwise left shift
~> stringwise right shift
as well as the never-before-thought-of:
?< boolean left shift
?> boolean right shift
Those last would be a great addition insofar as they could always
participate in constant folding. Er, unless the right argument is 0,
of course... :-)
Ain't orthogonality wonderful...
Larry
Luke Palmer
> On Thu, Jan 22, 2004 at 08:08:13PM -0500, Joe Gottman wrote:
> : I just realized a potential flaw here. Consider the code
> : $a >>= 1;
> :
> : Will this right-shift the value of $a one bit and assign the result to $a
> : (the current meaning)? Or will it assign the value 1 to each element in the
> : array referenced by $a (as suggested by the new syntax). Both of these are
> : perfectly valid operations, and I don't think its acceptable to have the
> : same syntax mean both. I'm aware that using "»=" instead of ">>=" will
> : eliminate the inconsistency, but not everyone has easy access to Unicode
> : keyboards.
>
> Well,
>
> $a >>=<< 1
>
> would still presumably be unambiguous, and do the right thing, albeit
> with run-time dwimmery. On the other hand, we've renamed all the
> other bitwise operators, so maybe we should rename these too:
>
> +< bitwise left shift
> +> bitwise right shift
I could have sworn we already did that. I thought they were:
+<<
+>>
But I guess that's an extra unneeded character.
Luke
> which àlso gives us useful string bitshift ops:
Larry Wall
: Larry Wall writes:
: > On the other hand, we've renamed all the
: > other bitwise operators, so maybe we should rename these too:
: >
: > +< bitwise left shift
: > +> bitwise right shift
:
: I could have sworn we already did that. I thought they were:
:
: +<<
: +>>
:
: But I guess that's an extra unneeded character.
Yeah, I kinda wondered if we'd done that already. But hey, if I
don't remember what I already said, how can I get mad when other
people don't remember. :-)
For historical reasons it would be better to stick with the long
versions, even if that does engender the occasional 4-character
+<<= operator. (Not to mention the 6-character »+<<=« operator.
(Not to mention the 8-character >>+<<=<< operator.)) Though I guess
that would make >>+<< ambiguous again, sigh...
Which probably means we have to force bitshifts to +< and +>, so
we can tell the difference between >>+< and >>+<< and >>+<<<. It's
almost getting to the point where we want to allow disambiguating
underscores in operators: >>_+<_<<. Alternately we give up on <<>>
as a qw// replacement and allow spaces: >> +< <<.
But we also have the ambiguity with <<'' and friends, so maybe the real
problem is trying to make the << and >> workarounds look too much like
« and ». Maybe they should be :<< and :>> or some such. Maybe we
should be thinking about a more general trigraph (shudder) policy.
Or some other kind of "entity" policy. Though I don't think people
would be terribly pleased when they see things like:
@a »+<<« @b
Particularly since the "r" one goes on the left, and the "l" on goes
on the right. Still, it's potentially a lot less ambiguous, and puts
people into the "preprocessing" frame of mind, and would certainly
motivate people to move toward editors and terminals that can display:
@a »+<<« @b
And we wouldn't have to define yet another arbitrary list of mappings.
On the other hand, we'd probably have to require a () on the &foo()
notation to distinguish it from an &foo; entity.
As a half-measure, we could allow << and >> for most purposes and
only require the entities when ambiguous. That might be the best
approach.
Larry
Luke Palmer
> On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
> : Larry Wall writes:
> : > On the other hand, we've renamed all the
> : > other bitwise operators, so maybe we should rename these too:
> : >
> : > +< bitwise left shift
> : > +> bitwise right shift
> :
> : I could have sworn we already did that. I thought they were:
> :
> : +<<
> : +>>
> :
> : But I guess that's an extra unneeded character.
>
> Yeah, I kinda wondered if we'd done that already. But hey, if I
> don't remember what I already said, how can I get mad when other
> people don't remember. :-)
>
> For historical reasons it would be better to stick with the long
> versions, even if that does engender the occasional 4-character
> (Not to mention the 8-character >>+<<=<< operator.)) Though I guess
> that would make >>+<< ambiguous again, sigh...
>
> Which probably means we have to force bitshifts to +< and +>, so
> we can tell the difference between >>+< and >>+<< and >>+<<<. It's
> almost getting to the point where we want to allow disambiguating
> underscores in operators: >>_+<_<<. Alternately we give up on <<>>
> as a qw// replacement and allow spaces: >> +< <<.
>
> But we also have the ambiguity with <<'' and friends, so maybe the real
> problem is trying to make the << and >> workarounds look too much like
> should be thinking about a more general trigraph (shudder) policy.
> Or some other kind of "entity" policy. Though I don't think people
> would be terribly pleased when they see things like:
>
> @a »+<<« @b
All of these are getting pretty huge an unwieldy. We do reward the
people with UTF-8 terminals, but oh how we punish those without.
Perhaps that's not the best way to go.
What about >: and :< ? This doesn't visually interfere quite as much,
because we won't be seeing a distributed : or :: operator. It's still
not terribly pretty on things like >:+<<:<, but it's more managable than
>>+<<<<, and not nearly as ambiguous :-)
Luke
> Particularly since the "r" one goes on the left, and the "l" on goes
> on the right. Still, it's potentially a lot less ambiguous, and puts
> people into the "preprocessing" frame of mind, and would certainly
> motivate people to move toward editors and terminals that can display:
>
> @a 損+<<束 @b
Dave Whipp
English might be a better alternative. Using Larry's terminology from a few
posts ago, we might think of:
@a \C[leach] + \C[reach] @b
Not mnemonic in a visual sense, but extendable to all sorts of trigraph
contexts. Indeed, if we had a "this is an operator" operator, we could give
every symbol a textual name:
$a \op[assign] $b \op[plus] $c;
@a = @b \op[leach plus reach] @c;
Dave.
"Luke Palmer" <fibo...@babylonia.flatirons.org> wrote in message
news:20040123212...@babylonia.flatirons.org...
> Larry Wall writes:
> > On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
> > : Larry Wall writes:
> > : > On the other hand, we've renamed all the
> > : > other bitwise operators, so maybe we should rename these too:
> > : >
> > : > +< bitwise left shift
> > : > +> bitwise right shift
> > :
> > : I could have sworn we already did that. I thought they were:
> > :
> > : +<<
> > : +>>
> > :
> > : But I guess that's an extra unneeded character.
> >
> > Yeah, I kinda wondered if we'd done that already. But hey, if I
> > don't remember what I already said, how can I get mad when other
> > people don't remember. :-)
> >
> > For historical reasons it would be better to stick with the long
> > versions, even if that does engender the occasional 4-character
> > +<<= operator. (Not to mention the 6-character ?+<<=? operator.
> > (Not to mention the 8-character >>+<<=<< operator.)) Though I guess
> > that would make >>+<< ambiguous again, sigh...
> >
> > Which probably means we have to force bitshifts to +< and +>, so
> > we can tell the difference between >>+< and >>+<< and >>+<<<. It's
> > almost getting to the point where we want to allow disambiguating
> > underscores in operators: >>_+<_<<. Alternately we give up on <<>>
> > as a qw// replacement and allow spaces: >> +< <<.
> >
> > But we also have the ambiguity with <<'' and friends, so maybe the real
> > problem is trying to make the << and >> workarounds look too much like
> > ? and ?. Maybe they should be :<< and :>> or some such. Maybe we
> > should be thinking about a more general trigraph (shudder) policy.
> > Or some other kind of "entity" policy. Though I don't think people
> > would be terribly pleased when they see things like:
> >
> > @a »+<<« @b
>
> All of these are getting pretty huge an unwieldy. We do reward the
> people with UTF-8 terminals, but oh how we punish those without.
> Perhaps that's not the best way to go.
>
> What about >: and :< ? This doesn't visually interfere quite as much,
> because we won't be seeing a distributed : or :: operator. It's still
> not terribly pretty on things like >:+<<:<, but it's more managable than
> >>+<<<<, and not nearly as ambiguous :-)
>
> Luke
>
> > Particularly since the "r" one goes on the left, and the "l" on goes
> > on the right. Still, it's potentially a lot less ambiguous, and puts
> > people into the "preprocessing" frame of mind, and would certainly
> > motivate people to move toward editors and terminals that can display:
> >
> > @a ?+<<? @b
Doug McNutt
Luke Palmer also responded to my message and said I would be horrified to learn that >>*<< was being called a "vector" operation rather than a "list" operation. I am horrified. Computer scientists have already usurped the terms "real", "kilo", and others and given them non-standard meanings. Please don't do the same with "vector" and "matrix". And forget I ever mentioned quaternion, tensor, and rotor.
I am a physicist and mathematician who uses perl5 extensively for the likes of preparing CAD data for printed circuit board fabrication and creating AutoDesk files in DXF format from mathematical calculations. I even plot data on my web site using perl to create .SVG files. I learned to code when FORTRAN didn't have any version number and I still think I might be happy with pure assembly in parrot but when I want to do vectors or complex numbers I end up in Waterloo Maple for the solutions and M$ Excel for the arithmetic. Perl 6 would sure be nice for once-in-a-while vector operations that are not worth the programming time for an array of 1024 Mac G5's.
This whole thread worrying about semantics of obscure operators for things that are not even going to be real vector or matrix operations worries me. Just who do you think is going to use them? Multiplying elements of an array by each other to get another array is not a vector product and it is not an inner product. It is useless to me regardless of the operator syntax you choose. Ditto for multiplication of lists of lists, also called matrices, where all you do is provide piece by piece multiplication of elements.
In FORTRAN I learned that names that begin with IJKLMN were integers and further that if only a single letter is used it will be assigned to a hardware register. Those letters are what you now call a sigl and I'll bet I spelled it wrong.
Why can't you assign a sigl to things that are to be vectors or matrices and let that determine what the standard operators do? Context could distinguish the inner product from the vector product. typedef? Those of us who actually use vector arithmetic wouldn't mind a special identifier that's not an $, @, or %. Other users need not know about it until they find it useful. If absolutely necessary to comply with modern terminology you could call vectors and matrices members of a class and overload the operators but my experience is that such things just cloud the underlying arithmetic process that needs to be foremost while solving a problem.
The KISS principle is important. Please reconsider your "vector" operations before you go off the deep end with syntax that won't ever be used. And yes, I have some time and would like to help. But it will take hours to learn about the C++ stuff in CVS files. I have Linux and Mac OS neXt available.
Douglas P. McNutt PhD
The MacNauchtan Laboratory
7255 Suntide Place
Colorado Springs CO 80919-1060
voice 719 593 8192
dmc...@macnauchtan.com
http://www.macnauchtan.com/
--
--> There are 10 kinds of people: those who understand binary, and those who don't <--
Larry Wall
: When I see these long squiggles of line noise, I can't help thinking that
: English might be a better alternative. Using Larry's terminology from a few
: posts ago, we might think of:
:
: @a \C[leach] + \C[reach] @b
:
: Not mnemonic in a visual sense, but extendable to all sorts of trigraph
: contexts. Indeed, if we had a "this is an operator" operator, we could give
: every symbol a textual name:
:
: $a \op[assign] $b \op[plus] $c;
: @a = @b \op[leach plus reach] @c;
That's an interesting idea, but I'd prefer to generalize it to the
notion of how you interpolate a macro call that may be ambiguous
with its surroundings. Then you can set up any text you want.
In the unambiguous cases you can leave out the disambiguating syntax.
That is, suppose you have:
macro leach () { return "»" }
macro reach () { return "«" }
You could unambiguosly write
leach+reach
but (assuming spaces not allowed within distributed operators) you can't
write
leacheqreach
But if instead you could write something like
:leach()eq:reach()
then you can still do it even when it'd be ambiguous. But I can think
of prettier ways to disambiguate:
{leach}eq{reach}
[leach]eq[reach]
(leach)eq(reach)
<leach>eq<reach>
Unfortunately, all the good brackets are taken. Hey, we could use
those weird French quotes:
«leach»eq«reach»
Oh, wait...nevermind...
Larry
Larry Wall
: I have been a lurker since early November. Dan S. suggested I get over
: here when I wrote a piece on the summary list describing my feelings
: about vector operations in perl 6. My information was based on the
: recent O'Reilly book and I had to confess that I have never in my
: life opened a CVS file. I did volunteer to help and I remain willing.
Appreciate that...
: Luke Palmer also responded to my message and said I would be horrified
: to learn that >>*<< was being called a "vector" operation rather
: than a "list" operation. I am horrified. Computer scientists have
: already usurped the terms "real", "kilo", and others and given them
: non-standard meanings. Please don't do the same with "vector" and
: "matrix". And forget I ever mentioned quaternion, tensor, and rotor.
Sorry, I was just copying the designers of supercomputers in my
terminology. So you can really blame Seymour Cray for misappropriating
the term. On a Cray, "vector processing" is just operations applied
in parallel to two one-dimensional lists. Unfortunately, I don't
think you'll be able to get an apology from Seymour Cray these days...
: I am a physicist and mathematician who uses perl5 extensively for the
: likes of preparing CAD data for printed circuit board fabrication and
: creating AutoDesk files in DXF format from mathematical calculations. I
: even plot data on my web site using perl to create .SVG files. I
: learned to code when FORTRAN didn't have any version number and I
: still think I might be happy with pure assembly in parrot but when
: I want to do vectors or complex numbers I end up in Waterloo Maple
: for the solutions and M$ Excel for the arithmetic. Perl 6 would sure
: be nice for once-in-a-while vector operations that are not worth the
: programming time for an array of 1024 Mac G5's.
I'd like the program running on the array of 1024 Mac G5's to be in
Perl too. :-)
: This whole thread worrying about semantics of obscure operators for
: things that are not even going to be real vector or matrix operations
: worries me. Just who do you think is going to use them? Multiplying
: elements of an array by each other to get another array is not a vector
: product and it is not an inner product. It is useless to me regardless
: of the operator syntax you choose. Ditto for multiplication of lists
: of lists, also called matrices, where all you do is provide piece by
: piece multiplication of elements.
The so-called vector operations in Perl 6 are not really aimed at
mathemeticians. They're aimed more at the image processing and
finite-state automata folks, who often want to do the same thing in
parallel to a bunch of different array elements. This is why they
may be applied to any operator, not just numeric operators, so that
people can do things like "append newline to every element of this
array" without writing explicit loop or map statements.
Not being a mathemetician myself, it has always been my intention to
let the mathemeticians define their own operators however they see fit.
That is why Perl 6 allows the definition of Unicode operators.
: In FORTRAN I learned that names that begin with IJKLMN were integers
: and further that if only a single letter is used it will be assigned
: to a hardware register. Those letters are what you now call a sigl
: and I'll bet I spelled it wrong.
:
: Why can't you assign a sigl to things that are to be vectors
: or matrices and let that determine what the standard operators
: do? Context could distinguish the inner product from the vector
: product. typedef? Those of us who actually use vector arithmetic
: wouldn't mind a special identifier that's not an $, @, or %. Other
: users need not know about it until they find it useful. If absolutely
: necessary to comply with modern terminology you could call vectors
: and matrices members of a class and overload the operators but my
: experience is that such things just cloud the underlying arithmetic
: process that needs to be foremost while solving a problem.
You are precisely right: "Other users need not know about it until
they find it useful." In this case, I'm one of those other users. :-)
That is why, not being omniscient, I will leave it to the
mathemeticians to define their own sigils. Unfortunately, most of
ASCII is used up, so you'll have to pick your sigils from Unicode.
But part of the design of Perl 6 is that the language be mutable
enough to make this trivially easy. A single declaration can turn
Perl into Swahili, as far as I'm (un)concerned. "All is fair if
you predeclare."
: The KISS principle is important. Please reconsider your "vector"
: operations before you go off the deep end with syntax that won't
: ever be used.
I believe they will be used, but maybe not in your realm of endeavor.
The entire universe does things in parallel, so I think it behooves
Perl to provide some way to specify that without iterative constructs.
I really only care about the concept--I don't give a rip about the
word "vector". I can let it go at the drop of a hat. Because of the
confusion engendered by overloaded use of the term "vector", I've
recently taken to calling them "distributed" operations instead.
But that's a mouthful. Maybe we need to make up a new word.
But "dwimops" is a bit too general. Parops, genops, hmm... Maybe we
should go back to "hyper ops".
On the other hand, we could teach the mathemeticians not to assume
that their usage of a word is the only usage. :-)
And many people do think vector is the opposite of scalar...
: And yes, I have some time and would like to help. But
: it will take hours to learn about the C++ stuff in CVS files. I have
: Linux and Mac OS neXt available.
It would be useful to me to find out which Unicode characters a typical
mathemetician would actually find useful. I don't actually know,
for example, what the preferred operator for outer product would be.
APL used the circle operator, but there are a number of multiplicative
operators defined in Unicode, most of which seem pretty abstruse.
Eventually I'd like general feedback from the viewpoint of the
mathemeticians on the design of overloading, multimethods, and various
forms of syntactic relief. Up till now I really only have the input
of the PDL folks in RFCs 202..207 (available on dev.perl.org), and
some of the design has been influenced by those RFCs already (such
as syntax of slicing). But a lot of this feedback will have to wait
for Apocalypse 9, which will come out sometime after Apocalypse 12,
which will come out sometime...soon...
Larry
Dave Whipp
news:20040124014...@wall.org...
> That is, suppose you have:
>
> macro leach () { return "»" }
> macro reach () { return "«" }
>
> You could unambiguosly write
>
> leach+reach
>
> but (assuming spaces not allowed within distributed operators) you can't
> write
>
> leacheqreach
But, presumably, you could write a macro that has a whitespace-eater encoded
somehow. That is,
macro leach() { chomp_trailing_whitespace; return "»" }
macro reach () { chomp_leading_whitespace; return "«" }
then the macro magic would expand "leach eq reach" as "»eq«" (which,
hopefully, it then re-parses as a single token^Woperator). This doesn't
solve the generalized problem of disambiguating, though I could see a "_"
operator defined as a macro that eats all its surrounding whitespace.
Dave.
Jonathan Lang
> But, presumably, you could write a macro that has a whitespace-eater
> encoded
> somehow. That is,
>
> macro leach() { chomp_trailing_whitespace; return "»" }
> macro reach () { chomp_leading_whitespace; return "«" }
>
> then the macro magic would expand "leach eq reach" as "»eq«" (which,
> hopefully, it then re-parses as a single token^Woperator). This doesn't
> solve the generalized problem of disambiguating, though I could see a
> "_" operator defined as a macro that eats all its surrounding
> whitespace.
...making it a "nospace" character (or is that a "no_space" character?
Same thing?)
You wouldn't be able to say "chomp_trailing_whitespace" if you did this,
though.
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
Larry Wall
: "Larry Wall" <la...@wall.org> wrote in message
: news:20040124014...@wall.org...
: > That is, suppose you have:
: >
: > macro leach () { return "�" }
: > macro reach () { return "�" }
: >
: > You could unambiguosly write
: >
: > leach+reach
: >
: > but (assuming spaces not allowed within distributed operators) you can't
: > write
: >
: > leacheqreach
:
: But, presumably, you could write a macro that has a whitespace-eater encoded
: somehow. That is,
:
: macro leach() { chomp_trailing_whitespace; return "�" }
: macro reach () { chomp_leading_whitespace; return "�" }
:
: then the macro magic would expand "leach eq reach" as "�eq�" (which,
: hopefully, it then re-parses as a single token^Woperator).
Unfortunately, it wouldn't. The second one would only reparse the text
provided by the second macro. It would have to be written as a syntax
tree munging macro. Or we'd have to have
leach(eq)
reach(eq)
each(eq)
: This doesn't
: solve the generalized problem of disambiguating, though I could see a "_"
: operator defined as a macro that eats all its surrounding whitespace.
That has interesting possiblilities. I've always wanted to extend the rule
that says a lonesome right curly implies a trailing semicolon. I'd
like the rule to be that a final curly on *any* line implies a semicolon
after it. Then your _ could be used to "eat" the whitespace and extend
the line that happens to end with curly accidentally:
map { $_ + 1 }_
1,2,3,4,5,6,7,8,9.10;
Given that the usual reason for needing extra whitespace is that you
need a linebreak, I suspect that _ would want to eat comments as well:
map { $_ + 1 }_ # increment by one
1,2,3,4,5,6,7,8,9.10;
A _ would also be useful for gluing postfix operators to their
preceding token in the cases where there's also a conflicting infix
operator and the parser is trying to use whitespace to disambiguate.
Note: we've trying not to define Perl's grammar in those terms, but
we want to allow for the fact that someone might define their own
infix:++ operator, and be willing to differentiate based on whitespace:
$a++ + $b
$a ++ $b
In such a case, your _ would come in handy, so that either of
$a _ ++
$a _++
means
$a++
Note however that it wouldn't be the same as
$a_++
unless we disallowed _ on the end of an identifier, which seems a bit
callous. Likewise you couldn't say
lreach_eq_rreach
but would have to say
lreach _ eq _ rreach
or rely on _ within the macro definition to work correctly, which
might be tricky to implement if some grammar rule has already claimed
the whitespace. And the _ might have the untoward effect of turning
it back into the single token:
lreach_eq_rreach
So we might need to differentiate a token that glues tokens from one
that doesn't. Maybe __ glues tokens. Shades of the C preprocessor...
Given all that, though, I'm not sure that >>_+<<_<< would successfully
disambiguate things unless we view >>op<< as three tokens where the
third token is a postfix operator distinguished by whitespace from
something like >>op <<qwlist>>. I said we were trying to avoid that
distinction in Perl's grammar, but maybe we need it here.
Anyway, if we do use _ for that, the people who want to warp Perl
into Prolog will have to use something else for unnamed bindings. :-)
Larry
Larry Wall
: Dave Whipp wrote:
: > But, presumably, you could write a macro that has a whitespace-eater
: > encoded
: > somehow. That is,
: >
: > macro reach () { chomp_leading_whitespace; return "?" }
: >
: > then the macro magic would expand "leach eq reach" as "?eq?" (which,
: > hopefully, it then re-parses as a single token^Woperator). This doesn't
: > solve the generalized problem of disambiguating, though I could see a
: > "_" operator defined as a macro that eats all its surrounding
: > whitespace.
:
: ...making it a "nospace" character (or is that a "no_space" character?
: Same thing?)
:
: You wouldn't be able to say "chomp_trailing_whitespace" if you did this,
: though.
I doubt a _ macro would fire off in the middle of an identifier
like that. Once a grammar rule has snarfed a construct such as an
identifier, it generally rules out other interpretations of the
construct. There are all sorts of such context sensitivities in
Perl's grammar. A bareword is not a bareword if there's a "sub"
in front of it, or a "$", "@", etc.
Now, if we get into token-gluing scenarios, these sorts of things
come into play. But I think the _ proposal was for whitespace eating
without token gluing.
Larry
Gordon Henriksen
> Anyway, if we do use _ for that, the people who want to warp Perl into
> Prolog will have to use something else for unnamed bindings. :-)
Use ¬! Then the AppleScripters will feel right at home when they upgrade
to Perl 6. :/
—
Gordon Henriksen
mali...@mac.com
John Williams
> Sorry, I was just copying the designers of supercomputers in my
> terminology. So you can really blame Seymour Cray for misappropriating
> the term. On a Cray, "vector processing" is just operations applied
> in parallel to two one-dimensional lists. Unfortunately, I don't
> think you'll be able to get an apology from Seymour Cray these days...
>
> word "vector". I can let it go at the drop of a hat. Because of the
> confusion engendered by overloaded use of the term "vector", I've
> recently taken to calling them "distributed" operations instead.
> But that's a mouthful. Maybe we need to make up a new word.
> But "dwimops" is a bit too general. Parops, genops, hmm... Maybe we
> should go back to "hyper ops".
>
> On the other hand, we could teach the mathemeticians not to assume
> that their usage of a word is the only usage. :-)
I just want to chime in to support dropping the term "vector". There are
enough people who speak both math and CS that I have noticed a lot of
confusion caused by the term, not only in the "outer product" vs "inner
product" vs what-we-really-mean, but also with stopping at the max or min
when working with unequal length lists.
I would vote for "element-wise" for a relatively accurate description, or
"hyper" for short, fun, and not-implying-anything-specific description.
I did a quick survey of a few vector math packages to find some
math-friendly terms. The operations are usually described as being done
"element by element". Matlab uses the term "array" operator, but that may
be overused in perl. Octave says "element by element". Mathematica uses
the term "element-wise". Template Numerical Toolkit used both: "Array
(element-wise)".
~ John Williams
Uri Guttman
JW> On Fri, 23 Jan 2004, Larry Wall wrote:
>> Sorry, I was just copying the designers of supercomputers in my
>> terminology. So you can really blame Seymour Cray for misappropriating
>> the term. On a Cray, "vector processing" is just operations applied
>> in parallel to two one-dimensional lists. Unfortunately, I don't
>> think you'll be able to get an apology from Seymour Cray these days...
JW> I just want to chime in to support dropping the term "vector".
JW> There are enough people who speak both math and CS that I have
JW> noticed a lot of confusion caused by the term, not only in the
JW> "outer product" vs "inner product" vs what-we-really-mean, but
JW> also with stopping at the max or min when working with unequal
JW> length lists.
since the inputs are usually lists, why not call them list-ops?
so >>+<< is list-plus and takes a list (or array ref) on either side and
does a DWIM +. that is, element wise if two lists and a scalar added to
each element if only one list. AFAICT all list ops always generate lists
as a result (reduce is not a list op).
JW> I would vote for "element-wise" for a relatively accurate
JW> description, or "hyper" for short, fun, and
JW> not-implying-anything-specific description.
and >><< is the listifying op. it converts the op it surrounds into a
list form that will return a list value.
this is analogous to += being an assignment op. the key part is the list
result or the assignment and it is a modification of a regular scalar
op.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway
> But we also have the ambiguity with <<'' and friends, so maybe the real
> problem is trying to make the << and >> workarounds look too much like
> « and ». Maybe they should be :<< and :>> or some such. Maybe we
> should be thinking about a more general trigraph (shudder) policy.
Nooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!!!!!!!!!
;-)
> Or some other kind of "entity" policy. Though I don't think people
> would be terribly pleased when they see things like:
>
> @a »+<<« @b
Agreed!
> Particularly since the "r" one goes on the left, and the "l" on goes
> on the right. Still, it's potentially a lot less ambiguous, and puts
> people into the "preprocessing" frame of mind, and would certainly
> motivate people to move toward editors and terminals that can display:
>
> @a »+<<« @b
Yes, it would be an excellent motivation in that direction. But, then, so
would *not* providing any ASCII-based alternative in the first place.
> And we wouldn't have to define yet another arbitrary list of mappings.
Here, here! I certainly believe that any entity notation must use the
"standard" (i.e. HTML and/or Unicode) names for entities.
> On the other hand, we'd probably have to require a () on the &foo()
> notation to distinguish it from an &foo; entity.
Which would seem to suggest that the Huffman coding is backwards. I expect to
use constructs like:
my Code $clocks_ref = ×
far more often than I'd use something like:
my Vector $outer = $vec1 × $vec2;
especially since I'm already using an OS that makes it trivial to code the
latter "properly":
my Vector $outer = $vec1 × $vec2;
Frankly, I'd *much* rather see:
@sum = @a E<raquo>+<<E<laquo> @b;
my Vector $outer = $vec1 E<times> $vec2;
which at least has the benefit of being consistent with POD notation.
(Note that, if we *do* decide to support some kind of ASCII-based entity
notation, we really must make sure it's the same in both Perl code and POD
mark-up.)
Damian
Robin Berjon
> Frankly, I'd *much* rather see:
>
> @sum = @a E<raquo>+<<E<laquo> @b;
>
> my Vector $outer = $vec1 E<times> $vec2;
>
> which at least has the benefit of being consistent with POD notation.
I very much second that. Entities have been one of the worst features of
XML (and, in the end, a fairly useless one), I don't think XML geeks
would be happy seeing them too often in their Perl code :)
> (Note that, if we *do* decide to support some kind of ASCII-based entity
> notation, we really must make sure it's the same in both Perl code and
> POD mark-up.)
Picking the HTML entity names is better than the Unicode ones as the
latter are way too long. They may not cover all the characters we need,
but we can make up missing ones in a consistent fashion.
--
Robin Berjon
Damian Conway
> Picking the HTML entity names is better than the Unicode ones as the
> latter are way too long. They may not cover all the characters we need,
> but we can make up missing ones in a consistent fashion.
I fear there are too many "missing ones" for that.
Any reason we couldn't accept both HTML and Unicode names?
Damian
Robin Berjon
I wasn't proposing to come up with short names for all the Unicode
repertoire, just for the characters that are used as operators :) That
shouldn't be too long, should it?
I have nothing against using the Unicode names for other entities for
instance in POD. The reason I have some reserve on using those for
entitised operators is that E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR
RIGHTWARDS, COMBINING> isn't very readable. Or rather, it's readable
like a totally different plot with its own well-carved out characters,
intrigues, and subplots in the middle of a book.
--
Robin Berjon
John Macdonald
> I have nothing against using the Unicode names for other entities for
> instance in POD. The reason I have some reserve on using those for
> entitised operators is that E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR
> RIGHTWARDS, COMBINING> isn't very readable. Or rather, it's readable
> like a totally different plot with its own well-carved out characters,
> intrigues, and subplots in the middle of a book.
The book of Perl with an embedded copy of the book of COBOL.
Damian Conway
> I wasn't proposing to come up with short names for all the Unicode
> repertoire, just for the characters that are used as operators :) That
> shouldn't be too long, should it?
I'm not so sure about that. I can already see those mathematician/physicists
gazing hungrily at the following blocks:
Superscripts and Subscripts (41 codepoints)
Mathematical Operators (256 codepoints)
Miscellaneous Math Symbols-A (27 codepoints)
Miscellaneous Math Symbols-B (128 codepoints)
Supplemental Math Operators (256 codepoints)
Unicode has a *lot* of potential operators.
> I have nothing against using the Unicode names for other entities for
> instance in POD. The reason I have some reserve on using those for
> entitised operators is that E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR
> RIGHTWARDS, COMBINING> isn't very readable. Or rather, it's readable
> like a totally different plot with its own well-carved out characters,
> intrigues, and subplots in the middle of a book.
Yes, but when you download the Debug::Heisenberg module, surely it will be
better to be able to view:
my sub infix:? {...}
$eigensanction =
$state ? $event;
at least as:
my sub infix:E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR RIGHTWARDS, COMBINING> {...}
$eigensanction =
$state E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR RIGHTWARDS, COMBINING> $event;
if that's all your ancient ASCII device is capable of?
Damian
Robin Berjon
> Robin Berjon wrote:
> > I wasn't proposing to come up with short names for all the Unicode
> > repertoire, just for the characters that are used as operators :) That
> > shouldn't be too long, should it?
>
> I'm not so sure about that. I can already see those
> mathematician/physicists
> gazing hungrily at the following blocks:
>
> Superscripts and Subscripts (41 codepoints)
> Mathematical Operators (256 codepoints)
> Miscellaneous Math Symbols-A (27 codepoints)
> Miscellaneous Math Symbols-B (128 codepoints)
> Supplemental Math Operators (256 codepoints)
>
> Unicode has a *lot* of potential operators.
Are all these for use in the core language though? I was thinking about
defining short names for the core stuff, and people can use the thirty
letter names for more complicated things. I guess they could also use
E<xNNNN>, no? A codepoint may be better than the unreadably long name.
A good solution would be to support the Unicode names and codepoints,
and allow people to define their own entities with friendly names. That,
plus predefined short names for core language ops.
> > I have nothing against using the Unicode names for other entities for
> > instance in POD. The reason I have some reserve on using those for
> > entitised operators is that E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR
> > RIGHTWARDS, COMBINING> isn't very readable. Or rather, it's readable
> > like a totally different plot with its own well-carved out characters,
> > intrigues, and subplots in the middle of a book.
>
> Yes, but when you download the Debug::Heisenberg module, surely it will be
> better to be able to view:
>
> my sub infix:? {...}
>
> $eigensanction =
> $state ? $event;
>
> at least as:
>
> my sub infix:E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR RIGHTWARDS,
> COMBINING> {...}
>
> $eigensanction =
> $state E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR RIGHTWARDS,
> COMBINING> $event;
>
> if that's all your ancient ASCII device is capable of?
I have a dim memory of last time I was forced to deal with anything that
was ASCII only, but to be perfectly honest in the case you cite here I'd
be happier with a hex editor than with those terribly long names :)
--
Robin Berjon
Austin Hastings
"With Included CD!"
Austin Hastings
> -----Original Message-----
> From: Robin Berjon [mailto:robin....@expway.fr]
> Damian Conway wrote:
> > Robin Berjon wrote:
> > > I wasn't proposing to come up with short names for all the Unicode
> > > repertoire, just for the characters that are used as operators :)
That
> > > shouldn't be too long, should it?
> >
> > I'm not so sure about that. I can already see those
> > mathematician/physicists gazing hungrily at the following blocks:
> >
> > Superscripts and Subscripts (41 codepoints)
> > Mathematical Operators (256 codepoints)
> > Miscellaneous Math Symbols-A (27 codepoints)
> > Miscellaneous Math Symbols-B (128 codepoints)
> > Supplemental Math Operators (256 codepoints)
> >
> > Unicode has a *lot* of potential operators.
>
> Are all these for use in the core language though? I was thinking about
> defining short names for the core stuff, and people can use the thirty
> letter names for more complicated things. I guess they could also use
> E<xNNNN>, no? A codepoint may be better than the unreadably long name.
>
> A good solution would be to support the Unicode names and codepoints,
> and allow people to define their own entities with friendly names. That,
> plus predefined short names for core language ops.
I think you guys may be talking at cross purposes. Robin, I think, is
talking primarily about coding, while Damian talks of reading.
Perhaps Damian's solution is a Unicode2Ascii perl script that emits formal
names, combined with the implementation in Perl of the
E<long-assed-ascii-name> alternative spellings.
OTOH, Robin's concern for how to code when you're stuck with 7 bit ascii on
the boot console of a Sun box remains valid, and *I* sure would rather have
a short name available in a standard way.
Perhaps this is where the "accept Unicode and HTML" philosopy comes in, sort
of like the reverse of C< use English; >, to wit:
use asciiops;
...
@list.E<reach>method; # Instead of E<GUILLEMOT, CLOSING QUOTE>
Sadly, it happens more often than I like. Recovering from single-user mode
(crash/boot failure/disk error) on a Sun desktop, for instance: mount perl
across the network, then start parsing those log files... :-(
=Austin
Damian Conway
>> Unicode has a *lot* of potential operators.
>
> Are all these for use in the core language though?
Not yet...but give us time! >;-)
> I was thinking about defining short names for the core stuff, and people
> can use the thirty letter names for more complicated things.
Yes. But doesn't that amount to my HTML-entities-plus-Unicode-names suggestion?
> A good solution would be to support the Unicode names and codepoints,
> and allow people to define their own entities with friendly names.
I fear that might not be a good solution.
I think it's terribly important that Perl 6 have standard -- and preferred --
ways of expressing standard things. That's why it has a standard switch
statement, and a standard class declaration syntax, and a standard grammar
specification mechanism, etc. etc.
We eventually realized that having 26 ways to structure a switch statement
didn't actually help, and I fear that having 26 ways to write »+« won't be
beneficial either. I suspect that having four ways (Unicode glyph, HTML
entity, Unicode hex value, and Unicode name) of representing the common
symbols and three ways (Unicode gylph, Unicode hex value, Unicode name) for
everything else will be enough.
And, in any case, I'm sure if there's actually a demand for it, it won't be
long before some keen individual produces an Entitiy::Rename module. ;-)
> I have a dim memory of last time I was forced to deal with anything that
> was ASCII only, but to be perfectly honest in the case you cite here I'd
> be happier with a hex editor than with those terribly long names :)
Acknowledged. But those terribly long names are also terribly descriptive, and
I suspect there are others besides myself who would prefer cope with the
terrible length of those terribly descriptive names rather than have to
remember what the short but cryptic E<x224C> operator looks like.
Damian
Austin Hastings
> -----Original Message-----
> From: Luke Palmer [mailto:fibo...@babylonia.flatirons.org]
> Austin Hastings writes:
> > Perhaps Damian's solution is a Unicode2Ascii perl script that
> > emits formal names, combined with the implementation in Perl of the
> > E<long-assed-ascii-name> alternative spellings.
> >
> > OTOH, Robin's concern for how to code when you're stuck with 7
> > bit ascii on the boot console of a Sun box remains valid, and
> > *I* sure would rather have a short name available in a standard way.
> >
> > Perhaps this is where the "accept Unicode and HTML" philosopy
> > comes in, sort of like the reverse of C< use English; >, to wit:
> >
> > use asciiops;
> > ...
> > @list.E<reach>method; # Instead of E<GUILLEMOT, CLOSING QUOTE>
>
> I think that using the POD entities + Unicode is fine, but the solution
> to giving people who use E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR
> RIGHTWARDS, COMBINING> often, I belive, is to be able to define these
> escapes simply. Either the module writer or the user would map a more
> usable escape to that character.
Yah, and the "module writer" for the standard P6 builtins like << and >> is us.
So I propose that we
a) Accept the ULAN entities; and
b) Provide a standard module that shortens the names of "core" or "common" Unicode operators to the point they can by typed in 10 or fewer characters (3 of which are E<>, 7 for the name)
It would be nice to make E behave like q or s in that it could dynamically adopt its delimiter characters.
@list .E'>>' $method;
is a nice, readable, short, unobtrusive alias.
=Austin
PS: Damian, your mailbox was full earlier today.
Luke Palmer
> I think you guys may be talking at cross purposes. Robin, I think, is
> talking primarily about coding, while Damian talks of reading.
>
> Perhaps Damian's solution is a Unicode2Ascii perl script that emits formal
> names, combined with the implementation in Perl of the
> E<long-assed-ascii-name> alternative spellings.
>
> OTOH, Robin's concern for how to code when you're stuck with 7 bit ascii on
> the boot console of a Sun box remains valid, and *I* sure would rather have
> a short name available in a standard way.
>
> Perhaps this is where the "accept Unicode and HTML" philosopy comes in, sort
> of like the reverse of C< use English; >, to wit:
>
> use asciiops;
> ...
> @list.E<reach>method; # Instead of E<GUILLEMOT, CLOSING QUOTE>
I think that using the POD entities + Unicode is fine, but the solution
to giving people who use E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR
RIGHTWARDS, COMBINING> often, I belive, is to be able to define these
escapes simply. Either the module writer or the user would map a more
usable escape to that character.
Luke
Rod Adams
Question in all this: What does one do when they have to _debug_ some
code that was written with these lovely Unicode ops, all while stuck in
an ASCII world?
Also, isn't it a pain to type all these characters when they are not on
your keyboard? As a predominately Win2k/XP user in the US, I see all
these glyphs just fine,but having to remember Alt+0171 for a « is going
to get old fast... I much sooner go ahead and write E<raquo> and be done
with it.
Thoughts?
-- Rod
Scott Walters
>
> Also, isn't it a pain to type all these characters when they are not on
> your keyboard? As a predominately Win2k/XP user in the US, I see all
> these glyphs just fine,but having to remember Alt+0171 for a « is going
> to get old fast... I much sooner go ahead and write E<raquo> and be done
> with it.
>
> Thoughts?
>
> -- Rod
>
Agreed. Cryptic, but in a different way than usual. I'd rather see
plain old keywords as long as I'm typing things out or making that
many key-strokes.
sub each (*);
each @arr += 3;
each @arr += each @foo;
Larry Wall suggested reading >> and << as "each".
This would require a small comprimise on the p5 each. Or else it could be
named "vector". Shouldn't be a problem with %hash.keys, %hash.values,
%hash.each anyway.
This wouldn't implement as an operator very well, admittedly, but more like
a control keyword. It would seem closely related to foreach, though.
What happens when there are a bunch of the puppies? Vectorizing operators
do the right thing, working according to the rules of precedence. "each"
would have to just share one iterator per statement, or else do ugly things
to the rest of the statement. It would be very difficult to do something like:
(each @foo + each @bar) + (each @baz + each @baz)
This would lend itself a P5 backport that did overload on its argument, too. If
it found that the thing on the right hand side was also overloaded into the
same class, it is could use a single iterator on both sides, otherwise it would
treat the 2nd argument as a scalar. This would solve the "single iterator
per line" problem for p5 atleast. It would work correctly. Any number of
vectorized arrays could be floating around in an expression, each interacting
with each other correctly.
Would it be possible to subclass things on the fly, returning a specialized
object representing the argument that knew how to vectorize when asked to add?
Aren't add, substract, multiply, and so on, implemented as class methods in
Perl 6, much like Perl 5's overload module?
foreach and map are looking really good, combined with argument binding and
pipelines. Is this redundant perhaps?
Would a keyword for vectorizing be more consistent with the "zip" keyword?
Can you smell the speculation in the air?
Thanks,
-scott
Austin Hastings
> -----Original Message-----
> From: Rod Adams [mailto:r...@rodadams.net]
> Sent: Thursday, January 29, 2004 11:45 PM
> To: perl6-l...@perl.org
> Subject: Re: Semantics of vector operations
>
> Question in all this: What does one do when they have to _debug_ some
> code that was written with these lovely Unicode ops, all while stuck in
> an ASCII world?
>
> Also, isn't it a pain to type all these characters when they are not on
> your keyboard? As a predominately Win2k/XP user in the US, I see all
> these glyphs just fine, but having to remember Alt+0171 for a « is going
> to get old fast... I much sooner go ahead and write E<raquo> and be done
> with it.
>
> Thoughts?
This has been discussed a bunch of times, but for Windows users the very best thing in the US is to change your Start > Settings > Control Panel > Keyboard > Input Locales so that you have the option of switching over to a "United States-International" IME.
Once you've got that available (I used the Left-Alt+Shift hotkey) you can make a map of the keys. The only significant drawback is the behavior of the quote character, since it is used to encode accent marks. It takes getting used to the quote+space behavior, or defining a macro key (hint, hint).
=Austin
Luke Palmer
> On 0, Rod Adams <r...@rodadams.net> wrote:
> >
> > Also, isn't it a pain to type all these characters when they are not on
> > your keyboard? As a predominately Win2k/XP user in the US, I see all
> > with it.
> >
> > Thoughts?
> >
> > -- Rod
> >
>
> Agreed. Cryptic, but in a different way than usual. I'd rather see
> plain old keywords as long as I'm typing things out or making that
> many key-strokes.
>
> sub each (*);
>
> each @arr += 3;
>
> each @arr += each @foo;
That would be a hard macro to write. Not impossible, of course :-)
I'm not sure it's a good idea to change the syntax just because Unicode
is unavailable. There was a definite reason for bundling the "each"
modifiers near the operator, and we'd be changing that. You also get
ambiguities regarding to which operator the C<each> applies if there is
more than one.
On the other hand, it does read quite wonderfully, unlike the seeming
alternative:
@arr each += each @foo;
What about just a function?
each(&infix:+= , @arr, @foo)
Such that the Unicode is the only way to get at the syntactic shortcut?
We've done a lot to make functions readable in a lot of ways. Indeed,
there are many ways the function could work. A function that operates
on alternating arguments may not be unhandy either:
each(&infix:+= , zip(@arr, @foo))
But that's getting pretty far away from what the operators originally
intended.
> Larry Wall suggested reading >> and << as "each".
>
> This would require a small comprimise on the p5 each. Or else it could be
> named "vector". Shouldn't be a problem with %hash.keys, %hash.values,
> %hash.each anyway.
Perl5 C<each> is going away anyway, in favor of the new construct:
for %hash.kv -> $k, $v {
...
}
> This wouldn't implement as an operator very well, admittedly, but more like
> a control keyword. It would seem closely related to foreach, though.
Which is also going away :-)
> What happens when there are a bunch of the puppies? Vectorizing operators
> do the right thing, working according to the rules of precedence. "each"
> would have to just share one iterator per statement, or else do ugly things
> to the rest of the statement. It would be very difficult to do something like:
>
> (each @foo + each @bar) + (each @baz + each @baz)
Don't worry about implementation. That's not our job.
It would probably be implemented as a macro that just put it back into
the Unicode notation.
> This would lend itself a P5 backport that did overload on its argument, too. If
> it found that the thing on the right hand side was also overloaded into the
> same class, it is could use a single iterator on both sides, otherwise it would
> treat the 2nd argument as a scalar. This would solve the "single iterator
> per line" problem for p5 atleast. It would work correctly. Any number of
> vectorized arrays could be floating around in an expression, each interacting
> with each other correctly.
Of course you mean "損interacting with束 other correctly." :-)
> Would it be possible to subclass things on the fly, returning a specialized
> object representing the argument that knew how to vectorize when asked to add?
> Aren't add, substract, multiply, and so on, implemented as class methods in
> Perl 6, much like Perl 5's overload module?
No! And I couldn't be happier! They're multimethods, dispatching based
on I<both> their arguments, not just the left one.
Luke
Luke Palmer
> Scott Walters writes:
> > This would lend itself a P5 backport that did overload on its argument, too. If
> > it found that the thing on the right hand side was also overloaded into the
> > same class, it is could use a single iterator on both sides, otherwise it would
> > treat the 2nd argument as a scalar. This would solve the "single iterator
> > per line" problem for p5 atleast. It would work correctly. Any number of
> > vectorized arrays could be floating around in an expression, each interacting
> > with each other correctly.
>
> Of course you mean "損interacting with束 other correctly." :-)
Grr! That ruined that joke! I'd better get this unicode thing figured
out before Perl 6 is released.
»interacting with« other correctly.
Luke
> > Would it be possible to subclass things on the fly, returning a specialized
> > object representing the argument that knew how to vectorize when asked to add?
> > Aren't add, substract, multiply, and so on, implemented às class methods in
Larry Wall
: Luke Palmer writes:
: > Of course you mean "損interacting with束 other correctly." :-)
:
: Grr! That ruined that joke! I'd better get this unicode thing figured
: out before Perl 6 is released.
:
: »interacting with« other correctly.
I dunno, "'loss' interacting with 'bundle'" was kind of funny too.
Larry
Jonathan Lang
> Scott Walters writes:
> > Would it be possible to subclass things on the fly, returning a
> > specialized object representing the argument that knew how to
> > overload module?
>
> No! And I couldn't be happier! They're multimethods, dispatching based
> on I<both> their arguments, not just the left one.
Exactly how far can we go without the "each" tags? We could define
multimethods for the standard operators such that if one or both of their
arguments are lists, they're treated as distributed functions, which would
cover a _lot_ of ground on its own. However, there's a problem with
extensibility: every time you add a new operator under this scheme, you'd
also have to add overloaded versions which implement the distribution
functionality or do without. I have a feeling that a large number of
programmers would rather do without than write the extra code if it came
down to that choice.
How about this: if an operator is declared using one or more scalar
parameters, and there's no defined alternative using list parameters in
their places, implicit "distributing operators" are made available by the
compiler. So:
multi sub infix:+ ($x, $y) {...}
would imply something like the existence of
multi sub infix:+ (@x, $y) {return $_ + $y for @x;}
multi sub infix:+ ($x, @y) {return $x + $_ for @y;}
multi sub infix:+ (@x, @y) {...}
(Yes, I know I abused the syntax for "return" and "for" above, and that it
wouldn't do what you'd expect it to at first glance. Maybe it should?)
Can you coerce a scalar value into a list? I'd love to be able to say
something like "5 x $x" and have perl interpret it as "($x, $x, $x, $x,
$x)" - or, better yet, take "5 x rand()" and get (rand(), rand(), rand(),
rand(), rand())". Combine this with the above: to add five random numbers
to the first five elements of a list, you'd say "@x + 5 x rand()". The
only drawback to this is that the "x" operator has already been claimed as
a string operation.
And, upon review, I'd rather _not_ have the core syntax of perl rely on
unicode; so no using × (or whatever it's called in Unicode) for
this. Unicode's fine for supplemental material; but until such time as
unicode keyboards are more widespread, I don't want to be forced to use
it.
==
Is there anything else that <<+>> can do that the above can't?
Luke Palmer
This was all discussed in Apocalypse 3. It's not happening, in
particular, because people like to do:
if $index < @array-1 {...}
It has been pointed out before: Polymorphic variables + polymorphic
operators = Bad Idea.
>
> Can you coerce a scalar value into a list? I'd love to be able to say
> something like "5 x $x" and have perl interpret it as "($x, $x, $x, $x,
> $x)"
You can do that. It looks like C<$x xx 5>.
> - or, better yet, take "5 x rand()" and get (rand(), rand(), rand(),
> rand(), rand())".
C<rand() xx 5> returns C<do { my $x = rand; ($x,$x,$x,$x,$x) }>.
> Combine this with the above: to add five random numbers
> to the first five elements of a list, you'd say "@x + 5 x rand()". The
> only drawback to this is that the "x" operator has already been claimed as
> a string operation.
>
> And, upon review, I'd rather _not_ have the core syntax of perl rely on
> unicode; so no using × (or whatever it's called in Unicode) for
> this. Unicode's fine for supplemental material; but until such time as
> unicode keyboards are more widespread, I don't want to be forced to use
> it.
Uh huh. Already been discussed. It ain't up for negotiation (it may
change, but it won't be from our direct influence).
> ==
>
> Is there anything else that <<+>> can do that the above can't?
No, but there's something that + can do that >>+<< can't, and that's why
the each operators have to be there.
Luke
Gordon Henriksen
> OTOH, Robin's concern for how to code when you're stuck with 7 bit
> ascii on the boot console of a Sun box remains valid, and *I* sure
> would rather have a short name available in a standard way.
Perhaps a solution is a cultural one, that it simply be a point of good
style for library authors to provide ASCII alternatives in the form of
multimethods. Then, at least, the alternative name will be pertinent to
the module.
—
Gordon Henriksen
mali...@mac.com
Austin Hastings
Agreed. And since the first such situation that P6 learners will encounter
is the built-in « and » operators, or the equally built-in « » quoting
delimiters, we get to be first, providing-a-good-ascii-alternative-wise.
From http://www.unicode.org/charts/PDF/U0080.pdf, we have:
00AB « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
= LEFT POINTING GUILLEMET
00BB » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
= RIGHT POINTING GUILLEMET
While quite descriptive, none of those really flows from the tongue.
I believe that we SHOULD accept either of those terms, with or without
hyphens, but not require them for ascii work. I'd much rather see E'<<' and
E'>>' as valid aliases. (Yes, this implies a change to POD, too. But it's a
good change.)
=Austin
Luke Palmer
Right. And we also need a way for users to provide ASCII alternatives
when they come across a rude module. But, in perl's tradition of
starting quoting constructs with q, perhaps it should be qe'' instead.
But that doesn't quite work with POD, unless pod changed to using qe,
which isn't all that nice.
But I think that literal >> and << are quite nice alternatives for » and
« [1], and if the only think that's holding us back is the bitshift
operators, we should kill them -- turn them into functions or something.
C<shl> and C<shr> aren't so bad, are they?
Or perhaps << and >> can be the quoters, and separate from « and ».
But I'm still sure that the unicode-deficient would rather write:
@a = @b >>+<< @c
Than
@a = @b E'>>'+E'<<' @c
Luke
[1] In fact, you'll probably find me writing them that way when they're
used as a quoting construct: I like << foo bar baz >> better than
«foo bar baz».
Luke
>
> =Austin
>
Luke Palmer
> But I think that literal >> and << are quite nice alternatives for » and
> « [1], and if the only think that's holding us back is the bitshift
> operators, we should kill them -- turn them into functions or something.
> C<shl> and C<shr> aren't so bad, are they?
Or named operators. As in:
$bits = ($high shl 4) +| $low;
Luke
Andy Wardley
> But I'm still sure that the unicode-deficient would rather write:
I suspect the unicode-deficient would rather write Ruby.
Adding unicode operators to Perl will just reinforce its reputation as
a "line noise" language.
I know it has been said before, and I'm sure it will be said again,
but this is a really bad idea, IMHO.
Sure, make Perl Unicode compliant, right down to variable and operator
names. But don't make people spend an afternoon messing around with mutt,
vim, emacs and all the other tools they use, just so that they can read,
write, email and print Perl programs correctly.
A
Simon Cozens
> Sure, make Perl Unicode compliant, right down to variable and operator
> names. But don't make people spend an afternoon messing around with mutt,
> vim, emacs and all the other tools they use, just so that they can read,
> write, email and print Perl programs correctly.
To be honest, I don't think that'll be a problem, but only because by the
time Perl 6 is widely deployed, people will have got themselves sorted out
as far as Unicode's concerned. I suspect similar things were said when C
decided to use 7 bit characters.
That doesn't mean I think Unicode operators are a good idea, of course.
--
"When in doubt, print 'em out."
-- Karl's Programming Proverb 0x7
Alex Burr
--- Andy Wardley <a...@andywardley.com> wrote:
> Adding unicode operators to Perl will just reinforce
> its reputation as
> a "line noise" language.
Perl6, the language with *real* runes.
Come to think of it, some of the ogham runes would
look more incharacter as a 'distribute' operator than
guillemets... :-)
More seriously, what about things live 'combining
characters', eg U20D0 (vector indication);
U0307 (derivative)?
Alex
John Macdonald
> a...@andywardley.com (Andy Wardley) writes:
> > Sure, make Perl Unicode compliant, right down to variable and operator
> > names. But don't make people spend an afternoon messing around with mutt,
> > vim, emacs and all the other tools they use, just so that they can read,
> > write, email and print Perl programs correctly.
>
> To be honest, I don't think that'll be a problem, but only because by the
> time Perl 6 is widely deployed, people will have got themselves sorted out
> as far as Unicode's concerned. I suspect similar things were said when C
> decided to use 7 bit characters.
Don't be so sure. I've been seeing the << and >>
characters properly sometimes, as ??? sometimes,
and I think there were some other variants (maybe for
other extended characters) - depending upon whether
I'm reading the messages locally at home or remotely
through a terminal emulator. Those emulators are
not about to be replaced for any other reason in the
near future.
I'll be able to work it out if I have to, but it'll
be an annoyance, and probably one that shows up
many times with different bits of software, and
often those bits will not be under my control and
will have to be worked around rather than "fixed".
(In the canine-ical sense, it is the current software
that is "fixed", i.e. it has limited functionality.)
> That doesn't mean I think Unicode operators are a good idea, of course.
They will cause problems for sure.
Luke Palmer
> --- Andy Wardley <a...@andywardley.com> wrote:
>
> > Adding unicode operators to Perl will just reinforce
> > its reputation as
> > a "line noise" language.
>
> Perl6, the language with *real* runes.
>
> Come to think of it, some of the ogham runes would
> look more incharacter as a 'distribute' operator than
> guillemets... :-)
>
> More seriously, what about things live 'combining
> characters', eg U20D0 (vector indication);
> U0307 (derivative)?
Those are fair game for modules, but they won't be in the core because
they're not in latin-1.
Luke
Larry Wall
: On Mon, Feb 02, 2004 at 09:59:50AM +0000, Simon Cozens wrote:
: > a...@andywardley.com (Andy Wardley) writes:
: > > Sure, make Perl Unicode compliant, right down to variable and operator
: > > names. But don't make people spend an afternoon messing around with mutt,
: > > vim, emacs and all the other tools they use, just so that they can read,
: > > write, email and print Perl programs correctly.
: >
: > To be honest, I don't think that'll be a problem, but only because by the
: > time Perl 6 is widely deployed, people will have got themselves sorted out
: > as far as Unicode's concerned. I suspect similar things were said when C
: > decided to use 7 bit characters.
:
: Don't be so sure. I've been seeing the << and >>
: characters properly sometimes, as ??? sometimes,
: and I think there were some other variants (maybe for
: other extended characters) - depending upon whether
: I'm reading the messages locally at home or remotely
: through a terminal emulator. Those emulators are
: not about to be replaced for any other reason in the
: near future.
Well, sure. But what we're trying to optimize here is specifically
not the near future.
: I'll be able to work it out if I have to, but it'll
: be an annoyance, and probably one that shows up
: many times with different bits of software, and
: often those bits will not be under my control and
: will have to be worked around rather than "fixed".
: (In the canine-ical sense, it is the current software
: that is "fixed", i.e. it has limited functionality.)
:
: > That doesn't mean I think Unicode operators are a good idea, of course.
:
: They will cause problems for sure.
No question about that. But Unicode is addressing (or attempting
to address) a basic unreducable complexity of the world, and I'm not
willing to sweep that complexity under someone else's carpet for
the purposes of short-term anaesthesia. I expect that over the long
term people will learn to use Unicode in moderation, after a short
period of (over)exuberant experimentation.
As a temporary measure (where temporary is measured in years), I'd
suggest Unicode declarations include an C<is ASCII('!@#$')> trait.
Larry
Larry Wall
Yes, that's the policy, at least for 6.0.0. Once everyone's on the
Unicode bandwagon (I realize we're talking years here), we can think
about relaxing that.
That being said, we can potentially use × U+00D7 MULTIPLICATION SIGN.
(Though my vim can't seem to decide whether it's a single-width or a
double-width character, urgh...)
By the way here's a program called "uni" that greps the Unicode characters:
#!/usr/bin/perl
binmode STDOUT, ":utf8";
$pat = "@ARGV";
@names = split /^/, do 'unicore/Name.pl';
for (@names) {
if (/$pat/io) {
$hex = hex($_);
print chr($hex),"\t",$_;
}
}
Sorry if I posted that before, but it's a really useful little beastie.
Larry
David Wheeler
> That being said, we can potentially use × U+00D7 MULTIPLICATION SIGN.
> (Though my vim can't seem to decide whether it's a single-width or a
> double-width character, urgh...)
I realize this is a tad OT, but can anyone tell me how I can get Emacs
to properly display Unicode characters? I expect that others on the
list could benefit, too.
Cheers,
David
David Wheeler
>> I realize this is a tad OT, but can anyone tell me how I can get Emacs
>> to properly display Unicode characters? I expect that others on the
>> list could benefit, too.
>
> (require 'un-define)
Since I really don't understand Lisp, and since that simply didn't
work, I'm going to assume it was some kind of joke. :-) Am I right?
David
David Wheeler
> No joke. You'll need to have the "mule-ucs" module installed.
> A quick Google search turns up plenty of sources.
Oh, I have Emacs 21.3.50. Mule is gone.
> You'll also need to have the appropriate fonts installed, of
> course.
> You may need to set your $LANG environment variable to a suitable value
> (I use "en_US.UTF-8").
I'm on Mac OS X. The fonts I use show most Unicode characters correctly
when I use them in TextEdit...
Thanks,
David
Kurt Starsinic
No joke. You'll need to have the "mule-ucs" module installed.
A quick Google search turns up plenty of sources.
You'll also need to have the appropriate fonts installed, of course.
You may need to set your $LANG environment variable to a suitable value
(I use "en_US.UTF-8").
- Kurt
Kurt Starsinic
> On Feb 3, 2004, at 7:13 AM, Kurt Starsinic wrote:
>
> > No joke. You'll need to have the "mule-ucs" module installed.
> >A quick Google search turns up plenty of sources.
>
> Oh, I have Emacs 21.3.50. Mule is gone.
I'm afraid you're on your own, then. I'm using 21.3.1. If you
work it out, please post.
- Kurt
Smylers
read some of these a couple of weeks ago but didn't want to reply till
I'd read the entire thread, then I was away a bit ...]
Larry Wall writes:
> On the other hand, it's possible that we should extend the visual
> metaphor of 猾 and apply it asymmetrically when one of the arguments
> is expected to be scalar.
The more I've thought about this since you suggested it, the more sense
it makes.
Smylers
Smylers
> Larry mused:
>
> > ... I don't think people would be terribly pleased when they see
> > things like:
> >
> > @a »+<<« @b
>
> > [it] would certainly motivate people to move toward editors and
> > terminals that can display:
> >
> > @a »+<<« @b
>
> Yes, it would be an excellent motivation in that direction. But, then,
> so would *not* providing any ASCII-based alternative in the first
> place.
If we go that far it will just put people off completely. Providing
people with an easy upgrade path is good motivation; purposefully making
life hard for un-upgraded people can be counter-productive: people can
take offence at it, or dismiss Perl 6 as elitist and impractical, or ...
Also I note that Luke Palmer recently wrote:
> Luke Palmer writes:
> > Scott Walters writes:
> > > This would lend itself a P5 backport that did overload on its
> > > argument, too. If it found that the thing on the right hand side
> > > was also overloaded into the same class, it is could use a single
> > > iterator on both sides, otherwise it would treat the 2nd argument
> > > as a scalar. This would solve the "single iterator per line"
> > > problem for p5 atleast. It would work correctly. Any number of
> > > vectorized arrays could be floating around in an expression, each
> > > interacting with each other correctly.
> >
> > Of course you mean "?interacting with? other correctly." :-)
>
> Grr! That ruined that joke! I'd better get this unicode thing figured
> out before Perl 6 is released.
>
> »interacting with« other correctly.
If Luke can't easily get it right, I'm not convinced other people will
bother ..
Smylers
Smylers
> With Larry's new "vectorized sides" suggestion, putting a guillemot on
> the right side of the operator ...
Austin, we've been through this before -- kindly return that guillemot
to wherever you picked it up from. It's hassle enough having unicode in
Perl, without us all having to set up wildlife-aware editors too.
According to 'The Oxford Minidictionary' a guillemot is "a kind of auk",
which is off-topic for this mailing list. (Not to be confused with "a
kind of Awk", which of course would be on-topic ...)
Smylers
Smylers
> On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
>
> : Larry Wall writes:
> :
> : > On the other hand, we've renamed all the other bitwise operators,
> : > so maybe we should rename these too:
> : >
> : > +< bitwise left shift
> : > +> bitwise right shift
> :
> : I could have sworn we already did that. I thought they were:
> :
> : +<<
> : +>>
>
> Yeah, I kinda wondered if we'd done that already.
The most-recent of MikeL's operator lists on Google Groups still has
them in the Perl 5 versions:
But the message from Andrew Wilson in that thread suggests the versions
that Larry does above.
> ... It's almost getting to the point where we want to allow
> disambiguating underscores in operators: >>_+<_<<. Alternately we
> give up on <<>> as a qw// replacement and allow spaces: >> +< <<.
How about going back to what you originally decreed in Apocalypse 2,
that the replacement for:
qw<Statler Waldorf>
will simply be:
<Statler Waldorf>
I think your reasoning, that using up a perfectly good set of brackets
for input is a waste, still stands. It's also among the things people
new to Perl find the most confusing, compared to an explicitly named
function or method that they might expect for input; I don't think
there'd be the same problem with something called C<read> or C<get> or
C<getline> or C<input> or C<from> or C<line> or C<chunk> or C<data>.
You describe as "likely" that in common situations no operator or
function name will be needed anyway -- do you still think that's the
case?
(I also note that if people are really attached to the special case of
empty C<< <> >> meaning 'read from files named in C<@ARG> or from stdin
if C<@ARG> is empty', that could be left in, since it doesn't at all
conflict with putting something inside the pointies to quote them. But
I'm still not keen on that.)
Or how about using backticks for quoting words:
my @person = `Statler Waldorf`;
Running shell commands and retrieving their output is also fairly rare,
and doesn't really need special quote-symbol-using operator --
especially when compared to the C<system> command, which manages to do
something quite similar as a mere named function. (Having them both as
named functions might also reduce the incidences of people grabbing the
command's output when they didn't mean to.)
> But we also have the ambiguity with <<'' and friends, so maybe the
> real problem is trying to make the << and >> workarounds look too much
> like « and ». Maybe they should be :<< and :>> or some such. Maybe
> we should be thinking about a more general trigraph (shudder) policy.
If you go along those lines then implementing (some of) those in RFC1345
would at least avoid inventing yet another set of symbols. They are
reasonably mnemonic ("<<" does indeed stand for "«"), so you'd only need
to pick designate the colon (or backtick or whatever) as the
digraph-designator and what follows is anything in that RFC.
That also has the advantage that 'Vim' users only need to learn one set
of mappings from digraphs to non-Ascii characters, thereby providing a
memorable upgrade path: people without the appropriate symbols have to
learn to type things such as these in Perl:
:<<
:*X
:.M
if they upgrade their terminal/fonts/whatever then they can now insert
the actual characters, and they can use the digraphs they've already
learnt, simply pressing Ctrl+K instead of colon:
Ctrl+K << «
Ctrl+K *X ×
Ctrl+K .M ·
I of course realize that not everybody uses 'Vim', but it is an RFC, and
possibly in use elsewhere too.
Smylers
Luke Palmer
> > ... It's almost getting to the point where we want to allow
> > disambiguating underscores in operators: >>_+<_<<. Alternately we
> > give up on <<>> as a qw// replacement and allow spaces: >> +< <<.
>
> How about going back to what you originally decreed in Apocalypse 2,
> that the replacement for:
>
> qw<Statler Waldorf>
>
> will simply be:
>
> <Statler Waldorf>
>
> I think your reasoning, that using up a perfectly good set of brackets
> for input is a waste, still stands. It's also among the things people
> new to Perl find the most confusing, compared to an explicitly named
> function or method that they might expect for input; I don't think
> there'd be the same problem with something called C<read> or C<get> or
> C<getline> or C<input> or C<from> or C<line> or C<chunk> or C<data>.
I feel uneasy about that. <foo> is not just input, it's iteration. You
say <$iter> to grab the next element of the iterator (or all remaining
elements in list context). Using C<read> for that would be more than a
little awkward.
> You describe as "likely" that in common situations no operator or
> function name will be needed anyway -- do you still think that's the
> case?
>
> (I also note that if people are really attached to the special case of
> empty C<< <> >> meaning 'read from files named in C<@ARG> or from stdin
> if C<@ARG> is empty', that could be left in, since it doesn't at all
> conflict with putting something inside the pointies to quote them. But
> I'm still not keen on that.)
>
> Or how about using backticks for quoting words:
>
> my @person = `Statler Waldorf`;
>
> Running shell commands and retrieving their output is also fairly rare,
> and doesn't really need special quote-symbol-using operator --
> especially when compared to the C<system> command, which manages to do
> something quite similar as a mere named function. (Having them both as
> named functions might also reduce the incidences of people grabbing the
> command's output when they didn't mean to.)
Hmm. Although I love the visual appeal of << quote words >>, this would
be pretty nice for keeping from overloading << >> too much. And then
spaces would be allowed around hyper operators, which is a huge plus.
I'm starting to reconsider my position on Larry's proposal, though. The
one-sided hyper operators are nice, but they don't buy us anything
semantically (being disambiguatable with a unary + most of the time).
And while they "feel good" syntactically, they seem to complicate
matters -- matters most everyone was liking -- into oblivion.
It's also something to note that for a language which allows you to make
your own operators, it has an extremely brittle syntax. I don't think
any of us want what "fixing" that will do.
> > But we also have the ambiguity with <<'' and friends, so maybe the
> > real problem is trying to make the << and >> workarounds look too much
> > like « and ». Maybe they should be :<< and :>> or some such. Maybe
> > we should be thinking about a more general trigraph (shudder) policy.
>
> If you go along those lines then implementing (some of) those in RFC1345
> would at least avoid inventing yet another set of symbols. They are
> reasonably mnemonic ("<<" does indeed stand for "«"), so you'd only need
> to pick designate the colon (or backtick or whatever) as the
> digraph-designator and what follows is anything in that RFC.
>
> That also has the advantage that 'Vim' users only need to learn one set
> of mappings from digraphs to non-Ascii characters, thereby providing a
> memorable upgrade path: people without the appropriate symbols have to
> learn to type things such as these in Perl:
>
> :<<
> :*X
> :.M
>
> if they upgrade their terminal/fonts/whatever then they can now insert
> the actual characters, and they can use the digraphs they've already
> learnt, simply pressing Ctrl+K instead of colon:
>
> Ctrl+K << «
> Ctrl+K *X ×
> Ctrl+K .M ·
>
> I of course realize that not everybody uses 'Vim', but it is an RFC, and
> possibly in use elsewhere too.
Everyone who counts uses vim :-)
Luke
Scott Walters
behind squeeky wheels. Makes it harder to evaluate arguments for their
merits by clogging the filters. Okey, enough metaphores.
On 0, Luke Palmer <fibo...@babylonia.flatirons.org> wrote:
>
> > Agreed. Cryptic, but in a different way than usual. I'd rather see
> > plain old keywords as long as I'm typing things out or making that
> > many key-strokes.
> >
> > sub each (*);
> >
> > each @arr += 3;
> >
> > each @arr += each @foo;
>
> That would be a hard macro to write. Not impossible, of course :-)
>
> I'm not sure it's a good idea to change the syntax just because Unicode
> is unavailable. There was a definite reason for bundling the "each"
> modifiers near the operator, and we'd be changing that. You also get
> ambiguities regarding to which operator the C<each> applies if there is
> more than one.
>
> On the other hand, it does read quite wonderfully, unlike the seeming
> alternative:
>
> @arr each += each @foo;
>
> What about just a function?
>
> each(&infix:+= , @arr, @foo)
>
> Such that the Unicode is the only way to get at the syntactic shortcut?
> We've done a lot to make functions readable in a lot of ways. Indeed,
> there are many ways the function could work. A function that operates
> on alternating arguments may not be unhandy either:
I really like this too. It is like Lisp's special forms: "apply operator to data
in interesting way". It opens the door for numerous other operations in
a generic system. Maybe Damian will champion this for us =)
Taken to an ugly extreme, it could look like the correlation I wrote for
AI::FuzzyLogic, where sets permutate, correlate, or aggregate. Creating a framework
where this can exist outside of core prevents something horrid from being
suggested for core =)
>
> each(&infix:+= , zip(@arr, @foo))
>
> But that's getting pretty far away from what the operators originally
> intended.
This isn't very far away from map when used on built-ins.
@foo = map &infix:*, zip(@foo, @bar);
map -> $a is rw, $b { $a *= $b }, zip @foo, @bar; # except that zip would copy in all probability
each() as a map type operator that applies operators (and other closures), modifying
the LHS, covers what people want to do with vectorized operators and covers
gaps in map.
So, in summary, I really like Luke's proposal.
-scott
>
> > Larry Wall suggested reading >> and << as "each".
> >
> > This would require a small comprimise on the p5 each. Or else it could be
> > named "vector". Shouldn't be a problem with %hash.keys, %hash.values,
> > %hash.each anyway.
>
> Perl5 C<each> is going away anyway, in favor of the new construct:
>
> for %hash.kv -> $k, $v {
> ...
> }
>
> > This wouldn't implement as an operator very well, admittedly, but more like
> > a control keyword. It would seem closely related to foreach, though.
>
> Which is also going away :-)
>
> > What happens when there are a bunch of the puppies? Vectorizing operators
> > do the right thing, working according to the rules of precedence. "each"
> > would have to just share one iterator per statement, or else do ugly things
> > to the rest of the statement. It would be very difficult to do something like:
> >
> > (each @foo + each @bar) + (each @baz + each @baz)
>
> Don't worry about implementation. That's not our job.
>
> It would probably be implemented as a macro that just put it back into
> the Unicode notation.
>
> > This would lend itself a P5 backport that did overload on its argument, too. If
> > it found that the thing on the right hand side was also overloaded into the
> > same class, it is could use a single iterator on both sides, otherwise it would
> > treat the 2nd argument as a scalar. This would solve the "single iterator
> > per line" problem for p5 atleast. It would work correctly. Any number of
> > vectorized arrays could be floating around in an expression, each interacting
> > with each other correctly.
>
> Of course you mean "損interacting with束 other correctly." :-)
>
> > Would it be possible to subclass things on the fly, returning a specialized
> > object representing the argument that knew how to vectorize when asked to add?
> > Aren't add, substract, multiply, and so on, implemented as class methods in
> > Perl 6, much like Perl 5's overload module?
>
> No! And I couldn't be happier! They're multimethods, dispatching based
> on I<both> their arguments, not just the left one.
>
> Luke