Re: Semantics of vector operations (Damian)
On Mon, Jun 14, 2004 at 06:05:10PM -0400, Mark J. Reed wrote:
:
: On 2004-06-14 at 22:58:58, Matthew Walton wrote:
: > 'it would be better to explicitly just say
: >
: > (@list.grep value) = undef
: >
: > although I think that might be supposed to be
: >
: > (@list.grep value) »= undef;
:
: Those do different things according to my understanding. The first
: removes all matching items from the list; the second replaces the
: matching items with undef.
:
: e.g. (please forgive any Perl6 syntax errors):
:
: [1,2,3,4,5].grep { $_ % 2 } = undef
:
: results in the list
:
: [2,4]
:
: while
:
: [1,2,3,4,5].grep { $_ % 2 } »= undef
:
: results in the list
:
: [undef, 2, undef, 4, undef]
Er, no. Assignment of undef to a scalar value does not imply that it
is deleted from its current location (or locations). Scalars don't
necessarily even know what their locations are. Deletions are necessarily
a transaction with the container object, and by the time you've done a
grep, you've thrown away the reference to the container object. Even
if that were not the case (and a grep method could certainly be taught
to be an lvalue), assigning undef would at most undefine the selected
scalar values in place, because undef is a scalar value, not a list,
and because all of these are the same value as far as list assignment
is concerned:
()
(undef)
(undef, undef)
(undef, undef, undef)
...
I think you're looking for something more like
@list.=grep { not $_ % 2 };
But it doesn't make much sense to do that to an anonymous list.
Larry
Re: Semantics of vector operations (Damian)
Well, I'd speak up
for intentionally allowing some silly alternatives
except that's IMO unnecessary.
With all the apparently-wonderful new possibilities
which we'll soon have
(OK, maybe not as soon as we'd like),
it seems most likely
that some will turn out to be silly.
George "tim toady"
On Monday 14 June 2004 2:58 pm, Matthew Walton wrote:
> Austin Hastings wrote:
> > Perhaps we could consider the junctive lvalues as a sort of implied
> > ?= operation:
> >
> >junction(@list) = value
> >
> > means
> >
> >unless junction(@list) == value
> >{
> > given junction {
> > when 'none' { (@list.grep value) = undef; }
> > when 'any' { for 0 .. random(@list) { @list[random(@list)] =
> > undef; } }
> > when 'one' { @list[random(@list)] = undef; }
> > when 'all' { @list = $(@list) x undef; }
> > }
> >}
> >
> > (which would make for some interesting use cases around 'any', at least
> > ;-)
>
> This is extremely scary. The thought of anybody actually using 'any' in
> their code is... umm... well, let's just say the Haskell programmer me
> is curling up in fright and screaming his head off, because the idea is
> entirely abhorrent to him. Gadget Matthew says it's a substanceless
> 'wow' feature. Both are also skeptical about 'one', and my psychiatrist
> is rattling pill bottles.
>
> 'none' could be useful, but it would be better to explicitly just say
>
> (@list.grep value) = undef
>
> although I think that might be supposed to be
>
> (@list.grep value) »= undef;
>
> as shouldn't list.grep return a list of matches? Which we assume are
> aliases to the original elements.
>
> I'm with Damian. TMTOWTDI yes, but there's a line between 'nice to have
> the alternative' and 'silly'.
>
> Oh, and the example appears to have forgotten that only 'none' should be
> assigning undef, the rest should be assigning value - shouldn't they? I
> think they should, otherwise it doesn't make any sense at all. Or
> perhaps it does, and I need to go to bed.
>
> Ciao.
Re: Semantics of vector operations (Damian)
Mark J. Reed wrote:
On 2004-06-14 at 22:58:58, Matthew Walton wrote:
'it would be better to explicitly just say
(@list.grep value) = undef
although I think that might be supposed to be
(@list.grep value) »= undef;
Those do different things according to my understanding. The first
removes all matching items from the list; the second replaces the
matching items with undef.
e.g. (please forgive any Perl6 syntax errors):
[1,2,3,4,5].grep { $_ % 2 } = undef
results in the list
[2,4]
while
[1,2,3,4,5].grep { $_ % 2 } »= undef
results in the list
[undef, 2, undef, 4, undef]
That's a very good point, and seems rather likely. I wasn't thinking of
it that way. Quite cunning really.
Re: Semantics of vector operations (Damian)
On 2004-06-14 at 22:58:58, Matthew Walton wrote:
> 'it would be better to explicitly just say
>
> (@list.grep value) = undef
>
> although I think that might be supposed to be
>
> (@list.grep value) »= undef;
Those do different things according to my understanding. The first
removes all matching items from the list; the second replaces the
matching items with undef.
e.g. (please forgive any Perl6 syntax errors):
[1,2,3,4,5].grep { $_ % 2 } = undef
results in the list
[2,4]
while
[1,2,3,4,5].grep { $_ % 2 } »= undef
results in the list
[undef, 2, undef, 4, undef]
-Mark
Re: Semantics of vector operations (Damian)
Austin Hastings wrote:
Perhaps we could consider the junctive lvalues as a sort of implied
?= operation:
junction(@list) = value
means
unless junction(@list) == value
{
given junction {
when 'none' { (@list.grep value) = undef; }
when 'any' { for 0 .. random(@list) { @list[random(@list)] =
undef; } }
when 'one' { @list[random(@list)] = undef; }
when 'all' { @list = $(@list) x undef; }
}
}
(which would make for some interesting use cases around 'any', at least
;-)
This is extremely scary. The thought of anybody actually using 'any' in
their code is... umm... well, let's just say the Haskell programmer me
is curling up in fright and screaming his head off, because the idea is
entirely abhorrent to him. Gadget Matthew says it's a substanceless
'wow' feature. Both are also skeptical about 'one', and my psychiatrist
is rattling pill bottles.
'none' could be useful, but it would be better to explicitly just say
(@list.grep value) = undef
although I think that might be supposed to be
(@list.grep value) »= undef;
as shouldn't list.grep return a list of matches? Which we assume are
aliases to the original elements.
I'm with Damian. TMTOWTDI yes, but there's a line between 'nice to have
the alternative' and 'silly'.
Oh, and the example appears to have forgotten that only 'none' should be
assigning undef, the rest should be assigning value - shouldn't they? I
think they should, otherwise it doesn't make any sense at all. Or
perhaps it does, and I need to go to bed.
Ciao.
Re: Semantics of vector operations (Damian)
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Date: Wed, 28 Jan 2004 12:34:15 +1100
> From: "Damian Conway" <[EMAIL PROTECTED]> Add to Address Book
> To: "Language List" <[EMAIL PROTECTED]>
>Subject: Re: Semantics of vector operations (Damian)
Messages are *not* guaranteed to arrive in the order sent, but boy,
this seems harsh!
> I have trouble with junctive lvalues because I think they lead to
> unexpected/unpredictable behaviour. For example, the "predicate"
> associated with a junction is only invoked when that junction is
> involved in a boolean test of some kind, so the (hypothetical):
>
> all($x, $y, $z) = 1;
> any($x, $y, $z) = 1;
> one($x, $y, $z) = 1;
> none($x, $y, $z) = 1;
>
> would (hypothetically) all do the same thing (i.e. independently
> assign 1 to each of the three scalar variables).
> That makes the last three versions nothing but obfuscatory in
> my view.
Perhaps we could consider the junctive lvalues as a sort of implied
?= operation:
junction(@list) = value
means
unless junction(@list) == value
{
given junction {
when 'none' { (@list.grep value) = undef; }
when 'any' { for 0 .. random(@list) { @list[random(@list)] =
undef; } }
when 'one' { @list[random(@list)] = undef; }
when 'all' { @list = $(@list) x undef; }
}
}
(which would make for some interesting use cases around 'any', at least
;-)
=Austin
>
> So, at very best, we'd have to restrict lvalue junctions to
> conjunctions.
>
> And there seems to be very little benefit even in that restricted
> form,
> especially when you consider that:
>
> all($x, $y, $z) = 1;
> all(@foo) = 2;
>
> are hardly any better than the existing solutions:
>
> $x = $y = $z = 1;
> $_ = 2 for @foo;
>
> and no better at all than the Perl 6 distributive solutions:
>
> ($x, $y, $z) »= 1;
> @foo »= 2;
>
> So, on balance, I feel that lvalue junctions are more trouble than
> they're worth.
>
>
> Damian
>
>
>
>
>
Re: Semantics of vector operations (Damian)
Scott wrote: I'm just waiting for Damian to speak up :-) I'm not at all comfortable with the notion of junctions as lvalues. I've *always* considered a junction to be a special kind of constant, just as a number or a string or a reference is. I have trouble with junctive lvalues because I think they lead to unexpected/unpredictable behaviour. For example, the "predicate" associated with a junction is only invoked when that junction is involved in a boolean test of some kind, so the (hypothetical): all($x, $y, $z) = 1; any($x, $y, $z) = 1; one($x, $y, $z) = 1; none($x, $y, $z) = 1; would (hypothetically) all do the same thing (i.e. independently assign 1 to each of the three scalar variables). That makes the last three versions nothing but obfuscatory in my view. So, at very best, we'd have to restrict lvalue junctions to conjunctions. And there seems to be very little benefit even in that restricted form, especially when you consider that: all($x, $y, $z) = 1; all(@foo) = 2; are hardly any better than the existing solutions: $x = $y = $z = 1; $_ = 2 for @foo; and no better at all than the Perl 6 distributive solutions: ($x, $y, $z) »= 1; @foo »= 2; So, on balance, I feel that lvalue junctions are more trouble than they're worth. Damian
Re: Semantics of vector operations
This is still raging. I was going to let it slide. I hate the mechanics
behind squeeky wheels. Makes it harder to evaluate arguments for their
merits by clogging the filters. Okey, enough metaphores.
On 0, Luke Palmer <[EMAIL PROTECTED]> 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 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 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 their arguments, not just the left one.
>
> Luke
Re: Semantics of vector operations
Smylers writes:
> > ... 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
>
> will simply be:
>
>
>
> 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 or C or
> C or C or C or C or C or C.
I feel uneasy about that. 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 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 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
Re: Semantics of vector operations
Damian Conway writes: > 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
Re: Semantics of vector operations
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 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: http://xrl.us/perl6ops6 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 will simply be: 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 or C or C or C or C or C or C or C. 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 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
Re: Semantics of vector operations (Damian)
Austin Hastings writes: > 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
Re: Semantics of vector operations
[Apologies for the delay in responding to this (and other) messages -- I 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
Re: Semantics of vector operations
On Feb 02, David Wheeler wrote: > On Feb 2, 2004, at 9:53 PM, Kurt Starsinic wrote: > > >>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? 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
Re: Semantics of vector operations
On Feb 2, 2004, at 9:53 PM, Kurt Starsinic wrote: 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
Re: Semantics of vector operations
On Feb 2, 2004, at 5:20 PM, Larry Wall wrote: 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
Re: Semantics of vector operations
On Mon, Feb 02, 2004 at 11:44:17AM -0700, Luke Palmer wrote:
: Alex Burr writes:
: > --- Andy Wardley <[EMAIL PROTECTED]> 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.
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
Re: Semantics of vector operations
On Mon, Feb 02, 2004 at 01:14:48PM -0500, John Macdonald wrote: : On Mon, Feb 02, 2004 at 09:59:50AM +, Simon Cozens wrote: : > [EMAIL PROTECTED] (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 trait. Larry
Re: Semantics of vector operations
Alex Burr writes: > --- Andy Wardley <[EMAIL PROTECTED]> 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
Re: Semantics of vector operations
On Mon, Feb 02, 2004 at 09:59:50AM +, Simon Cozens wrote: > [EMAIL PROTECTED] (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.
Re: Semantics of vector operations
--- Andy Wardley <[EMAIL PROTECTED]> 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 __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Re: Semantics of vector operations
[EMAIL PROTECTED] (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. 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
Re: Semantics of vector operations
Luke Palmer wrote: > 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
Re: Semantics of vector operations
I wrote: > 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 and C aren't so bad, are they? Or named operators. As in: $bits = ($high shl 4) +| $low; Luke
Re: Semantics of vector operations
Austin Hastings writes: > > -Original Message- > > From: Gordon Henriksen [mailto:[EMAIL PROTECTED] > > Austin Hastings wrote: > > > > > 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. > > 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.) 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 and C 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 >
RE: Semantics of vector operations
> -Original Message- > From: Gordon Henriksen [mailto:[EMAIL PROTECTED] > Austin Hastings wrote: > > > 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. 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
Re: Semantics of vector operations
Austin Hastings wrote: 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 [EMAIL PROTECTED]
Re: Semantics of vector operations
Jonathan Lang writes:
> Luke Palmer wrote:
> > Scott Walters writes:
> > > 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, subtract, 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 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?)
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 returns C.
> 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
Re: Semantics of vector operations
Luke Palmer wrote:
> Scott Walters writes:
> > 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, subtract, 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 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?
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
Re: Semantics of vector operations
On Fri, Jan 30, 2004 at 06:55:39AM -0700, Luke Palmer wrote: : 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
Re: Semantics of vector operations
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. 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 > > Perl 6, much like Perl 5's overload module? > > No! And I couldn't be happier! They're multimethods, dispatching based > on I their arguments, not just the left one. > > Luke
Re: Semantics of vector operations
Scott Walters writes:
> On 0, Rod Adams <[EMAIL PROTECTED]> 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
> > 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 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;
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 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 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 their arguments, not just the left one.
Luke
Re: Unicode under Windows (was RE: Semantics of vector operations)
Austin Hastings wrote: From: Rod Adams [mailto:[EMAIL PROTECTED] 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? That's why I suggested a standard script for Unicode2Ascii be shipped with the distro. Good Idea, which would also beg an ASCII2Unicode script to reverse the process. 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 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). (Links Snipped) Thanks for the pointers. I've now set up Win2k so I can easily switch between US and United States International. Works nicely. Now I have to go beat up the Thunderbird guys for trapping the keyboard directly and not allowing me to type the chars here. Thanks Again -- Rod
RE: Semantics of vector operations
> -Original Message- > From: Rod Adams [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 29, 2004 11:45 PM > To: [EMAIL PROTECTED] > 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 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
RE: Unicode under Windows (was RE: Semantics of vector operations)
> -Original Message- > From: Austin Hastings [mailto:[EMAIL PROTECTED] > > From: Rod Adams [mailto:[EMAIL PROTECTED] > > > > 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? That's why I suggested a standard script for Unicode2Ascii be shipped with the distro. > > 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 > 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). Sorry for the self-reply, but here's some links for you: These guys sell an overlay, and include a picture of the overlay, for US-Int keyboarding: http://www.datacal.com/dce/catalog/us-international-layout.htm Some extra information with a Francophonic spin to it: http://www.lehman.cuny.edu/depts/langlit/labs/keyboard.htm A more complete keyboard diagram: http://www.worldnames.net/ML_input/InternationalKeyboard.cfm >From the horse's mouth there is an interesting applet: http://www.microsoft.com/globaldev/reference/keyboards.aspx Finally, you could define your OWN keyboard layout using this tool (requires .NET install): http://www.microsoft.com/globaldev/tools/msklc.mspx =Austin
Re: Semantics of vector operations
On 0, Rod Adams <[EMAIL PROTECTED]> 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 > 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 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
Re: Semantics of vector operations
Luke Palmer wrote: Austin Hastings writes: 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 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.Emethod; # Instead of E I think that using the POD entities + Unicode is fine, but the solution to giving people who use E 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 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 and be done with it. Thoughts? -- Rod
Re: Semantics of vector operations
Austin Hastings writes: > 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 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.Emethod; # Instead of E I think that using the POD entities + Unicode is fine, but the solution to giving people who use E 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
RE: Semantics of vector operations
> -Original Message- > From: Luke Palmer [mailto:[EMAIL PROTECTED] > 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 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.Emethod; # Instead of E > > I think that using the POD entities + Unicode is fine, but the solution > to giving people who use E 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.
Re: Semantics of vector operations
Robin Berjon asked: >> 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 operator looks like. Damian
RE: Semantics of vector operations
> -Original Message-
> From: Robin Berjon [mailto:[EMAIL PROTECTED]
> 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, 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 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.Emethod; # Instead of E
>
> > > 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 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 RIGHTWARDS,
> > COMBINING> {...}
> >
> > $eigensanction =
> > $state E > 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 :)
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
RE: Semantics of vector operations
> -Original Message- > From: John Macdonald [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 29, 2004 8:30 AM > To: Robin Berjon > Cc: Damian Conway; [EMAIL PROTECTED] > Subject: Re: Semantics of vector operations > > > On Thu, Jan 29, 2004 at 11:52:04AM +0100, Robin Berjon wrote: > > 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 > 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. "With Included CD!"
Re: Semantics of vector operations
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, 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 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 {...}
$eigensanction =
$state E $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
Re: Semantics of vector operations
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.
> 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 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 {...}
$eigensanction =
$state E
$event;
if that's all your ancient ASCII device is capable of?
Damian
Re: Semantics of vector operations
On Thu, Jan 29, 2004 at 11:52:04AM +0100, Robin Berjon wrote: > 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 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.
Re: Semantics of vector operations
Damian Conway wrote: Robin Berjon wrote: 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? 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 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
Re: Semantics of vector operations
Robin Berjon wrote: 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
Re: Semantics of vector operations
Damian Conway wrote: Frankly, I'd *much* rather see: @sum = @a E+< @b; my Vector $outer = $vec1 E $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
Re: Semantics of vector operations
Larry mused: 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. No! ;-) 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+< @b; my Vector $outer = $vec1 E $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
Re: Semantics of vector operations
> "JW" == John Williams <[EMAIL PROTECTED]> writes: 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 -- [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
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... > > 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. :-) 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
Re: Semantics of vector operations
On Friday, January 23, 2004, at 10:57 , Larry Wall wrote: 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 [EMAIL PROTECTED]
Re: Semantics of vector operations
On Fri, Jan 23, 2004 at 07:53:49PM -0800, Jonathan Lang wrote:
: Dave Whipp wrote:
: > 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.
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
Re: Semantics of vector operations
On Fri, Jan 23, 2004 at 06:43:04PM -0800, Dave Whipp wrote:
: "Larry Wall" <[EMAIL PROTECTED]> wrote in message
: news:[EMAIL PROTECTED]
: > 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 <>. 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
Re: Semantics of vector operations
Dave Whipp wrote:
> 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/
Re: Semantics of vector operations
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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.
Re: Semantics of vector operations
On Fri, Jan 23, 2004 at 05:20:41PM -0700, Doug McNutt wrote: : 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 re
Re: Semantics of vector operations
On Fri, Jan 23, 2004 at 01:54:21PM -0800, Dave Whipp wrote:
: 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)
eq
Unfortunately, all the good brackets are taken. Hey, we could use
those weird French quotes:
«leach»eq«reach»
Oh, wait...nevermind...
Larry
Re: Semantics of vector operations
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. 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. McNuttPhD The MacNauchtan Laboratory 7255 Suntide Place Colorado Springs CO 80919-1060 voice 719 593 8192 [EMAIL PROTECTED] http://www.macnauchtan.com/ -- --> There are 10 kinds of people: those who understand binary, and those who don't <--
Re: Semantics of vector operations
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; Dave. "Luke Palmer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 ?+< > > > 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
Re: Semantics of vector operations
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 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 > > 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
Re: Semantics of vector operations
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 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
Re: Semantics of vector operations
Larry Wall writes: > 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 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: > > ~ ~>stringwise right shift > > as well as the never-before-thought-of: > > ? ?>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
Re: Semantics of vector operations
Luke Palmer <[EMAIL PROTECTED]> writes: > @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
Re: Semantics of vector operations
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 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
Re: Semantics of vector operations
- Original Message - From: "Luke Palmer" <[EMAIL PROTECTED]> To: "Austin Hastings" <[EMAIL PROTECTED]> Cc: "Larry Wall" <[EMAIL PROTECTED]>; "Language List" <[EMAIL PROTECTED]> Sent: Thursday, January 22, 2004 4:28 PM Subject: [perl] Re: Semantics of vector operations > Austin Hastings writes: > > 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. 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
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 01:34:33PM -0600, Jonathan Scott Duff wrote: : 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
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 02:28:09PM -0700, Luke Palmer wrote:
: 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([EMAIL PROTECTED], [EMAIL PROTECTED])
:
: (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
Re: Semantics of vector operations (Damian)
On Thu, Jan 22, 2004 at 01:28:42PM -0500, Austin Hastings wrote:
> > From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
> > 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?
> >
> > 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.
>
> It would be disappointing if junctions could not be lvalues.
Oh, I think that junctions can be lvalues but a junction is different
from the things that compose it. I.e.,
$a = 5; $b = 10;
$c = $a | $b;
$c += 5;
print "$a $b\n";
if $c > 10 { print "More than 10!\n"; }
would output
5 10
More than 10!
because the *junction* has the +5 attached to it rather than the
individual elements of the junction. Read the if statement as "if any
of (5 or 10) + 5 is greater than 10, ..." Which is the same as "if
any of 10 or 15 is greater than 10, ..."
I hope I'm making sense.
> > I don't think junctions apply at all in vectorization. They seem to
> > be completely orthogonal.
>
> I'm curious if that's true, of if they're two different ways of getting to
> the same data. (At least in the one-dimension case.)
I'm just waiting for Damian to speak up :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 11:25:41AM -0800, Larry Wall wrote: > On Thu, Jan 22, 2004 at 01:10:25PM -0500, Austin Hastings wrote: > : > -Original Message- > : > From: Larry Wall [mailto:[EMAIL PROTECTED] > : > 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, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Semantics of vector operations (Damian)
Luke Palmer writes: > > (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 Ã
Re: Semantics of vector operations (Damian)
Austin Hastings writes:
> > 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(); ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
PROTECTED], [EMAIL PROTECTED]) }
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
Ã
RE: Semantics of vector operations (Damian)
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> 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
Re: Semantics of vector operations
Austin Hastings writes:
> 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([EMAIL PROTECTED], [EMAIL PROTECTED])
(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
Ã
Re: Semantics of vector operations
* Larry Wall <[EMAIL PROTECTED]> [2004-01-22 18:40]: > 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. -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
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. 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 Ã
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 01:10:25PM -0500, Austin Hastings wrote: : > -Original Message- : > From: Larry Wall [mailto:[EMAIL PROTECTED] : > 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
Re: Semantics of vector operations (Damian)
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? 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 [EMAIL PROTECTED]
RE: Semantics of vector operations (Damian)
> -Original Message- > From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 22, 2004 1:16 PM > To: Austin Hastings > Cc: Larry Wall; Language List > Subject: Re: Semantics of vector operations (Damian) > > > 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? > > 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. It would be disappointing if junctions could not be lvalues. > > 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. I'm curious if that's true, of if they're two different ways of getting to the same data. (At least in the one-dimension case.) =Austin
RE: Semantics of vector operations
> -Original Message- > From: Larry Wall [mailto:[EMAIL PROTECTED] > 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
RE: Semantics of vector operations (Damian)
> -Original Message- > From: Larry Wall [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 22, 2004 12:50 PM > To: Language List > Subject: Re: Semantics of vector operations > > > On Thu, Jan 22, 2004 at 03:57:26AM +0100, A. Pagaltzis wrote: > : * 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++ ? :) > > %languageometer.values »+=« rand; > > Not to be confused with > > %languageometer.values »+= rand; > > which would presumably add the *same* number to all languageometers. > 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
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 03:57:26AM +0100, A. Pagaltzis wrote: : * 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++ ? :) %languageometer.values »+=« rand; Not to be confused with %languageometer.values »+= rand; which would presumably add the *same* number to all languageometers. Larry
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. 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
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."
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
* 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
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: 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
> -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
> "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
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: 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
* 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
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
Austin Hastings wrote:
> 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) {...}
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
RE: Semantics of vector operations
> -Original Message- > From: Larry Wall [mailto:[EMAIL PROTECTED] > 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
Re: Semantics of vector operations
Larry Wall wrote: > 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
Re: Semantics of vector operations
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". : 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... : 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
