On Sat, Sep 03, 2005 at 11:45:33 +0300, Yuval Kogman wrote a lot. I'd like to summarize:
* if operators are not special than they are defined in perl 6
(maybe)
* if operators are defined in terms of other operators, then
overriding an operator may interfere with the definition of
another operator.
* if all operators are defined in terms of each other, perl 6 is
circular. At some point the loop must be broken, and
functionality has to be delegated to the runtime.
* one way to do this is to infer where operators are not
overridden
* each "builtin" code may have an alternative version in the
native runtime's language
* if a bit of code is kown, by inferrence, to be completely
unaltered, the native could is used instead.
* essentially the role of inferrencing here is to determine
where, and to what extent may the circularity be broken.
* functions which must have a runtime counterpart (like IO) are
defined as stubs. They can be overridden for emulation purposes,
or die as "not yet implemented" when the runtime can't provide a
native version.
This is possibly slow to compile, and possibly dangerous to allow.
I think that the best solution is to allow overriding builtins only
in the current lexical scope, unless this circularity is explicitly
asked for.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!!!!!
pgpdMqa2opdoI.pgp
Description: PGP signature
