Leon> > Of course it is :-) and it's a pity perl doesn't let you
Leon> > overload *everything*.
Leon>
Leon> I've recently been thinking about this, in the context of
Leon> Parse::Perl, a pure Perl parser. Now, writing a Perl parser in
Leon> Perl isn't really that hard. All you have to do is convert the
Leon> C parser to Perl, which you can do in a semi-automated way. The
Leon> problem is making Parse::Perl useful: people are going to use
Leon> it to change the language, and currently the parser is *very*
Leon> tied to the lexer, which is horrible C code very tied to the
Leon> current Perl. I'm almost convinced that we need a new parsing
Leon> solution (and get completely away from yacc and lex). But that
Leon> won't be easy, will it Damian ;-) What do you guys reckon? How
Leon> much are you going to want to change the language?
My plans for the Parse::Perl module are that it will be based on a
RecDescent (or, rather, a FastDescent) grammar. This will (probably)
not be as fast as a C-implemented parser, but may still be fast enough.
More importantly, because it will be a P::RD/P:FD grammar, you'll be
able to $parser->Extend(...) or $parser->Replace(...) particular parsing
rules at whim.
Dave> I have frequently wanted to overload operators when not using
Dave> objects - for example, I wanted to overload == to tell me
Dave> whether a list contained a certain scalar - of course, now I
Dave> can just do if($foo == any(@list)) but using Q::S makes my code
Dave> much slower, and using it in production code seems rather
Dave> silly.
I still have high hopes that some subset of the Q::S functionality will
make it into Perl 6 (in the core, so there are no speed penalties). See
http://www.yetanother.org/damian/Perl5+i/disjunctives.html
Leon> % perldoc -q contains
Leon> How can I tell whether a list or array contains a
Leon> certain element?
Leon>
Leon> Hearing the word "in" is an indication that you probably
Leon> should have used a hash, not a list or array, to store
Leon> your data. Hashes are designed to answer this question
Leon> quickly and efficiently. Arrays aren't. ...
You know, I've *never* subscribed to this argument. Perhaps it holds
true if you're doing repeated membership tests on the same set of data,
but the fact that people *want* to one-shot write code like this says to
me that they *ought* to be able to.
I can imagine an 'in' operator that caches array membership
information on every query (in the array itself), so that asymptotic
cost of an 'in' is O(1) rather than O(n).
Damian
