>>>>> "Frank" == Frank Duncan <fr...@kank.net> writes:
Frank> Based on a discussion on hipchat, I had a question about NetLogo Frank> bytecode compilation. Frank> Why not compile to scala or java, then have the standard Frank> compiler generate bytecode from that for a nlogo file? Have we Frank> ever tried? The original decision on this predates my involvement with the project -- it would have happened at Tufts circa 1999. I don't know if the approach you suggest was even considered at the time, but if it was, I'm guessing it was rejected on the grounds that end users didn't have javac on their computers. Of course now it's possible to ship the javac and/or scalac jars with the application, but when NetLogo started, the main use scenario was as an applet running in a browser. The desktop application didn't become the main use scenario until later. Another consideration may have been that when NetLogo started, `ask-concurrent` (which was the default way `ask` worked back then), including Termites-style modeling with turtle forever buttons, was central to the design and implementation. That implied that NetLogo code be suspendable at any point without blocking a thread, and since Java lacks coroutines / continuations / generators, a straightforward "transpiler" preserving the basic structure of the source code, like we have in Tortoise, wouldn't been sufficient. (An alternate design where each `nvm.Context` had its own thread and context-switching occurred via locks was, if even considered, presumably rejected on the grounds of too-high resource usage.) In 2005, when Forrest and I started work on the bytecode generator, could we have used the approach you suggest for the generator only, while leaving the rest of the compiler alone? We would have had the applet problem, but this could be surmounted by making "Save as Applet" save out compiled bytecode, instead of running the compiler in the browser, as we still did then and still do today. I think we actually discussed involving javac, but I don't remember any details. We may have been concerned that using Java as an intermediate language would be too restrictive because we wouldn't have full control over the resulting bytecode. (Unless we rewrote the bytecode coming out of javac, but at point, we'd be risking doubling the amount of work we'd be doing, since we'd need to generate Java source *and* get our hands dirty with direct manipulation bytecode.) As far as I can recall, generating bytecode directly seemed like the simplest approach that promised nice speed gains for a manageable level of effort. What about now? In some hypothetical future version of NetLogo where neither applets nor `ask-concurrent` were any longer supported, I think it could be worthwhile to back up and rethink the entire architecture. If we were starting over now, I think "transpiling" to Java, Scala, Clojure, or JavaScript (run on the JVM using Nashorn) could definitely be worthwhile approaches. (If we dropped support for Java 5, 6, or 7, we'd be free to use Java 8's new `invokedynamic` instruction, too.) I could probably go on for pages more about the pros and cons of this approach (and the pros and cons of the possible choices of target language for the transpiler), but I'm not sure it's worth doing unless someone is really seriously considering writing a grant around it or making it their PhD thesis. Are you asking mainly out of semi-idle curiosity, or are you serious about this as a possible way forward for the project? And if so, why? -- Seth Tisue | http://tisue.net -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to netlogo-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
