> On the other hand, if Parrot provides stacklessness, JIT compilation, > cross-language interop, and pushes some complex C-level maintenance burden > onto other people, perhaps you'll consider consider the laundry run and > drinks worth it in the end. No way to find out if Parrot is up to the task > without trying... That's why I'm taking the challenge. But I'm skeptical, and that's why I'm not too worried... > > OTOH there may be a devilish plan here to let Dan believe he won't > > have to work very hard, and then in the end he'll lose because your > > implementations are inefficcient... :-) > > For some reason the Parrot developers seem more focused on working with > bytecode; see Dan Sugalski's weblog at > http://www.sidhe.org/~dan/blog/archives/000205.html . Interesting indeed. The focus on bytecode is understandable: let someone else write a parser, so Parrot won't have to. But from skimming his log, Dan seems to take the bytecode too seriously; it's really only meant to be a quick way for the parser to output something. In particular, bytecode hacks were never a goal. (There's an amusing > link in the comments for a Python-bytecode-to-SAX-event-stream translator; > my mind is boggled.) Bytecode translation doesn't strike me as a very > useful course to follow, because Python's bytecode is vulnerable to being > changed between versions and because looking at bytecode provides less > information than looking at an AST. Sure, but bytecode evolves slowly enough to be useful for Dan; given that the only parse tree format we have is *intricately* linked with the Python parser and (at least part of) its runtime, I can see why Dan would have nothing of it. --Guido
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