Date: Tue, 29 Oct 2002 15:57:56 -0800 (PST)
From: Larry Wall [EMAIL PROTECTED]
That's not a problem with builtins, but what about
sub foo ();
sub prefix:foo ($x);
@a = [foo][1,2,3,4,5];
So how is this interpreted? Such syntactic ambiguity isn't nice.
Should we go with the
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
unary (prefix) operators:
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not - force to bool context, negate
+ - force to numeric
On Tue, 29 Oct 2002, Larry Wall wrote:
Logically entangle nouns *are* more basic than grade school. Kids are
even sophisticated enough to disambiguate xor from or by context,
despite the fact that English has no xor operator:
Which do you want? A popsicle or a Mickey Mouse hat?
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 Wed, Oct 30, 2002 at 04:03:55PM +, Piers Cawley wrote:
Jonathan Scott Duff [EMAIL PROTECTED] writes:
Hey, that's neat. Although it looks like it returns the $src when there
isn't a path. You probably want it to return undef or something.
Nah, it'll die when there isn't a path.
duh!
On 29 Oct 2002 at 11:22, Jonathan Scott Duff wrote:
On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
Also the idea of allways using 'function' style for something so
basic like superpositions doesn't appeal to me.
Superpositions are basic in a fabric-of-the-universe kind of
On Wednesday, October 30, 2002, at 07:18 AM, Jonathan Scott Duff wrote:
The only thing this inspires in my brain is Schoolhouse Rock
flashbacks.
o/~ Conjuction Junction, what's your function? o/~
Heh. That's what I heard, too.
David
--
David Wheeler AIM:
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
[.]foo() # What does this mean?
One could argue that several ways, depending on what's in the current
topic. It's the exact same thing as the binary form of dot, but with
the left side being implied, as 'the current topic':
topic is a scalar: hyperdot does nothing (scalar hyperop
In the Re: Wh[ie]ther Infix Superposition ops thread
On Wed, 30 Oct 2002, Piers Cawley wrote:
But given a decent Collection hierarchy:
my $seen = Set.new($start,$finish);
for - $next {
print $next unless $next =~ $seen;
$seen.insert($next);
}
Just a
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, Dave Storrs wrote:
: In the Re: Wh[ie]ther Infix Superposition ops thread
:
: On Wed, 30 Oct 2002, Piers Cawley wrote:
:
: But given a decent Collection hierarchy:
:
: my $seen = Set.new($start,$finish);
:
: for - $next {
: print $next unless $next =~
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
Jonathan Scott Duff [EMAIL PROTECTED] writes:
On Wed, Oct 30, 2002 at 04:03:55PM +, Piers Cawley wrote:
Jonathan Scott Duff [EMAIL PROTECTED] writes:
Hey, that's neat. Although it looks like it returns the $src when there
isn't a path. You probably want it to return undef or something.
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
Dave Storrs [EMAIL PROTECTED] writes:
In the Re: Wh[ie]ther Infix Superposition ops thread
On Wed, 30 Oct 2002, Piers Cawley wrote:
But given a decent Collection hierarchy:
my $seen = Set.new($start,$finish);
for - $next {
print $next unless $next =~ $seen;
Piers Cawley [EMAIL PROTECTED] writes:
Personally, I'd love to see something like the whole Smalltalk
Collection hierarchy available complete with Bags, Sets,
Dictionaries, OrderedCollections and the whole deal. I note, for
instance that Christian Lemburg has implemented Set::Object, and
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,
On Wed, 30 Oct 2002, Piers Cawley wrote:
:It is a truth universally acknowledged that a language in
: possession of a rich syntax must be in need of a rewrite.
: -- Jane Austen?
It is a truth universally acknowledged that a language in possession
of a rich syntax must be in need
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
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
On Wed, Oct 30, 2002 at 09:13:02AM -0800, Austin Hastings wrote:
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
Maybe we've gone over this before but, if so, I don't remember
...
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael
On Wed, 30 Oct 2002, Austin Hastings wrote:
: No, no. I'm talking about the unary . prefix
:
: method blah {
: .foo()
: [.]foo() # What does this mean?
: }
:
: Vector of invocations of the foo methods of the current topic.
Except that the topic is by
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
From: Piers Cawley [EMAIL PROTECTED]
Date: Wed, 30 Oct 2002 18:59:15 +
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Dave Storrs [EMAIL PROTECTED] writes:
In the Re:
--- Larry Wall [EMAIL PROTECTED] wrote:
On Wed, 30 Oct 2002, Austin Hastings wrote:
: No, no. I'm talking about the unary . prefix
:
:method blah {
: .foo()
: [.]foo() # What does this mean?
:}
:
: Vector of invocations of the foo methods of the
On Wednesday, October 30, 2002, at 11:58 AM, Larry Wall wrote:
I'd even be willing to give up ´foo bar bazª meaning qw(foo bar baz)
for this.
I can't see that right (MacOSX Jaguar) in the email; to me it looks
like a forwardtick and an, um, underlined 'a' -- but in spite of that,
I'm game.
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 Wednesday, October 30, 2002, at 12:17 PM, Michael Lazzaro wrote:
I can't see that right (MacOSX Jaguar) in the email; to me it looks
like a forwardtick and an, um, underlined 'a' -- but in spite of that,
I'm game. It's just so pretty (when it works!)
On my Mac, it's spelled «op» -- can
On 2002-10-30 at 12:23:53, David Wheeler wrote:
This tells me that Mail.app, for some reason, didn't know that it was
supposed to use UTF-8 when showing Larry's mail. When I pasted his mail
into a UTF-8 document in Emacs, it looked fine.
Given that it's probably UTF-8 that Perl 6 source
Proposal : Vector operations for Hashes
%a ^{+} %b
the direct generalization would be as follows :
a ^[op] b
for a ; b -
$x ; $y {
$x op $y
}
%a op %b
# find common keys
k = keys hash{ map { { _=1 } } *( %a.keys , %b.keys ) };
#return hash
On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:
: # find common keys
: @k = keys hash{ map { { _=1 } } *( %a.keys , %b.keys ) };
It seems a bit odd to privilege the intersection over the union.
Larry
On Wed, Oct 30, 2002 at 06:45:52PM +0200, Markus Laire wrote:
You are making the fundamental mistake of thinking superpositions as
superpositions. When thinking them as another-kind-of or/and, their
usefulness comes a lot clearer.
perl5: if $x 0 $x 20 $y 0 $y 20 $z 0 $z 20
!! Sorry, in previos post I had a mistake
Proposal : Vector operations for Hashes
(
this is just a joke
%a ^{+} %b
)
the direct generalization would be as follows :
a ^[op] b
for a ; b -
$x ; $y {
$x op $y
}
%a ^[op] %b
# find
In a different thread, Buddha Buck wrote the following code snippet:
for a; b - $x is rw; $y { $x = $y[5] };
And I finally had to whimper publicly about this.
I've been lurking around the P6 process since the very beginning of the
RFC process. I saw the new 'for' syntax come out, and
On 30/10/02 15:33 -0500, Mark J. Reed wrote:
On 2002-10-30 at 12:23:53, David Wheeler wrote:
This tells me that Mail.app, for some reason, didn't know that it was
supposed to use UTF-8 when showing Larry's mail. When I pasted his mail
into a UTF-8 document in Emacs, it looked fine.
On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
for a; b - $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be solved
if the above were just written:
for (a;b) - ($x is rw; $y) { $x = $y[5] };
Would that suffice to make it clearer?
On 29 Oct 2002 at 22:29, Larry Wall wrote:
Of course, Real Mathematicians will want [1..10) and (1..10] instead.
That seems familiar, I like it ;)
There's also an issue of what (1..10) - 1 would or should mean, if
anything. Does it mean (1..9)? Does 1 + (1..10) mean (2..10)?
And what
On Wed, 30 Oct 2002, Nicholas Clark wrote:
: On Wed, Oct 30, 2002 at 06:45:52PM +0200, Markus Laire wrote:
:
: You are making the fundamental mistake of thinking superpositions as
: superpositions. When thinking them as another-kind-of or/and, their
: usefulness comes a lot clearer.
:
:
On Wed, Oct 30, 2002 at 03:33:57PM -0500, Mark J. Reed wrote:
On 2002-10-30 at 12:23:53, David Wheeler wrote:
This tells me that Mail.app, for some reason, didn't know that it was
supposed to use UTF-8 when showing Larry's mail. When I pasted his mail
into a UTF-8 document in Emacs, it
On Wed, 30 Oct 2002, Mark J. Reed wrote:
: Larry's mail was *marked* as UTF-8, but by the time I got it it
: had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore.
: My mailer understand UTF-8 just fine, and so does vim (which I used to
: look at my spool file to check for
Michael Lazzaro writes:
On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
for a; b - $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be solved
if the above were just written:
for (a;b) - ($x is rw; $y) { $x =
On Wed, Oct 30, 2002 at 11:10:54PM +0200, Markus Laire wrote:
If we are going to do math with ranges, we definitely need non-
discreet ranges also. Or at least make sure it's easy enough to
implement as a class.
(1.9 .. 2.1) + (5..7) * (72.49 .. 72.51);
I don't think that non-discrete
--- Larry Wall [EMAIL PROTECTED] wrote:
Do these French quotes come through?
@a «+» @b
Oui, M'sieu!
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
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
On Wednesday, October 30, 2002, at 12:47 PM, Larry Wall wrote:
This is currently running in a window that does Latin-1 rather than
UTF-8.
Do these French quotes come through?
@a ´+ª @b
Nope.
But given that I don't even know where to go to type them in, and doing
so will likely be a
Dave Storrs writes:
is a Bad Thing and is going to cause a lot of bugs. I have the following
problems with it:
for a; b - $x is rw; $y { $x = $y[5] };
1) This is (AFAIK) the ONLY place in Perl where a semicolon that
is not enclosed in parens is used for anything other
On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote:
--- Larry Wall [EMAIL PROTECTED] wrote:
Do these French quotes come through?
@a «+» @b
Odd, I see them in this message. But In the message from Larry I see ?'s
Graham.
On Wednesday, October 30, 2002, at 01:28 PM, David Wheeler wrote:
But given that I don't even know where to go to type them in, and
doing so will likely be a PITA...even though I *love* the idea of
using these characters, might it be better to abandon them for now?
Oh, don't say that! I
On Wednesday, October 30, 2002, at 01:35 PM, Graham Barr wrote:
On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote:
--- Larry Wall [EMAIL PROTECTED] wrote:
Do these French quotes come through?
@a «+» @b
Odd, I see them in this message. But In the message from Larry I see
On Wed, 30 Oct 2002, Michael Lazzaro wrote:
On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
for a; b - $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be solved
if the above were just written:
for (a;b) - ($x is rw; $y)
Dave Storrs wrote:
for a; b - $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be solved
if the above were just written:
for (a;b) - ($x is rw; $y) { $x = $y[5] };
Would that suffice to make it clearer?
Actually, yes, that would solve everything
On Wednesday, October 30, 2002, at 01:43 PM, Michael Lazzaro wrote:
Oh, don't say that! I already know what all of these should mean! :-)
≈ … ∫ § ¿ ∆ ∑ Ω ø ¶ º ≠ ≤ ≥ ‹ › ‡ Ø ˇ ¬ Ç Œ ∞ ¡ •
Nice, I can see all of those. Your mailer is the same as mine, Apple
Mail, and the headers are:
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 Wednesday, October 30, 2002, at 01:46 PM, David Wheeler wrote:
But let me ask you -- how did you input those characters?
Applications/Utilities/Key Caps (Again, OSX) which shows you where
they all are.
The «» quotes, for example, are option-\ and shift-option-\
:-)
MikeL
On Wed, 30 Oct 2002, Austin Hastings wrote:
--- Dave Storrs [EMAIL PROTECTED] wrote:
for @a - $x; @b - $y { $x = $y[5] };
Yes!!!
(Except for the ''. That's feigen-ugly.
*shrug* You may not like the aesthetics, but my point still
stands: is rw is too long for something we're
On Tue, 29 Oct 2002, Austin Hastings wrote:
Any of you OO guys know of a case where
$a = $a + $b; # A [+]= B; -- A = A [+] B;
and
$a += $b; # A [+=] B;
should be different?
They are different in the scalar [op] list case, as explained here:
On Wed, 30 Oct 2002, Michael Lazzaro wrote:
: On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
: for a; b - $x is rw; $y { $x = $y[5] };
:
: I agree that it's an eyeful. How many of your issues could be solved
: if the above were just written:
:
: for (a;b) - ($x is
On Thu, 31 Oct 2002, Damian Conway wrote:
Dave Storrs wrote:
Actually, yes, that would solve everything for me...and I knew
this was valid syntax.
So is this vertical layout, which I think will become fairly standard
amongst those who care about readability:
for a ; b
Wednesday 30 October 2002 22:08, Michael Lazzaro escribió:
On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
for a; b - $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be
solved if the above were just written:
for (a;b) -
On Wed, 30 Oct 2002, Angel Faus wrote:
Then let's make the parens required when there is more than one
stream.
Sane people will put them there anyway, and it will force the rest of
us to behave.
It also solves the ;-not-a-line-seperator problem.
-angel
Yes! Thank you, this
On 30 Oct 2002 at 11:09, Larry Wall wrote:
On Wed, 30 Oct 2002, Piers Cawley wrote:
:It is a truth universally acknowledged that a language in
: possession of a rich syntax must be in need of a rewrite.
: -- Jane Austen?
It is a truth universally acknowledged that a
On Wed, 30 Oct 2002, John Williams wrote:
: They are different in the scalar [op] list case, as explained here:
: http://archive.develooper.com/perl6-language%40perl.org/msg10961.html
:
: ($a = 0) [+=] b; # sum
: ($a = 1) [*=] b; # product
: ($a ='') [~=] b; # cat
That's almost
On Thu, 31 Oct 2002, Markus Laire wrote:
: And you could always have something else as a backup for those
: unfortunates who can't use «+» - like ^[+]
:
: What are the good reasons not to use «» ?
It would force everyone to get their act together with respect to Unicode.
Oh, wait, that's a
Dave Storrs writes:
On Wed, 30 Oct 2002, Angel Faus wrote:
Then let's make the parens required when there is more than one
stream.
Sane people will put them there anyway, and it will force the rest of
us to behave.
It also solves the ;-not-a-line-seperator problem.
On Wed, Oct 30, 2002 at 01:57:00PM -0800, Dave Storrs wrote:
*shrug* You may not like the aesthetics, but my point still
stands: is rw is too long for something we're going to do fairly often.
I am not so sure. If I look back through a lot of my code, there are more cases
where I use
On 30 Oct 2002 at 15:24, Jonathan Scott Duff wrote:
On Wed, Oct 30, 2002 at 11:10:54PM +0200, Markus Laire wrote:
If we are going to do math with ranges, we definitely need non-
discreet ranges also. Or at least make sure it's easy enough to
implement as a class.
(1.9 .. 2.1) + (5..7)
--
On Wed, 30 Oct 2002 07:13:40
Damian Conway wrote:
Yes. That superpositions are going to be so widely used once people
catch on, that users going to curse us every time they have to
write Cuse ops ':superpositions'; at the start of every scope.
So, I open my inbox and see that it has
Brian Ingerson wrote:
Not quite. You also need to discriminate the *type* of the superposition:
Oh right. I was thinking that Cany and friends were operations, not types.
Oops.
YAML type-URIs are made up of a type-family with an optional format:
!domain.com/type#format
and:
!int
Larry mused:
On Tue, 29 Oct 2002, David Whipp wrote:
: Larry Wall [mailto:larry;wall.org] wrote:
: : unary (postfix) operators:
: :... - [maybe] same as ..Inf [Damian votes Yes]
: : I wonder if we can possibly get the Rubyesque leaving out of
: endpoints by saying something like
[EMAIL PROTECTED] (Dave Storrs) writes:
minimal exception to remember
Another one for my irregularity check, thanks! :)
--
Though spring is here, to me it's still September,
That September, in the rain
- Dinah Washington, The USENET Anthem.
Graham Barr wrote:
Now that we have gained ^ back from being a hyeroperator, could we not
have ^ as a polymorphic complement operator. It can always be combined
with ~ or + to force context, eg
$a = ^ +$b;
$a = ^ ~$b;
We would then have a complement operator that I would assume objects
Larry Wall:
# This is currently running in a window that does Latin-1
# rather than UTF-8. Do these French quotes come through?
#
# @a + @b
No, but I'm running Outlook, so it's probably a bug on my end. :^) (It
does show up in that annoying variable-width font it switches to for
[EMAIL PROTECTED] (Damian Conway) writes:
Forgive me but is this syntax really necessary.
If you're going for user-definable operators, most of this syntax is
entirely unnecessary. Take all the hairy stuff out of core and be done
with it!
This won't stop people arguing about it, though. :)
--
[EMAIL PROTECTED] (Michael Lazzaro) writes:
â
 â
¦Â â
«Â § ¿ â
 â
 Ω ø ¶ º â
 â
¤Â â
¥Â â
¹Â â
ºÂ â
¡Â Ã
 Ë
 ¬ Ã
 Å
 â
 ¡ â
¢
How does that translate to Perl 5?
--
Almost any animal is capable learning a
So is it usefull to make sence out of these :
hash ^[op] hash
hash ^[op] array
hash ^[op] scalar
array ^[op] array
array ^[op] scalar
Actually ,
I just want to understand , why so much accent is put on vectorizing
atomic operations with arrays . It seems that hashes are at least as
On Wednesday, October 30, 2002, at 03:07 PM, Damian Conway wrote:
In creating my operator list I deliberated shied away from the unary
and binary
multimorphic forms. But I do see Graham's point and would favour
retaining
polymorphic unary C^ at least.
Meaning that the list:
+ - force
On Wed, 30 Oct 2002, Graham Barr wrote:
On Wed, Oct 30, 2002 at 01:57:00PM -0800, Dave Storrs wrote:
*shrug* You may not like the aesthetics, but my point still
stands: is rw is too long for something we're going to do fairly often.
I am not so sure. If I look back through a lot of
Michael Lazzaro wrote:
Meaning that the list:
+ - force to numeric context
- - force to numeric context, negate
+^- force to numeric context, complement
~ - force to string context
~^- force to string context, complement
simply becomes:
^ - complement
On Fri, 25 Oct 2002, I wrote:
why not simply extend pattern-matching in a similar way to substr, making it
an L-value, so that one gets
$str ~ /[aeiou]+/ = vowels($)
or
$str ~ /\d/ {hyper-symbol}= (0) x {size-of-LHS-array};
On Thu, 24 Oct 2002, Larry Wall replied:
Problem
hash ^[op] hash
...
array ^[op] scalar
ie, generally:
term ^[op] term
what to do if a, b in a ^[op] b have different length
what to do if %a, %b in %a ^[op] %b have not the same set of keys
what to do in %a ^[op] a
[what to do] resolved by hash property :
I'd expect adverbs
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:
fc == [EMAIL PROTECTED] writes:
fc So is it usefull to make sence out of these :
fc hash ^[op] hash
fc hash ^[op] array
fc hash ^[op] scalar
fc array ^[op] array
fc array ^[op] scalar
well, you can't mung the keys to a hash, just the values. so why not
just use the values
Larry elucidated:
In general, for any type, how do you write
[$min .. $max - $step : $step]
when you don't even necessarily have subtraction defined? We don't know
how to do z - 1 in Perl 5, for instance.
Okay. I buy that.
Damian
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
Larry wrote:
The set features are a side effect of junctions, just as they're a side
effect of hashes. An any junction might well be implemented underneath
as a hash without values.
Yep.
Possibly we might even extend the notion of hash to any junk.
%hash = 1 | 2 | 3;
So you're
Larry wrote:
That's almost a reduce. Pity you have to include a variable.
But since rvalues are illegal on the left side of an assignment, we
*could* go as far as to say that
0 [+=] b; # sum
1 [*=] b; # product
'' [~=] b; # cat
dwim into reduce operators rather than being
--
On Wed, 30 Oct 2002 16:37:09
Michael Lazzaro wrote:
OK, by my count -- after editing to reflect Larry's notes -- only a few
issues remain before the ops list can be completed.
1) Need a definitive syntax for hypers,
^[op] and +op;
have been most seriously proposed --
Date: Thu, 31 Oct 2002 13:02:44 +1300 (NZDT)
From: Martin D Kealey [EMAIL PROTECTED]
We don't in general have a let on the front of assignment statements; why
should this type of assignment be any different? (Do we want a let keyword?
Personally I don't think so, but what do others think?)
On 30/10/02 13:41 -0800, David Wheeler wrote:
On Wednesday, October 30, 2002, at 01:35 PM, Graham Barr wrote:
On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote:
--- Larry Wall [EMAIL PROTECTED] wrote:
Do these French quotes come through?
@a «+» @b
Odd, I see
On Wed, 30 Oct 2002, Me wrote:
%a ^:union[op] %b
%a :foo[op]:bar %b
I think that any operators over 10 characters should be banished, and
replaced with functions.
~ John Williams
95 matches
Mail list logo
