Hi Nathan, Thanks. ByteBuddy is extremely overpowered for my use case. I am just spinning extremely light stub classes.
On Tuesday, May 19, 2020 at 10:38:52 PM UTC-7, Nathan Fisher wrote: > > There’s also bytebuddy which has commercial support if that’s important to > you. > > On Thu, May 7, 2020 at 14:47, Steven Stewart-Gallus < > [email protected] <javascript:>> wrote: > >> Hi, >> >> Just going to update this thread with a link to the repo I am asking this >> question for which I finally see fit to share >> https://github.com/sstewartgallus/jsystemf . >> >> Mostly copypasting from a reddit post I made. >> >> So I plan to use this as the core of a functional language similar to >> the Glasgow Haskell Compiler's core but for now I don't have a higher >> language made yet. >> >> Atypically I use higher order abstract syntax for the core IR. Higher >> order abstract syntax cheats for implementing things like closures by >> using lambda expressions. I compile these lambdas to a point free >> representation by repeatedly substituting the free variables with >> pairs. >> >> Basically Type.INT.l(x -> Type.INT.l(y -> x)) becomes rewritten to >> something like curry(Type.INT.and(Type.INT).l(v -> v.second())) which >> then can be reduced to simple category theory based combinators (It's >> well known the lambda calculus can be compiled to closed cartesian >> categories see http://conal.net/papers/compiling-to-categories/ .) >> Unexpectedly I found that evaluation of the product of a thunk and a >> function Category<<F<A, B>, A> can be implemented using uncurrying and >> currying implements closures. >> >> After I compile to a point-free closed cartesian category combinator >> representation I then compile my types to a similar >> representation. Just as lambda abstraction is curried so is universal >> quantification over types. Interestingly existential quantification >> plays the same role products play in compiling functions. >> >> Still I haven't really implemented generics properly yet and I >> struggle a bit because of Java's mediocre type system and also because >> this is something I have mostly figured out myself. >> >> Next I compile the CCC representation to MethodHandle. As a legacy of >> an earlier much more complicated code base before I settled on the CCC >> representation I use bytebuddy to spin custom closure types that >> represent an environment + a method. I use invokedynamic heavily for >> linking calls. I still haven't implemented supersaturated/partially >> saturated callsites yet meaning that multiargument Invokers >> (dynamically spun classes that fill interfaces for invoking function >> values) don't really work. >> >> I think I'm pretty confident I have a solid foundation now though and >> just have to figure out the type representation at runtime. Currently >> the type Type is more akin to a ClassDesc in Java than an actual live >> Class value. I need to figure out how to instantiate/cache generic >> types and methods. I hope that by flattening generic tuple types I can >> recover a more JVM native argument passing convention as as of now >> everything is boxed into pairs. >> >> A lazy pure functional language on the JVM has been an itch I've been >> trying to scratch for a while (even playing with GraalVM at times, >> which proved not flexible enough) but I think I've figured out a solid >> foundation with this even though I have not yet implemented tail calls >> or lazy evaluation. >> >> I thought some of you might be interested in this kind of bytecode >> spinning stuff. >> >> On Sunday, April 26, 2020 at 9:36:07 AM UTC-7, Steven Stewart-Gallus >> wrote: >>> >>> I'm spinning a lot of classes dynamically for an interpreter. >>> I'm not sure the best way to load the classes into the VM. >>> >>> Aside from Unsafe's defineAnonymousClass what's the best way to load >>> classes into the VM? >>> >>> I believe I could create a new classloader for each spun class but IIRC >>> classloaders are expensive. >>> >>> I believe as much as possible I'd want to reuse MethodHandle and >>> LambdaMetafactory to rely on the JVMs use of defineAnonymousClass. >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/mechanical-sympathy/1d74256c-f60c-453f-98c8-0452230732b9%40googlegroups.com >> >> <https://groups.google.com/d/msgid/mechanical-sympathy/1d74256c-f60c-453f-98c8-0452230732b9%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > Nathan Fisher > w: http://junctionbox.ca/ > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/6bb30eb7-d520-44fd-9c6c-bb62423277cc%40googlegroups.com.
