Yes. In fact that is how I'm intending to target the CLR and JVM in my own environment -- whether I successfully implement the ability to use Factor (the language) inside my platform or not. I was envisioning something like a combination of direct byte code generation (either MSIL or JVM byte code) together with whatever programmatic facilities are necessary for fixing up metadata tokens, invoking the respective jit compilers and the like. This could just as easily be done from the existing Factor environment as any custom environment I manage to construct and in a perfect world Factor code created in either environment would compile and execute in the other just fine.
You Factor guru types might be scratching your heads and wondering why on earth I would want to reproduce the factor booting mechanism in my own environment and build it on top of my own foundations instead of just using what Slava has already put so much work into. The answer is that while I'm not sure that this will be necessary (i might be able to get away with the DLL-ized version of Factor itself; I'm in major research mode about it as we speak), I suspect I may need to roll my own in order to integrate at as deep a level as I need with other language facilities I already have in place. That's as much as I'm going to say about it, because I don't want to commandeer the FactorCode.org airwaves to talk about my stuff. But whatever I end up doing, I do expect to give back to the community in the way of documentation of what I learn along the way. Sent from my iPhone On Aug 23, 2012, at 1:42 PM, "Joe Groff" <arc...@gmail.com> wrote: > On Thu, Aug 23, 2012 at 11:46 AM, Michael Clagett <mclag...@hotmail.com> > wrote: >> That, I would guess, is a result of its being implemented in C#. But what >> you lose at that point is the ability for the language to be used outside of >> the CLR and the extreme portability of something like Factor. What I'm >> envisioning is something closer to Microsoft's C++, which now has built-in >> support for generating MSIL, while still remaining completely viable on a >> native code platform. Such a capability for Factor (with the ability to >> generate JVM byte code as well) would allow Factor to act as a DSL layer >> above real-world code bases that organizations are always going to be using >> for a significant portion of their development. > > The JVM and CLR both have native code interfaces a Factor bridge could > take advantage of. I think that would be a more realistic avenue > toward interfacing with those platforms than rearchitecting Factor to > target the JVM or CLR directly. > > -Joe > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
