Re: could u help me please?
On Thu, Sep 25, 2003 at 09:16:43AM -0700, Shannon Francis wrote: i tried to build a program and have only one error but seem not to be able to fix it. i think it is a rather small one. i would really appreciate it if you help me with this situation: if (num1 %2 =0) the error is: error C2106: '=' : left operand must be l-value. thank you very much. i await your answer. Wow! How did you find this list? The last message I got here was over two years ago. And how did you choose this list? Its name has little to do with your problem. In any case, try if (num1 % 2 == 0) and look for a C list or newsgroup for any subsequent problems you might have. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
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 Cwhere (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 Cwhere 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. :(
