user-defined operators?
Michele Dondi
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...
Michele
--
Dante, _The Inferno_, in particular the line about, ``Abandon all hope ye who
enter here.''
- William F. Adams in comp.text.tex, "Re: Book Suggestion for MS Word?"
Matthew Walton
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.
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. 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.
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), 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).
So can we at least have the ability to define short-circuit operators,
even if we can't define new ones?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA2rP20UvYjCBpIlARAsFKAJoCBjgP8+wmbQP3XO1HLD+6AC43DQCfVvj3
kTT9cYnblCADyVCWCrpcpD0=
=G7FE
-----END PGP SIGNATURE-----
Larry Wall
: 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...
Yes, this is already provided for with infix/postfix operators/macros,
with the caveat that if you wish to specify multiple arguments to the
left, you'll have to do one of:
1) give your operator a looser precedence than comma
2) group the arguments with some kind of brackets or parens to
make them a single argument
3) put some kind of introductory macro out front that parses
things the way you want
4) write the definition of your infix/postfix macro to have
incestuous knowledge of the parser in order to slurp the
leftwise arguments that have already been reduced by the
ordinary grammar. Simple. :-)
Actually, I suspect that infix macros have precedence much like operators,
so #4 probably reduces to #1. (Macros differ from ordinary operators in
how they treat the subsequent text, not the preceding text.)
Larry
Larry Wall
: -----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
Matthew Walton
Hash: SHA1
Larry Wall wrote:
| 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.
I immediately start to feel very stupid, because I've definitely read
the Apocalypse about this.
| 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...
Yes, numeric precedence levels aren't really such a great idea. I
suppose one could have floating-point ones, but then you get precendence
levels like 2.56728, and things get even more confusing. The Perl 6 way
sounds a lot better.
| : 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. :-)
Probably. My small brain isn't capable of remembering everything in the
Apocalypses, they're just too exciting ;-)
Fabulous. That's exactly what I wanted to hear :-) I thought it might be
something to do with passing closures around, as it seems pretty much
the only way to accomplish it anyway without altering things already
laid down which are Good Things.
I'm a very happy man now Larry. Thankyou.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA2+ig0UvYjCBpIlARAo5pAKCNNZbWWWBKK+FNNXmntxFmBlq1kACfb+E4
T5cBANE6a2kDZ0QwcAA8aqs=
=pObn
-----END PGP SIGNATURE-----
Alexey Trofimenko
> 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.
if I got it right, you mean that in perl6 it would be correct (perl5
syntax):
$a and my $b=1;
is the same as
$a and do {my $b=1}
or, more correct:
$a and sub {my $b=1}->()
in perl5 it isn't the same. What about lexical scoping? or "implicit
closure" shouldn't be taken literally?
Luke Palmer
> On Thu, 24 Jun 2004 10:55:26 -0700, Larry Wall <la...@wall.org> wrote:
>
>
> >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.
>
> if I got it right, you mean that in perl6 it would be correct (perl5
> syntax):
>
> $a and my $b=1;
>
> is the same as
>
> $a and do {my $b=1}
No. It's more like:
my $b;
infix:and($a, { $b=1 });
The fact that the my is stated outside the block is an unsolved problem
that is going to be dealt with. When macros are used, there has to be
something that assigns the inner lexical variables to the correct
lexical scope. We just don't quite know how we're going to do it yet.
And of course we want it to be possible to assign it to an incorrect
lexical scope, if the need arises.
Don't worry, the scoping will all work out in these cases... somehow.
Luke