On Thu, Jun 24, 2004 at 11:59:03AM +0100, Matthew Walton wrote:
: -----BEGIN PGP SIGNED MESSAGE-----
: Hash: SHA1
:
: Michele Dondi wrote:
:
: | I don't know if this is already provided by current specifications, but
: | since I know of Perl6 that is will support quite a powerful system of
: | function prototyping ("signatures"?), I wonder wether it will be possible
: | to specify a (finite number of) argument(s) on the left of functions, thus
: | allowing to create user-defined operators. I had tried sml (a functional
: | language) and despite its being really simple if compared to Perl, it
: | provided this functionality...
:
: If SML is anything like Haskell, user-defined operators are really just
: syntactic sugar around normal function definitions, with appropriate
: allowances in the grammar for arbitrary operators to exist and be parsed
: correctly.
Same in Perl 6. For instance, to call the binary addition operator
C<< $a + $b >> by its "true name", you'd say C<< infix:+($a,$b) >>.
When you define an operator, you always use the "true name" form.
: Haskell also has an interesting backticks operator, which turns any
: two-argument function into an infix operator, and is generally used for
: readability purposes. Thus, although you can do modulus with the 'mod'
: function like this:
:
: mod 3 4
:
: you can also write
:
: 3 `mod` 4
:
: which can be handy when trying to get an arithmetic-type feel to your
: programs. I doubt Perl would need something like this though.
It would be easy to define a meta-operator in Perl 6 to do this, but
I also doubt that Perl will need it to be standard.
: Haskell of course also lets you do things like
:
: infixr 3 +++
:
: which defines a right-associative infix operator at precedence level 3,
: denoted by the token '+++'
:
: and later you can say something like
:
: (+++) :: Num a => a -> a -> a
: x +++ y = x + y
:
: which defines the +++ operator to have exactly the same effect as +
: (although probably with different precedence, I have no idea what the
: numeric precedence level of + is in Haskell, and indeed if + is right or
: left associative, as I always get those two muddled up, so that might be
: different too) when applied to numbers. Pretty pointless really, unless
: you wanted a tight-binding + or a backwards one, but you get the idea.
: Most combinator parsing libraries use user-defined operators to denote
: parser combination and choice, and GUI libraries tend to use them to
: denote things like signal connection, property setting and so forth.
And here we see a weakness of Haskell's approach: you need to know
the numeric precedence level. In Perl 6, all precedence levels
are defined relative to existing operators. You don't have to care
about the numeric level, and in fact, the actual precedence levels are
probably encoded with strings internally rather than numbers, because
that makes it trivial to add an arbitrary number of precedence levels
between any other two precedence levels without having to resequence.
Precedence levels are a bit like surreal numbers in that respect.
But the user doesn't have to know that...
: Wrangling this back to some sort of on-topicness, it would be great if
: Perl could have user-defined operators that actually work properly. I'm
: thinking new operator characters (Unicode's got lots left),
Gee, I'm thinking the same thing. Fancy that. 'Course, the fact
that I already said as much in the Apocalypses could have something
to do with it. :-)
: and also the
: ability to define short-circuit operators like C's && and || (I can't
: remember what they've become in Perl 6, did they change? I seem to
: remember them changing). Not being able to do this is a major weakness
: in C++'s operator overloading, because it effectively means that && and
: || are untouchable unless you really want to mess with other people's
: heads, and demonstrate the only point operator overloading has against
: it (that is the potential disruption of expected semantics; this is all
: IMO of course).
Well, any operator or function that knows how to call a closure can
function as a short-circuit operator. The built-in short-circuit
operators are a bit special insofar as they're a kind of macro that
treats the right side as an implicit closure without you having to
put braces around it. No reason in principle you couldn't write your
own infix macro to do the same thing.
: So can we at least have the ability to define short-circuit operators,
: even if we can't define new ones?
Already there. You can even define new short-circuit operators.
The new ones can even be Unicode operators, if you're willing to go
into hiding for the next five years or so till most everyone learns
how to type Unicode. Alternately, be willing to stare down the
occasional lynch mob...
On the other hand, we've tried to make it trivially easy to defer
evaluation of a chunk of code. All you have to do is slap some
curlies around it.
Larry
