Re: perl6 operator precedence table
Really what I've been wishing for was an operator (or whatever) to let me do an s// without changing the variable. print 'He said "'_($statement ~ s/\.$//)_'," but we didn't believe him.'; I'm not sure exactly what the semantics would be, but somehow =~ without the = seems appealing...it's always seemed annoying to have to make a new variable for things like that, instead of being able to do it in place. But then, perhaps that isn't justification for an entire operator so much as $statement.replace/\.$// or something Mental note: no more postings right before bed. > Brent Dax wrote: > > > Can the new nefarious use be concat? Pretty please? > > There was a brief period 18 months ago when tilde *was* the designated > Perl 6 concatenation operator. > > I certainly wouldn't mind seeing it return to that role, now that > it's not needed elsewhere. And, of course, that would actually be: > > $x ~ $y string concatentation > $x ~= $ystring append > ~$x stringification > > I guess the only concern is the potential for nasty surprises between: > > $str =~ s/a/b/; substitute a for b in $str > > and: > > $str ~= s/a/b/; substitute a for b in $_ and append result to $str > > But I guess that's no worse than: > > $x-=10; > > and > > $x=-10; > > which doesn't seem to be a problem for people in Perl 5. > > Damian > > -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Falls don't kill people. It's the deceleration trauma.
RE: perl6 operator precedence table
Damian Conway wrote:
>I certainly wouldn't mind seeing it return to that role, now that
>it's not needed elsewhere. And, of course, that would actually be:
>
> $x ~ $y string concatentation
> $x ~= $ystring append
> ~$x stringification
> ...
> $str =~ s/a/b/; substitute a for b in $str
>
> ...
> $x-=10;
> ...
> $x=-10;
> which doesn't seem to be a problem for people in Perl 5.
>
So now
$x = ~$y
is not the same as
$x =~ $y
but
$x =- $y
is same as
$x = -$y
Dont we have for consistency ( or may be I have a wrong idea of consistency )
to prohibit ( or rize warning ) when "=-" ( or "=+", "=/" and so on ) appear .
besides it will make "=" an operatorial prefix ( which beutifully makes sence
in "=~" operator) . And maybe in future we can find uses for "=|" , "=!" , ...
..
And to start with, we can make them legitimate operators to be overloaded .
Maybe , my question really is , how perl will behave if I will do
sub operator:=+ (str $x, str $y) { system( "$x | $y" ) } ;
so this is more question of qrammar ?
?
arcadi .
Literate programming (was Re: perl6 operator precedence table)
Larry,
As long as you're trying to figure out how to shoehorn in the last few
available punctuation symbols, and thinking about if there are any
bracketers left, I wondered if there was a chance of a chunking operator
for literate programming? So you can do something like this, if <<<>>>
were the operator:
=doc code
We loop through the array, operating on each item:
=cut
for @list -> $item is rw { # is 'is rw' assumed with for? I forget...
<<>>
}
=doc code
The operation performed is incrementing each item by one:
=chunk operation
$item++;
=cut
Trey
Re: perl6 operator precedence table
On Thursday, October 24, 2002, at 11:22 AM, Larry Wall wrote: But we also have to balance it against the desirability of using ~ for concatenation. Requiring whitespace around _ is a bit of a rationalization after the fact, and ~ escapes that problem in most cases. So (w/out whitespaces): $a~$b # (1) concat $a~=$b # (2) $a = $a ~ $b $a=~$b # (3) $a = the stringification of $b (using unary ~) and something similar to the following $a ~~ $b # maybe perl5 =~, the "logical" look $a $b# maybe perl5 =~, the "comparator" look $a like $b # maybe perl5 =~, the "english" look Hmm, something like that could work. From: Angel Faus <[EMAIL PROTECTED]> Oh, and =~ looks much more intimidating, which is good, given its.. err.. power. Well, I was sort of trying to _avoid_ the intimidating part, because Perl is already intimidating, or so we keep hearing. :-) :-) Stop being intimidating! But in any case (if ~ means concat) I don't think we could sensibly leave =~ as '=~'. I would think we'd want unary ~ to work after '=', which would nix it right there, unless we want required whitespace again. Plus, it's ugly and its parents dress it funny. MikeL
Re: perl6 operator precedence table
On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote: On the other hand, the current rule for recognizing the *end* of a name in the style of operator:=+ is to go till the next whitespace, on the assumption that we'll never have (shudder) whitespace operators. Oooh, I nominate whitespace to be the concatenation operator! my $foo = $bar $bat; ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6 operator precedence table
> From: Angel Faus <[EMAIL PROTECTED]> > Date: Fri, 25 Oct 2002 00:54:09 +0200 > > All this ones fit more with the concept of "mystical analogy" hinted > by =~ than with the plain similarity that one would expect from > "like" True. Can't say I like, um, like. > Oh, and =~ looks much more intimidating, which is good, given its.. > err.. power. I fancy ~ or ~~ at the moment. To me, =~ implies some sort of assignment, seeing as there's a single equal sign in it. =~= looks more like a comparison, but it's too ugly-prolog-like. Indeed, I like the I of out-of-place substitutions, and using ~= or ~~= (the duck) for in-place. Though, as pointed out, the in-place efficiency of such a thing would be hard to detect. But--that's for the practical perliticians to work out :) Luke
Re: perl6 operator precedence table
Or we could go with Valspeak:
$a is like $b and stuff
At the moment I like "like" the best, actually...
Hmmm... I could actually see "like" in a more active role. Along the
lines of:
my str $string;
my $other_string is like $string;
Analogous to saying:
my str $other_string
Except that it would get new type information if the type of $string is
changed at some point. Might be useful for generic classes.
class LimitedStack {
attr @.array;
my $init;
method new($first, *@others are like $first) {
$init = $first;
@.array.push($first, *@others);
}
method push(*@items are like $init) { ... }
method pop { ... }
}
Also, this brings to mind the one thing I actually remember about
Sather, and as long as we're discussing operators...
Will we have similar to Sather's "::="? That was essentially the
"statically type this variable at run-time based on the type of it's
initial value" operator.
Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Chris Dutton wrote: : Also, this brings to mind the one thing I actually remember about : Sather, and as long as we're discussing operators... : : Will we have similar to Sather's "::="? That was essentially the : "statically type this variable at run-time based on the type of it's : initial value" operator. I was thinking ::= would be a := variant that binds at compile time. A "latchy" operator seems a bit weird to me. I'm not sure what it buys you that you couldn't get more straightforwardly through eval. It's a bit like the /o modifier on regexes. If you don't know the type at compile time, it's unlikely that you'll want to nail it down to the first type that comes along when other types might also want to use the same code generically. Larry
Re: perl6 operator precedence table
>
> At the moment I like "like" the best, actually...
>
"like" is beautiful for old-style regex matching, but I find it
confusing for the new smart abilities:
$varlike Class:Foo # $var is instance of Class:Foo
$item like %hash # %hash{$item} is true
$digit like (0..10) # $digit is in 0..10 range
@array1 like @array2 # array intersection
$numlike &f# f($num) is true
All this ones fit more with the concept of "mystical analogy" hinted
by =~ than with the plain similarity that one would expect from
"like"
Oh, and =~ looks much more intimidating, which is good, given its..
err.. power.
-angel
Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Damian Conway wrote: : Adam D. Lopresto wrote: : : > Really what I've been wishing for was an operator (or whatever) to let me do an : > s// without changing the variable. : : I would hope/expect that that's what the subroutine form of C would do. The problem with defining that as the primitive behavior is that some substitutions are very much faster in place, and it would be difficult to capture. : That is, it takes a string, a pattern, and a replacement string, : and returns a new string with substitution performed (without affecting : the original string): : : print 'He said "$( s($statement,/\.$/,"") )", but we didn't believe him.'; It's possible the syntax for substitution should be wrapped around the syntax for matching, whatever that turns out to be. replace($statement =~ /\.$/, "") replace($statement like /\.$/, "") or even: replace($statement like /\.$/, with => "") We shouldn't limit our notions to strings: replace(@array like 1|2|3, $& + 1); or if @array is the topic replace(1|2|3, $& + 1) It's not yet clear where in-place vs en-passant fits in here. Perhaps there's two different functions, spliting replace into "inplace" and "outplace". :-) I'm sure there are better words with the right connotations though. Larry
RE: perl6 operator precedence table
On Thu, 24 Oct 2002, fearcadi wrote:
: Maybe , my question really is , how perl will behave if I will do
:
: sub operator:=+ (str $x, str $y) { system( "$x | $y" ) } ;
:
: so this is more question of qrammar ?
The general rule in most lexers has always been that it grabs the
longest token it can recognize. So adding that definition would
change the meaning of
$a=+$b;
unless the lexer has a built-in rule that allows it to recognize
operators that haven't been defined yet. It's tempting to
require whitespace after certain classes of operators, but it
would certainly enrage a segment of the population.
On the other hand, the current rule for recognizing the *end* of a
name in the style of operator:=+ is to go till the next whitespace,
on the assumption that we'll never have (shudder) whitespace operators.
But that doesn't mean we have to require whitespace after every
operator. Putting the whitespace merely guarantees that it will
never be interpreted as a longer operator.
I think putting whitespace around any operator containing "=" is a
really good idea just on general principle. But I'm not willing to
inflict my principles on people mandatorily unless there's a really
good reason (as I think there is with mandatory curlies).
Larry
Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Deborah Ariel Pickett wrote: : Which looks better? : if ($a == 1|2|3 || $b eq "x"|"y"|"z") : or : if ($a == 1||2||3 | $b eq "x"||"y"||"z") : ? I think disjunctions of data values should be | and disjunctions of expressions should be ||, so that the "bigger" concept has the bigger operator. : Besides, maybe superposition is going to turn out to be a very common : thing in Perl after all. I think we'll see an awful lot of them that people won't even think of as superpositions, for instance: when 1 | 2 | 3 You know, we could go so far as to say that in regexen, | is unordered and || is ordered. Then we could optimize | to work via DFA or in parallel (for whatever definitions of parallel you want) . But that'd be a rather significant cultural change... : I think I've already decided that I prefer it the way it is (for recent : values of "is"). I just need some kind soul to pat me on the head and : tell me it's OK. It's really OK. The head pat is more problematic--I seem to flip my hemispherical sign bits one at a time, never both at once for the same trip. Perhaps Damian could give you a head pat by proxy next time you run into each other. Larry
Re: [OT] Power of Lisp macros?
Luke Palmer writes: > > Do you think that Lisp macros make the language more powerful than > > others (eg Perl)? I mean, do they really give a competitive > > advantage, or are they being overrated (see below)? > > If you define "powerful" as "can do more things," then of course not. No, of course. I guess any language is a Turing Machine, after all... I mean power in the sense of "more high level", that could be measured in (fewer) lines of code. Would I exaggerate if I said that the C/Perl compression rate could approach 10 in certain cases? Then I could point you to some benefits Perl has over C, for some classes of problems: faster development, easier maintenance, capability to better develop bigger systems. And Perl excels in solving a wide range of problems. > Lisp is implemented in C, and C's macros are certainly not essential > to its functionality. But think of what macros in general provide: > > * Multi-platform compatability > * Easier maintenance > > Perl has no problem with the former. It's multi-platform by nature. > But is has as much of a problem with the latter as any other language, > except Lisp. That is one of the continuing strong points of Lisp: it > can change very, very quickly. Yes. And what would this kind of "meta programming" allow? Perhaps thoughts like this: "Now I need code for these n cases. I will just write a macro." Maybe it makes complex problems suddenly appear more "tractable", allows for more code reuse/factorization? > However, they are intending to make it possible to write things like > C with subs, which will imply most of the power of > macros... though I imagine it won't be possible to have the level of > introspection lisp macros have (infinite). But, that design team is > very clever, so you never know. Well, I have to confess that I'm asking about macros, but I don't even remember when was the last time I used a closure ;-) > This kind of thing should reveal itself in the next Apocalypse. Then > we can see Larry's "vision," and make appropriate adjustments in terms > of that. Right now, it's very fuzzy. Nice, I'm looking forward to reading it. > Oh, and you aren't being inconvenient. These kinds of questions are > what the list is for: ask away! Thanks! Best regards, -- Adriano
Re: perl6 operator precedence table
Brent Dax wrote: Can the new nefarious use be concat? Pretty please? On Wednesday, October 23, 2002, at 07:46 PM, Damian Conway wrote: I guess the only concern is the potential for nasty surprises between: $str =~ s/a/b/; substitute a for b in $str and: $str ~= s/a/b/; substitute a for b in $_ and append result to $str On behalf of the Dumb People, I object. :-)... When I'm training newcomers to Perl, one of the hardest things for them to get is the =~ operator doing a regex. Regexen aren't a base part of most languages that beginning programmers use, but it's an integral part of Perl. Noone ever guesses that =~ means "matching": it looks like an assignment, which it sometimes is, and sometimes isn't, etc. It takes a lot of explaining, and even then people have often written ~= when they mean =~, and stared at it for a half hour not knowing why it didn't work. So I think the =~ vs ~= would be very, very confusing to people, just because =~ is already very confusing to start with, which, in turn, implies we can't use ~ for concat. If anything, I'd almost suggest the other way around, such that ~ means matching and ~= means matching assignment: $str1 ~ $str2# $str1 =~ m/$str2/ $str ~ /foo/ # $str1 =~ m/foo/ $str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2 $str ~= /foo/bar/; # perform subst, assign result to $str which sortof goes better with the new 'magic matching' usage of =~, and I could make some vague argument for matching +=, etc. IF we want to muck with it at all. MikeL
Re: perl6 operator precedence table
Larry Wall wrote: > On 20 Oct 2002, Smylers wrote: > > : Seems like not too long ago we were short of punctuation symbols, > : and now you've got a spare one lying around. > > Pity there's no extra brackets lying around without going to > Unicode... Well if C<~> were made the hyper prefix (squiggly line suggesting motion or 'and so on' through a set of things?) that would free up C<^>. And the caret could be a bracket if you rotate your head to the right: ^ 1 2 3 v Might have to outlaw ending identifiers with "v" though ... Now that C<.> is used in bitwise operators, does it make sense to use it in bitwise shifts too: $a .< $b $a .> $b That would almost free up C< << > and C< >> > for being brackets of some sort, but only 'almost' here-docs use the former. Smylers
Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Michael Lazzaro wrote: :$str1 ~ $str2# $str1 =~ m/$str2/ That would be a smart match, not m/$str2/. :$str ~ /foo/ # $str1 =~ m/foo/ That would work. :$str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2 : :$str ~= /foo/bar/; # perform subst, assign result to $str That can't work without the "s". The lexer can't tell if "bar" is a string or an operator. But the ~= is a cute trick. Not sure if it's more than that though. Gotta worry about s/// in a boolean context, for instance. And the current idiom ($str2 = $str1) =~ s/foo/bar; is not much longer than yours, though your parens are, I think, optional, while mine aren't. But we also have to balance it against the desirability of using ~ for concatenation. Requiring whitespace around _ is a bit of a rationalization after the fact, and ~ escapes that problem in most cases. Plus, smart matching is such a heavyweight, notionally speaking, that it really deserves a larger operator. Since there's no such thing as a "logical concat", we might get away with using ~~, and then people wouldn't have to wonder whether it was ~= or =~. Or we could make it ===. That would pretty much rule out having the corresponding assignment operator though... Or we could leave it =~ for old times sake, and make people learn the difference from ~=. Or go with something new: $a :~ $b $a =~= $b $a =? $b $a $b $a <~> $b $a >< $b $a ::: $b $a match $b $a like $b $a vs $b $a v $b If it is, in fact, a topicalizer, then the Japanese would very naturally parse a postpositional particle: $a wa $b Or we could go with Valspeak: $a is like $b and stuff At the moment I like "like" the best, actually... Larry
Re: perl6 operator precedence table
On Thu, Oct 24, 2002 at 09:59:00AM -0700, Michael Lazzaro wrote: > Noone ever guesses that =~ means "matching" That's because it doesn't. =~ means something more akin to "apply" but it's only valid for the three m//, s///, tr/// ops. That'll change in perl 6 though :-) > If anything, I'd almost suggest the other way around, such that ~ means > matching and ~= means matching assignment: > >$str1 ~ $str2# $str1 =~ m/$str2/ >$str ~ /foo/ # $str1 =~ m/foo/ >$str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2 >$str ~= /foo/bar/; # perform subst, assign result to $str I like it even though the naked ~ always makes me think of awk. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: perl6 operator precedence table
In 'C', we have: a = b+c; In Perl, we can have: $a = $b$c; (Parseable as $a = $b operator:spacespace operator:tab operator:spacespace $c;) Oh frabjous day! =Austin --- David Wheeler <[EMAIL PROTECTED]> wrote: > On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote: > > > On the other hand, the current rule for recognizing the *end* of a > > name in the style of operator:=+ is to go till the next whitespace, > > on the assumption that we'll never have (shudder) whitespace > operators. > > Oooh, I nominate whitespace to be the concatenation operator! > >my $foo = $bar $bat; > > ;-) > > David > > -- > David Wheeler AIM: dwTheory > [EMAIL PROTECTED] ICQ: 15726394 > http://david.wheeler.net/ Yahoo!: dew7e > Jabber: > [EMAIL PROTECTED] > __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Re: perl6 operator precedence table
On Thursday, October 24, 2002, at 02:52 PM, Austin Hastings wrote: In 'C', we have: a = b+c; In Perl, we can have: $a = $b$c; (Parseable as $a = $b operator:spacespace operator:tab operator:spacespace $c;) Oh frabjous day! Good Lord, you're sicker than I am! :-D David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: perl6 operator precedence table
Um, I don't know about your mail program, but mine converts operator:tab to operator:spacespace operator:spacespace Anyone for makefiles? > -Original Message- > From: David Wheeler [mailto:david@;wheeler.net] > Sent: Thursday, October 24, 2002 5:59 PM > To: [EMAIL PROTECTED] > Cc: Larry Wall; fearcadi; Damian Conway; [EMAIL PROTECTED] > Subject: Re: perl6 operator precedence table > > > On Thursday, October 24, 2002, at 02:52 PM, Austin Hastings wrote: > > > In 'C', we have: > > > > a = b+c; > > > > In Perl, we can have: > > > > $a = $b$c; > > > > (Parseable as $a = $b operator:spacespace operator:tab > > operator:spacespace $c;) > > > > Oh frabjous day! > > Good Lord, you're sicker than I am! > > :-D > > David > > -- > David Wheeler AIM: dwTheory > [EMAIL PROTECTED] ICQ: 15726394 > http://david.wheeler.net/ Yahoo!: dew7e > Jabber: > [EMAIL PROTECTED] > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: [OT] Power of Lisp macros?
On Thu, Oct 24, 2002 at 12:26:41PM -0300, Adriano Nagelschmidt Rodrigues wrote: > Luke Palmer writes: > > Lisp is implemented in C, and C's macros are certainly not essential > > to its functionality. But think of what macros in general provide: > > > > * Multi-platform compatability > > * Easier maintenance > > > > Perl has no problem with the former. It's multi-platform by nature. > > But is has as much of a problem with the latter as any other language, > > except Lisp. That is one of the continuing strong points of Lisp: it > > can change very, very quickly. > > Yes. And what would this kind of "meta programming" allow? Perhaps thoughts > like this: > > "Now I need code for these n cases. I will just write a macro." > > Maybe it makes complex problems suddenly appear more "tractable", allows for > more code reuse/factorization? Damian's Switch.pm is like a Lisp macro. It extends Perl syntax for a certain kind of problem, and makes it easier to write a common code pattern. The thought process might go something like this: "I want to check a variable against a variety of conditions, and I'm tired of writing the same long-winded and error prone if/elsif/elsif/elsif/else cascade. This is a common 'switch' statement, except that I want to match a variety of conditions intelligently (integers, string equality, regexes, etc.)." When Paul Graham writes that 25% of his Viaweb code was macros, he's really saying that Common Lisp wasn't well suited to his problem domain (writing an ecommerce app). However, Common Lisp *allowed* itself to be extended in that directon, with macros. The result is that the 75% of his code that comprised the guts of Viaweb could have been written without macros (or in a language other than Common Lisp), but would have taken significantly more effort and code (and led to more bugs). Perl source filters are similar to Lisp macros to a small degree. Lisp macros are Lisp functions that are invoked at compile time to transform a *tokenized* Lisp program (using Lisp data structures) into a different set of tokens (which are then compiled). Source filters tend to act on raw text, not tokenized source code, and need to deal with the problematic aspects of Perl syntax (comments, Pod, HEREDOCs, etc.) every time they are written/invoked. Because Lisp macros are real Lisp code, they are far more powerful than the textual substitutions that pass for "C macros". Perl6 is moving to include something like Lisp macros. Perl5 source filters are a rough approximation, and a preview of things to come. Z.
Re: perl6 operator precedence table
On Fri, 25 Oct 2002, Martin D Kealey wrote:
: Going back to Perl5 for a moment, we have
:
: substr($str,$start,$len) = $newstr
:
: 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};
Problem with that...the replacement argument has to be lazy, and currently
the RHS of an assignment is actually evaluated before the left. You'd
really need something more like
$str =~ /\d/ = { 0 }
However, I think readability suffers without a hint on the front what
you're trying to do. So I'd be more inclined to say that the general
syntax is really more in the spirit of a conditional:
where $str =~ /\d/ { 0 }
The difference between inplace and copying is then really the disposition
of the closure:
where $str =~ /\d/, replace => { 0 }
where $str =~ /\d/, return => { 0 }
But that's clunky. If replacement is the norm, then returning a copy is just
where $str =~ /\d/ { 0 }
where $str.dup =~ /\d/ { 0 }
The topicalized forms would then be:
where /\d/ { 0 }
where .dup =~ /\d/ { 0 }
Except that still doesn't tell it whether to return a boolean or a string...
Of course, most of the time you want to replace with a string, and
where /\d/ { "0" }
is still a lot clunkier than
s/\d/0/;
Maybe we end up with that form and a Ruby-esque
s(/\d/) { "0" }
in the general case. Or it could go in the parens. Hey, maybe that's
a good spot for an arrow:
s(/\d/ -> { "0" })
In any event, we still haven't really solved the want-a-string vs
the want-a-boolean problem. Maybe it's just context:
if s(/\d/ -> { "0" }) {...} # boolean context, in-place
s(/\d/ -> { "0" }); # void context, in-place
print s(/\d/ -> { "0" })# string context, return string
$result = ~s(/\d/ -> { "0" }) # string context, return string
$result = ?s(/\d/ -> { "0" }) # boolean context, return string
$result = s(/\d/ -> { "0" })# untyped context, return what?
But I suspect that's too much weight to put on the context system. It
doesn't really solve the readability problem, especially when we get more
that one {...} in a row.
By all accounts, a s/// is an odd thing to put in a smart match
anyway. You can't have a superposition of things with side effects,
for instance:
$str =~ s/a/b/ | s/b/c/
Though doubtless Damian can think of something indeterminate to make
it mean. :-)
The in-place really feels more like you want a method
$str.s/a/b/
@foo.s(1|2|3, {0})
or maybe
$str.subst/a/b/
@foo.subst(1|2|3, {0})
Maybe the return value form is also a method:
$result = $str.where/a/b/
@result = @foo.where(1|2|3 -> {0})
In typical topical string usage, that leaves us with
if .subst/a/b/ {...}
$result = .where/a/b/
That's quite livable, though the second is a bit odd, English-wise.
We could even keep around
s/a/b/
as a shorthand for .subst/a/b/. And maybe even add
w/a/b/
as a synonym for .where/a/b/.
If so, possibly we don't have .subst/a/b/, but just .subst(/a/ -> { "b" })
for the general form. But string-like method args are certainly a possibility
in general, provided we can keep the declarations in order. But if not,
there's a bad ambiguity between
.subst/a/b/
and things like
.size/2
: (hyper, however it's spelt, will have some way for the RHS to reference the
: LHS, won't it?)
Haven't specified one. @array ^= 0 is supposed to do the right thing already,
and doesn't require the right side to know anything about the left side.
Larry
