-----BEGIN PGP SIGNED MESSAGE----- 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 ;-)
| : 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.
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-----
