On Fri, Jul 14, 2000 at 01:36:20PM -0400, Eric S. Raymond wrote: >Huaiyu Zhu <huaiyu_zhu@yahoo.com>: >> This is not a call for a special language for matrix only. But we do need >> enough binary operators to override with. The additional operators might be >> useful at other places as well. > >I agree that supporting user-defined syntax threatens to fragment the language. >To avoid that, perhaps it would be best to leave what are in effect >user-definable hooks in Python's lexical space. Huaiyu Zhu thinks that better matrix operators will attract a significant new of new users; I'm doubtful of this claim. We're both just guessing, since neither of us has actual evidence to support our respective points of view. Given that uncertainty, there seems little impetus for adding new operators; Python will have to live with them for a long time, even if the matrix work withers after a short time, or never really catches on. It should be possible to try out new operators *right now*, with no core changes. I believe Jeremy's compiler code, written in pure Python, can parse a module and generate the corresponding bytecodes. Therefore, you could take that code and hack it to support 'a .| b', by generating equivalent code to a.__dotbar__(b), or whatever. The only visible difference is that some error messages would be obscure; 2 .| 1 would get a '2 has no attribute __dotbar__' exception; this isn't significant. So, rather than add a whole bunch of new operators to the core, I'd first want to see the alternative syntax implemented through a hacked parser and *in use by a significant community*, and then we can consider what bits from it to add to the core. --amk
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