Yesterday Aaron Crane wrote:
Jonathan Scott Duff writes:
a `+ b
In my experience, many people actually don't get the backtick
character at all.
Yes. I think that might be a good reason _for_ using backtick in vector
operators:
* Backticks aren't used in any other operators, so
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote:
Yesterday Aaron Crane wrote:
Jonathan Scott Duff writes:
@a `+ @b
In my experience, many people actually don't get the backtick
character at all.
Yes. I think that might be a good reason _for_ using backtick
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
? ?| ?^ - [maybe] C-like bool
operations
?= ?|= ?^= - (result is always just 1 or
0)
[?][?|][?^] - (hyperversions)
[?]= [?|]= [?^]=
[?=]
Thats ugly, IMO.
Now this is going to sound wild (probably) and I have not thought too much
about it and there are probably others who can see the pitfalls quicker
then me. But could () be available for hyper operators ?
I will sit back now and watch the firewaorks, as I wont be in
Austin Hastings wrote:
In the C that I learned, the ^| ops were bitwise.
Likewise, the || ops were lazy booleans.
So what's a single-letter boolean act like? Is it lazy? Does it retain
its bitwise-ness but (since boolean) force evaluation for 1 or 0 first?
I just don't understand what the
Graham Barr wrote:
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote:
... using backtick in vector operators ... A pair of backticks could
be used if the vector-equals distinction is required:
@a `+`= @b;
@a `+=` @b;
Thats ugly, IMO.
Oh, I wasn't claiming that
--- Luke Palmer [EMAIL PROTECTED] wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
traits = any ( ... )
requirements = .. ..
if $requirements eq $traits
Should that be traits = all()?
No. Because later we say (effectively):
print
Oops. About that op thing, I was wrong. Though there is a case
that does it:
sub bar();
sub postfix:bar($x) returns IO::Handle;
$x = length bar;
If it's possible to have a distinct sub and an operator with the same
name. If not, I believe the distinction is precisely the same as
Date: Thu, 31 Oct 2002 15:16:17 -0800 (PST)
From: Austin Hastings [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
--- Luke Palmer [EMAIL PROTECTED] wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
traits = any (
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote:
... using backtick in vector operators ... A pair of backticks could
be used if the vector-equals distinction is required:
@a `+`= @b;
@a `+=` @b;
Thats ugly, IMO.
Oh, I wasn't claiming that it's pretty. I
get guillemot
Taken.
Extra credit for those of you who remembered that that's a bird, not a
punctuation mark.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Is it, err, Mildred? O.K., no. How 'bout - Diana? Rachel? Ariel, her name is
On Thursday, October 31, 2002, at 03:47 PM, Deborah Ariel Pickett
wrote:
(Whine: my Perl undergrad students are too young to remember or
appreciate text adventures. At least some of you oldsters here will
understand.)
Hey! We're not old, we're just version 1.0!
Can we have a grue operator?
On Fri, Nov 01, 2002 at 07:54:01AM +1100, Damian Conway wrote:
Austin Hastings wrote:
traits = any ( ... )
requirements = .. ..
if $requirements eq $traits
Should that be traits = all()?
No. Because later we say (effectively):
print True love\n
if all(desiderata) eq
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 1 Nov 2002 03:08:37 +
From: Andrew Wilson [EMAIL PROTECTED]
Mail-Followup-To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Content-Disposition: inline
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
On Fri, Nov 01,
On Fri, 1 Nov 2002, Damian Conway wrote:
: Austin Hastings wrote:
:
: In the C that I learned, the ^| ops were bitwise.
:
: Likewise, the || ops were lazy booleans.
:
: So what's a single-letter boolean act like? Is it lazy? Does it retain
: its bitwise-ness but (since boolean) force
Larry wrote:
I don't much care whether they short-circuit or not. I could argue it
either way. I think it'd be okay if they short-circuit. Anybody who
uses an operator like ? expecting it to force a side effect on the
second expression is nuts. And there's something (though not much)
to
On Tue, 29 Oct 2002, Larry Wall wrote:
Maybe we should just say that you can put it anywhere that makes sense,
and let the perl parser sort out the sheep from the goats. The basic
rule is that for any op, [op] is also expected in the same place.
It would be nice to have a fully generalized
Larry Wall wrote:
Maybe we should just say that you can put it anywhere that makes sense,
and let the perl parser sort out the sheep from the goats. The basic
rule is that for any op, [op] is also expected in the same place. So
if the user defines a postfix:! for factorial, they automatically
On Wed, Oct 30, 2002 at 11:26:01AM -0500, Buddha Buck wrote:
How would you parse:
@a = @b[[5]];
(My intent: for @a; @b - $x is rw; $y { $x = $y[5] }; # I think... )
I'd write that as @a [=] @b[5];
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Wednesday, October 30, 2002, at 09:25 AM, Larry Wall wrote:
So despite the beauty of
a [+] b
I think it cannot survive in its current form. It overloads square
My own backup proposals would be:
h+
h[+]
or similar, e.g. give the brackets a prefix to differentiate them
firmly
Larry Wall writes:
So despite the beauty of
a [+] b
I think it cannot survive in its current form. It overloads square
brackets too heavily.
Larry
so may be a + b
a = b
a , b
a .= replace ( /foo/ - { bar } )
but
c = a = b
this work since we do not
On Wed, 30 Oct 2002, Austin Hastings wrote:
: [op] - as prefix to any unary/binary operator, vectorizes the
: operator
:
: What, if any, guarantees are there about the order of evaluation for
: vectorized operations?
:
: If I say
:
: b = a[.meth];
:
: and .meth has a side-effect, what
On Wed, 30 Oct 2002, Jonathan Scott Duff wrote:
: a x+ b
: a `+ b
: a ^+ b# I like this one best ;-)
:
: if we did go back to using ^ for hyper I have no clue what to do about
: xor. I'd suggest % but I use the modulus too much.
Gee, % looks kinda like an X.
Larry
On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:
: Larry Wall writes:
:
: So despite the beauty of
:
: @a [+] @b
:
: I think it cannot survive in its current form. It overloads square
: brackets too heavily.
:
: Larry
:
:
: so may be @a + @b
:
: @a = @b
: @a , @b
On Wed, 30 Oct 2002, Michael Lazzaro wrote:
: My own backup proposals would be:
:
: h+
: h[+]
:
: or similar, e.g. give the brackets a prefix to differentiate them
: firmly as 'hyper'. Personally, I still don't mind that extra char,
: because it makes it extra-super-obvious; as we've
Jonathan Scott Duff writes:
a `+ b
Ick. In my experience, many people actually don't get the backtick
character at all. They can't find it on the keyboard, and they don't really
see what's so different about it from apostrophe. Indeed, many typefaces
(including common print-media faces,
Larry Wall writes:
Well, v for vector makes a little more sense, maybe. Could be lots of things:
a *[+] b
a .[+] b
a =[+] b
a ![+] b
a ^[+] b
a _[+] b
a :[+] b
a '[+] b
a v[+] b
There's a problem with v[] for postfix ops, though.
Larry Wall writes:
a ^[+] b
I like this one in preference to plain ^+, but (unless I'm missing
something) it still leaves the question of what to do with xor.
a '[+] b
Doesn't this reinvent the $Package'symbol problem?
The * has obvious mnemonic value of the splat sort, but also
So despite the beauty of
a [+] b
I think it cannot survive in its current form. It overloads square
brackets too heavily.
What about using colon thus:
a [:+] b
or other character after the opening bracket, so long as that
character is not valid as the initial character of a
On Wed 30 Oct, Larry Wall wrote:
An earlier message had something like this as a hyper:
@a = @b[.method];
That absolutely won't work, because [.method] is a valid subscript.
In this case it would have to be written
@a = @b[.]method;
But the general problem is just about
Larry Wall wrote:
: if we did go back to using ^ for hyper I have no clue what to do about
: xor. I'd suggest % but I use the modulus too much.
Gee, % looks kinda like an X.
Just put that alpha down and back away quietly, mister.
There's no need for anyone to get hurt here.
;-)
Damian
Austin Hastings wrote:
? ?| ?^ - [maybe] C-like bool operations
?= ?|= ?^= - (result is always just 1 or 0)
[?][?|][?^] - (hyperversions)
[?]= [?|]= [?^]=
[?=] [?|=] [?^=]
Two possible differences between
Brent Dax self-deprecated:
So, the love of my life is:
Function call found where operator expected at - line 1, near
dark handsome
That figures, actually, considering my social life...
Thanks. Would the hypothetical example collector please archive the
corrected version instead:
Larry wrote:
Never. Truth is relative in Perl. Having a true literal would
imply that objects couldn't decide whether they're true or not, unless
the true literal really means a superposition of all the possible
true values of every type. Which is kinda hard to write, especially
since a type
For this version of the operator list, (since I am unsure that _every_
unary/binary op has a meaningful hyper, and some tentatively have
_two_) I have placed all of them in EXPLICITLY. Please check that I
didn't miss any, or put any in that are incorrect.
hyperoperators:
[op] - as prefix
On Tue, 29 Oct 2002, Michael Lazzaro wrote:
: For this version of the operator list, (since I am unsure that _every_
: unary/binary op has a meaningful hyper, and some tentatively have
: _two_) I have placed all of them in EXPLICITLY. Please check that I
: didn't miss any, or put any in that
36 matches
Mail list logo
