Thank you for your reply. Very insightful. Are you building it for a particular purpose like a compiler, or as a > curiosity? >
I built it for a number of yet-unreleased projects I'm working on. One of which is a compiler of sorts. I will get around to open-sourcing them eventually. The CLR is quite verbose and many parts of the bytecode emission machinery > require a lot of configuration to work > Since I posted this I have subsequently read more about the CLR's Reflection.Emit machinery, and I can see more why you chose this approach. Bytecode emission via ASM (and the JVM in general) is simpler and more straightforward AFAICT. MAGE's il/local constructor function will produce a symbolic local variable > Related to the above, I understand this better now that I am more familiar the concepts of Reflection.Emit and DeclareLocal <https://msdn.microsoft.com/en-us/library/system.reflection.emit.ilgenerator.declarelocal(v=vs.110).aspx> . Mage will automatically flatten nested bytecode sequences. > I recently converted one of my projects from emitting via insn.op <https://github.com/jgpc42/insn/wiki/Interface-Implementation>, to splicing seqs together for testing purposes. So I actually see more of this feature's value. I might implement this soon. MAGE does support emitting types, modules and assemblies directly into > memory To clarify, I was not asserting that MAGE does not support emitting to memory, only that the README states that a .dll is always written to disk. ... MAGIC project where it gets used and tested pretty extensively I see. I did not think to check there. Thank you again. I will also check out your blog. On Wednesday, September 6, 2017 at 6:48:13 PM UTC-7, Ramsey Nasser wrote: > > Hello! MAGE author here. First off, insn looks super cool! I am excited to > see where the project goes. Are you building it for a particular purpose > like a compiler, or as a curiosity? > > With respect to MAGE, > > Mage provides fns for yielding the Clojure data that it consumes > > ... > > I ultimately decided against this approach. I felt that using raw Clojure >> data provided more clarity, which is of course subjective. > > > Agreed, it's subjective. The CLR is quite verbose and many parts of the > bytecode emission machinery require a lot of configuration to work, and the > constructor functions allow me to set a lot of defaults in one place and > leave them out of the core emission logic. I got the approach from Kovas > Boguta's gamma library and haven't changed it since. > > Mage will automatically flatten nested bytecode sequences. This is not >> necessary in my opinion since you can just use unquote-splicing within an >> op sequence. > > > True, but you don't lose anything to flattening bytecode sequences, and > being able to return vectors of bytecode (or even nil) from functions is > very convenient. In an environment without a stack language (like LLVM), > I'd probably reconsider this, but I really like not worrying about the > shape of my symbolic bytecode as I generate it. > > Mage has the concept of named local variables. > > > This isn't quite the case. Locals on the CLR do not have names and compile > down to offsets, but MAGE's il/local constructor function will produce a > symbolic local variable (just Clojure data like everything else) that will > get stitched together by the emission library at the end. I use Clojure's > let bindings to cause the same symbolic local to appear in multiple places > in the bytecode stream, and they get resolved to the same offset in the > final bytecode. > > Finally, mage seems to require always writing out an assembly .dll to disk >> on each emit. > > > Though the README does not demo it, MAGE does support emitting types, > modules and assemblies directly into memory. This is how MAGIC is able to > live side-by-side with ClojureCLR. That said, the CLR compiler ecosystem is > very much oriented around files, so I do end up emitting to disk a lot > while developing MAGE and MAGIC to take advantage of disassemblers and > other tools. > > I would also be nice if the mage author would provide some tests > > > More than happy to! Do you mean tests of MAGE in the repo? The most use it > gets is in the MAGIC project where it gets used and tested pretty > extensively: https://github.com/nasser/magic. > > I hope than answers some questions! If you're interested in this stuff > I've started documenting it in a dev blog over at http://nas.sr/magic/. > > Again, great work on insn and I am excited to see where it goes! > > R > > > On Saturday, August 19, 2017 at 12:49:54 PM UTC-4, jgp...@gmail.com wrote: >> >> While I'm not as familiar with the CLR and its bytecode syntax, from what >> I can tell from the README, mage and insn seem to have similar goals and >> ideas. >> >> I'll attempt to summarize the differences that I could find, if the mage >> author *nasser* is available I would appreciate his or her input. >> >> Mage provides fns for yielding the Clojure data that it consumes. At one >> point in development I also did this. Something like the following. >> >> (insn/visit :members [(insn/field [:public] "foo" :int) >> (insn/method :init [:int :void] >> [[:iload 1] >> #_...])]) >> >> I ultimately decided against this approach. I felt that using raw Clojure >> data provided more clarity, which is of course subjective. You can easily >> implement these and more application-specific versions yourself if you >> desire. I use the library for a couple of unreleased projects and I have >> fns named emit-box, emit-proxy-method, etc. >> >> Mage will automatically flatten nested bytecode sequences. This is not >> necessary in my opinion since you can just use unquote-splicing within an >> op sequence. >> >> Mage has the concept of named local variables. I don't know if this is a >> CLR concept, I assume this is a convenience feature to avoid having to >> refer to method locals by number. If so, I could easily implement this as >> it seems to be the same concept as Insn's autogenerated labels. >> >> Finally, mage seems to require always writing out an assembly .dll to >> disk on each emit. Not a big deal, but Insn allows more control in this >> regard as your generated classes may exist entirely in memory. >> >> Anyway, I hope this helped. Again I am only passingly familiar with mage >> and I have not read the source code. I would also be nice if the mage >> author would provide some tests. :) >> >> >> On Friday, August 18, 2017 at 10:44:54 PM UTC-7, Colin Fleming wrote: >>> >>> This looks very interesting. How would you compare this to Mage for the >>> CLR? Are they essentially equivalent? >>> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
