--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Yeah, that's true. But note that you can't do that black magic you
> were
> speaking of earlier:
>
> $a [ (cond ?? &infix:+ : &infix:*) but tighter(&infix:*) ] $b
>
> Because we can't choose the precedence of an operator after we parse
> it... un
Eirik Berg Hanssen writes:
> Luke Palmer <[EMAIL PROTECTED]> writes:
> > You shouldn't parse the right hand side yourself. That fixes the
> > issue.
>
> I was not aware of this option. A6/E6 gave me the impression that
> C would override the default parsing of the RHS, not
> merely augment
Luke Palmer <[EMAIL PROTECTED]> writes:
> Cool stuff. In my usual pedantic sort of way, I'll go through the
> message and fix everything you said. For educational purposes only, of
> course :-)
Thanks :-)
For further education, some more questions/comments, if I may:
> # Let's say C
Simon Cozens writes:
> [EMAIL PROTECTED] (Luke Palmer) writes:
> > [$lhs, $rhs]脱\220\215.脱\235\237compile;
>
> What's that in old money?
Eep. I thought I had mutt's utf-8 working, but apparently not.
Does anyone who knows about these things want to mail me instructions,
or something? That'd be
[EMAIL PROTECTED] (Luke Palmer) writes:
> [$lhs, $rhs]æ\220\215.æ\235\237compile;
What's that in old money?
--
As the saying goes, if you give a man a fish, he eats for a day. If you
teach him to grep for fish, he'll leave you alone all weekend. If you
encourage him to beg for fish, pretty soon
"Austin Hastings" <[EMAIL PROTECTED]> writes:
> [Eirik wrote:]
> > Let us see ... somewhat speculative and probably short-of-the-mark
> > generalization coming up:
> >
> >
> > macro infix:[ ($lhs, $op, $rhs)
> > is parsed(/() \] ()/) {
> > return {
> > $op($lhs, $rhs)
> > };
Cool stuff. In my usual pedantic sort of way, I'll go through the
message and fix everything you said. For educational purposes only, of
course :-)
Eirik Berg Hanssen writes:
> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> > Hmm, since we're requiring no whitespace between a variable and it's
>
> -Original Message-
> From: Eirik Berg Hanssen [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 27, 2003 11:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Pondering parameterized operators
>
>
> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> > H
Luke Palmer <[EMAIL PROTECTED]> writes:
> Hmm, since we're requiring no whitespace between a variable and it's
> subscript, this should be possible:
>
> if "Dough" [eqn 4] "Douglas" {...}
Lisp! :-)
Well, almost. Now this would be lisp-y:
if $test [$moon.is_waxing ? &infix:< : &infi
"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 disambig
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, b
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
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 convenie
13 matches
Mail list logo
