>>>>> "AMK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes: AMK> It should be possible to try out new operators *right now*, AMK> with no core changes. I believe Jeremy's compiler code, AMK> written in pure Python, can parse a module and generate the AMK> corresponding bytecodes. Therefore, you could take that code AMK> and hack it to support 'a .| b', by generating equivalent code AMK> to a.__dotbar__(b), or whatever. The only visible difference AMK> is that some error messages would be obscure; 2 .| 1 would get AMK> a '2 has no attribute __dotbar__' exception; this isn't AMK> significant. There is one hitch. There is a corresponding bytecode op for each of the builtin operators. When Python sees 'm * x + b', it generates BINARY_MULTIPLY and BINARY_ADD opcode. If you wanted to add a new binary operator, you couldn't add a new opcode for it. Instead, you'd have to generate explicit instructions to check for the attr and then call it. This isn't a big problem, although the resulting interpreter is probably slower than one with builtin opcodes. Not sure how much slower. AMK> So, rather than add a whole bunch of new operators to the core, AMK> I'd first want to see the alternative syntax implemented AMK> through a hacked parser and *in use by a significant AMK> community*, and then we can consider what bits from it to add AMK> to the core. This seems like a reasonable approach to me. You basically build a frontend that compiles the Python+extensions into standard Python bytecode. Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4