[EMAIL PROTECTED] (Smylers) writes:
> In general I find backticks fairly jarring on the eyes, but they have to
> be used for _something_ ...
I think ugliness is actually a feature for vector ops. No sense having
to strap your programmers to the mast.
--
In a sense Christianity is like Jazz - if
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)
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) f
> 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
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 a
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
> > 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 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'
> 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:
> >
Oops. About that thing, I was wrong. Though there is a case
that does it:
sub bar();
sub postfix:bar($x) returns IO::Handle;
$x = length ;
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 that
of
--- 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
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 31 Oct 2002 14:07:34 -0800 (PST)
> From: Austin Hastings <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
>
> --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > Austi
--- 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 "True love\n"
> if all(@desidera
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
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 "
> 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
On Thu, 31 Oct 2002, Graham Barr wrote:
: On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote:
: > A pair of backticks could be used if the vector-equals distinction is
: > required:
: >
: > @a `+`= @b;
: > @a `+=` @b;
:
: Thats ugly, IMO.
:
: Now this is going to sound wild (p
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> >>?& ?| ?^ - [maybe] C-like bool
> operations
> >>?&= ?|= ?^= - (result is always just 1 or
> 0)
> >> [?&][?|][?^] - (hyperversions)
> >> [?&]= [?
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_
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
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 typ
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:
Damian Conway:
# Here's how to find the love of your life:
#
# $requirements = "tall" & "dark & "handsome"
#| "old" & "rich"
#| "Australian";
#
# for <> -> $candidate {
# my $traits = any( split //, $candidate );
# print "True love:
Austin Hastings wrote:
?& ?| ?^ - [maybe] C-like bool operations
?&= ?|= ?^= - (result is always just 1 or 0)
[?&][?|][?^] - (hyperversions)
[?&]= [?|]= [?^]=
[?&=] [?|=] [?^=]
Two possible differences between d
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
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 ab
> 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
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 al
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 w
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 face
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
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
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.
Larr
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, w
On Wed, Oct 30, 2002 at 09:25:21AM -0800, Larry Wall wrote:
> But the general problem is just about enough to kill the whole []
> idea for hyper.
Need. More. Punctuation. :-)
> So despite the beauty of
>
> @a [+] @b
>
> I think it cannot survive in its current form. It overloads squar
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 ( // -> { "bar" } )
but
@c = @a < <=>
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
fir
On Wed, 30 Oct 2002, Austin Hastings wrote:
: --- Brent Dax <[EMAIL PROTECTED]> wrote:
: > Buddha Buck:
: > # How would you parse:
: > #
: > # @a = @b[[5]];
: >
: > A 2D array slice, since you can't hyper numbers?
: >
:
: It's hypering the [5].
I don't think so. We can't allow general expres
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Buddha Buck:
> # How would you parse:
> #
> # @a = @b[[5]];
>
> A 2D array slice, since you can't hyper numbers?
>
It's hypering the [5].
@a = a list made up of the [5] (sub-)element of each element of @b.
for @b -> @b_subarr { @a.push(@b_subarr[5]
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]
Buddha Buck:
# How would you parse:
#
# @a = @b[[5]];
A 2D array slice, since you can't hyper numbers?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowin
On Wed, Oct 30, 2002 at 11:26:01AM -0500, Buddha Buck wrote:
> Larry Wall wrote:
> >I think we could also allow
> >
> >@a [??] @b [::] @c
> >
> >But it's not clear whether we can parse
> >
> >@a = [undef][...]
>
> How would you parse:
>
> @a = @b[[5]];
>
> (My intent: for @a; @b -> $x i
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 g
--- Michael Lazzaro <[EMAIL PROTECTED]> 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 i
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> 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 c
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
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 ar
47 matches
Mail list logo
