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!!!!!!!
Description: PGP signature