Pondering parameterized operators
So I sit here and think for a minute about how nice it will be in P6 to
be able to define
operator infix:eqi($str1, $str2) {...}
for doing
if ($1 eqi "last")
and I think about the whole 'C' string library. Which dredges up my old
questions about parameterized operators:
How can I conveniently pass an extra parameter to a historically binary
operator?
At one point, the colon was going to do that, but Larry took it back:
if ("Dough" eqn:4 "Douglas") # true
{ ...
The options left seem to be:
package String;
sub strncmp($a, $b, $n) {...}
package main;
sub infix:immed &String::strncmp.assuming($n = 4);
if ("Dough" immed "Douglas") # ?
or:
class InfixBinary is Code {...}
# How do I create a "type"? -- I want to define a return-type-spec
# that just guarantees context behavior.
sub eqn($max) returns InfixBinary {
return &String::strncmp.assuming($n=$max);
}
if ("Dough" eqn(4) "Douglas") ...
Frankly, I like the second one.
=Austin
Re: Pondering parameterized operators
On Fri, 26 Sep 2003, Austin Hastings wrote: > How can I conveniently pass an extra parameter to a historically binary > operator? If it's one of the 'base' binary operators (addition, subtraction, and whatnot) you don't. Dan
Re: Pondering parameterized operators
Austin Hastings writes:
> How can I conveniently pass an extra parameter to a historically binary
> operator?
I see a few possibilities. The first, call it like a function:
if infix:eqn("Dough", "Douglas", n => 4) {...}
Or, you could use the adverbial modifier C (well, not officially
yet, but I hope so):
if "Dough" eqn "Douglas" where n=>4 {...}
But that has some problems, like putting the operator parameters really
far away from the operator, and forcing parentheses on a function call
on the right (lest the C be associated with the call).
More below.
> At one point, the colon was going to do that, but Larry took it back:
>
> if ("Dough" eqn:4 "Douglas") # true
> { ...
>
> The options left seem to be:
>
> package String;
> sub strncmp($a, $b, $n) {...}
> package main;
>
> sub infix:immed &String::strncmp.assuming($n = 4);
You probably mean:
our &infix:immed ::= &String::strncmp.assuming($n => 4);
> if ("Dough" immed "Douglas") # ?
>
> or:
>
> class InfixBinary is Code {...}
> # How do I create a "type"? -- I want to define a return-type-spec
> # that just guarantees context behavior.
>
> sub eqn($max) returns InfixBinary {
> return &String::strncmp.assuming($n=$max);
> }
>
> if ("Dough" eqn(4) "Douglas") ...
>
> Frankly, I like the second one.
Yeah, I don't think it's a bad idea. I think returning an infix
operator is not the way to go about it. Perhaps optional (and named)
parameters on an infix operator could be taken from a parameter list:
sub infix:eqn ($a, $b, ?$n) {
substr($a, 0, $n) eq substr($b, 0, $n)
}
if "Dough" eqn(4) "Douglas" {...}
That's not terribly good at making different things look different.
It's pretty common to see parenthesized expressions on either side of an
operator.
Hmm, since we're requiring no whitespace between a variable and it's
subscript, this should be possible:
if "Dough" [eqn 4] "Douglas" {...}
If we're going that far...
sub foo($a, $b) {
print "$($a)y$b";
}
"Dough" [foo] "Douglas"; # DoughyDouglas
Not sure I like that too well.
Luke
Re: Pondering parameterized operators
"Austin Hastings" <[EMAIL PROTECTED]> wrote
> if ("Dough" eqn(4) "Douglas") ...
I wonder if the . operator is available here:
if "Dough" eq.n(4) "Douglas" { ... }
that makes it intuitive how to define new equality "methods". One thing of
concern is that we'd need whitespace rules to disambiguate things. I sense
some wonderful opportunities for obfuscation.
Dave.
Re: Autovivification (was Re: E6: assume nothing)
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 08, 2003 at 11:18:12AM +0200, Paul Johnson wrote:
> : By the way, I trust this will be addressed (if it hasn't been
> : already):
> :
> : perl5 -le 'print "gah!" if exists $a{b}{c}; print "phooey!"
> : if exists $a{b}'
> :
> : perlfunc says:
> :
> : This surprising autovivification in what does not at first--or
> : even second--glance appear to be an lvalue context may be fixed
> : in a future release.
>
> I sure hope so. Perl 5 confuses reference contexts with lvalue
> contexts. With the new vtable implementation of basic types, we
> ought to be able to substitute an "always undefined" array or hash
> vtable that can propagate non-existence outward in rvalue context.
>
> Larry
This one doesn't *quite* make me as strongly prompted to chuckle and
say "Larry, you're an evil genius" as the comments on macros in another
thread, but it still gives me a warm fuzzy particularly because we
know Good Larry is in charge, and Evil Genius Larry just works in the
sweatshop to satisfy his need to beat the Gods of Cryptocontext at
their own game.
TMTOWTDI applies likewise to DWIMming! :)
Also, I'm very sorry Larry -- I hit the wrong button backing up to edit
this, and sent you an empty message. :(
