Re: Semantics of vector operations
Warning: spacey, tangential semi-argument ahead.
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, 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.
%-)
> : 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;
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 Â+=Â [EMAIL PROTECTED]
? 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
Re: Semantics of vector operations
* Larry Wall <[EMAIL PROTECTED]> [2004-01-21 01:44]: > 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."
Re: Semantics of vector operations
On Tue, Jan 20, 2004 at 11:06:13PM -0500, Austin Hastings wrote: : 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 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
Re: Semantics of vector operations
On Wed, Jan 21, 2004 at 03:21:01PM +0100, A. Pagaltzis wrote: : 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
Re: Comma Operator
On Tue, Jan 20, 2004 at 08:12:28PM -0800, Jonathan Lang wrote: : Joe Gottman wrote: : >About a month ago, a thread here suggested that we change the meaning : > of the comma operator. Currently, in scalar context the expression : > foo(), bar() : > means "evaluate foo(), discard the result, then return the value of : > bar()". : > It was suggested that this be changed to return the 2-element array : > (foo(), bar()). Has Larry ruled on this yet? : : Not that I'm aware of. For the most part, the previous discussion was : focusing on what to replace the comma with in the case of "discard all but : the last result", and my impression was that any ruling on the change : would likely be contingent on the presence or absence of a suitable : replacement. I'm a little frustrated because I feel like I've ruled on it several times, but it never seems to "stick". I guess that's because it was never ruled in an Apocalypse, just in email. But I'm sure I'm on the record somewhere saying that I think [-1] is sufficient to pick out the last element of a list. If nothing else, just a couple of days ago, but I'm sure I also said it more than once in ancient times. : That said, : : > By the way, even if we do make this change, I think that in void : > context the expression : > foo(), bar() : > should still simply evaluate its parameters in order for their side- : > effects. This would allow comma expressions to remain as-is in loop : > statements (formerly for statements), which is where most of them are : > found anyway. : : I do like this suggestion. In the majority of cases where I've used the : comma operator, I've either enclosed the whole thing in parentheses to : turn it into a list, or I've treated it as a sequence of operators where : even the last result got discarded. I've rarely been interested in just : the last result, and I wouldn't mind that functionality being provided by : means of a C function which evaluates the list parameters for their : side effects and returns the value of the last list parameter. Well, a C function (or method) would be redundant with [-1], though I'm not totally opposed to redundancy. ["You can say that again."] Larry
Re: Semantics of vector operations
> "LW" == Larry Wall <[EMAIL PROTECTED]> 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 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 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 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 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 -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
RE: Semantics of vector operations
> -Original Message- > From: Larry Wall [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 21, 2004 2:33 PM > To: Language List > Subject: Re: Semantics of vector operations > > > On Wed, Jan 21, 2004 at 03:21:01PM +0100, A. Pagaltzis wrote: > : 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. > Perhaps the right way to vectorize the arguments is to delimit them with vectorization markers? @a + >>$b<< =Austin
Re: Semantics of vector operations
Uri Guttman <[EMAIL PROTECTED]> writes: >> "LW" == Larry Wall <[EMAIL PROTECTED]> 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 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 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 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
Re: Semantics of vector operations
On Wed, Jan 21, 2004 at 04:01:43PM -0500, Austin Hastings wrote: > 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.
Re: Comma Operator
- Original Message - From: "Larry Wall" <[EMAIL PROTECTED]> To: "Perl6" <[EMAIL PROTECTED]> Sent: Wednesday, January 21, 2004 2:51 PM Subject: [perl] Re: Comma Operator > On Tue, Jan 20, 2004 at 08:12:28PM -0800, Jonathan Lang wrote: > : Joe Gottman wrote: > : >About a month ago, a thread here suggested that we change the meaning > : > of the comma operator. Currently, in scalar context the expression > : > foo(), bar() > : > means "evaluate foo(), discard the result, then return the value of > : > bar()". > : > It was suggested that this be changed to return the 2-element array > : > (foo(), bar()). Has Larry ruled on this yet? > : > : Not that I'm aware of. For the most part, the previous discussion was > : focusing on what to replace the comma with in the case of "discard all but > : the last result", and my impression was that any ruling on the change > : would likely be contingent on the presence or absence of a suitable > : replacement. > > I'm a little frustrated because I feel like I've ruled on it several > times, but it never seems to "stick". I guess that's because it was > never ruled in an Apocalypse, just in email. But I'm sure I'm on > the record somewhere saying that I think [-1] is sufficient to pick > out the last element of a list. If nothing else, just a couple of > days ago, but I'm sure I also said it more than once in ancient times. > Great, so $x = foo(), bar(); means the same thing as $x = ( foo(), bar() ); Is the optimizer going to be smart enough so that given the expression $x = (foo(), bar(), glarch())[-1]; Perl6 won't have to construct a three-element array just to return the last element? Joe Gottman
Re: Semantics of vector operations
* Larry Wall <[EMAIL PROTECTED]> [2004-01-21 20:35]: > 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. -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Semantics of vector operations
* Piers Cawley <[EMAIL PROTECTED]> [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++ ? :) -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Semantics of vector operations
Gah. Not a good combination do heavy editing and insufficient proofreading make. * A. Pagaltzis <[EMAIL PROTECTED]> [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 > 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. -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
