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: Comma Operator
Larry Wall writes:
> On Wed, Jan 21, 2004 at 08:51:33PM -0500, Joe Gottman wrote:
>
> : Great, so
> : $x = foo(), bar();
> : means the same thing as
> : $x = ( foo(), bar() );
>
> No, we haven't changed the relative precedence of assignment and
> comma. I've been tempted to, but I always come back to liking the
> parens for visual psychological purposes.
But that does lead to propagating the myth that parens, rather than
commas, denote lists.
> Plus changing the precedence would break
>
> loop $i = 0, $j = 0; $x[$i,$j]; $i++, $j++ { ... }
I think that matters less -- assigning lists is a much more common
operation that using a C-style C loop, and is also something that's
a common source of errors with beginning Perl 5 programmers. Most of
the C-style C loops I see are unnecessary anyway:
* The majority of them are iterating through array indices (which are
then only used to look up elements in those arrays), something far
more easily achived with a C loop and letting Perl take
care of the indices.
* Many of the remainder are still iterating through consecutive
integers, where C or whatever would much tidier
than checking the boundary and increasing the iterator manually.
* Even for situations which 'genuinely' need the C-style loop in Perl
5 (such as looping through items in an array but also having the
index number available) many of those in Perl 6 can use C.
So I think it's odd to optimize for convenience of a construct that has
so little use.
Especially when there are ways of writing that statement without any
commas in it:
loop $i = $j = 0; $x[$i,$j]; do { $i++; $j++ } { ... }
While on the topic of C and parens, it hadn't occurred to me that
the former could now be written without the latter; I knew that C,
C, and C could be, and now I look at it I can see that
C can be so-written unambiguously -- but having 'internal',
unbracketed, unquoted, unprotected semicolons scares me a little.
I'd feel more at ease if on seeing something like:
loop $i = $j = 0;
I could be certain that that semicolon denoted the end of that
statement, without my having to know what C does.
Again, given how infrequently C is likely to be used, would
imposing such a rule be much of a hardship? So a loop could look
something like:
loop($i = $j = 0; $x[$i,$j]; do { $i++; $j++ }) { ... }
and it's blindingly obvious that the first semicolon couldn't possibly
be the end of the statement.
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
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 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
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
