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.
