You also need the loop combinator for implementing early return (the return keyword), I think i have an example of how to map a small language to a loop combinator somewhere, i will try to find that (or rewrite it) tomorrow.
cheers, Rémi > De: "Charles Oliver Nutter" <head...@headius.com> > À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net> > Envoyé: Mardi 2 Janvier 2018 21:36:33 > Objet: Re: Writing a compiler to handles, but filter seems to executed in > reverse > An alternative workaround: I do the filters myself, manually, in the order > that > I want them to executed. Also gross. > On Tue, Jan 2, 2018 at 2:35 PM Charles Oliver Nutter < [ > mailto:head...@headius.com | head...@headius.com ] > wrote: >> Ahh I believe I see it now. >> filterArguments starts with the first filter, and wraps the incoming target >> handle with each in turn. However, because it's starting at the target, you >> get >> the filters stacked up in reverse order: >> filter(target, 0, a, b, c, d) >> ends up as >> d_filter(c_filter(b_filter(a_filter(target)))) >> And so naturally when invoked, they execute in reverse order. >> This seems I am surprised we have not run into this as a problem, but I >> believe >> most of my uses of filter in JRuby have been pure functions where order was >> not >> important (except for error conditions). >> Now in looking for a fix, I've run into the nasty workaround required to get >> filters to execute in the correct order: you have to reverse the filters, and >> then reverse the results again. This is far from desirable, since it requires >> at least one permute to put the results back in proper order. >> Is there a good justification for doing it this way, rather than having >> filterArguments start with the *last* filter nearest the target? >> - Charlie >> On Tue, Jan 2, 2018 at 2:17 PM Charles Oliver Nutter < [ >> mailto:head...@headius.com | head...@headius.com ] > wrote: >>> Hello all, long time no write! >>> I'm finally playing with writing a "compiler" for JRuby that uses only >>> method >>> handles to represent code structure. For most simple expressions, this >>> obviously works well. However I'm having trouble with blocks of code that >>> contain multiple expressions. >>> Starting with the standard call signature through the handle tree, we have a >>> basic (Object[])Object type. The Object[] contains local variable state for >>> the >>> script, and will be as wide as there are local variables. AST nodes are >>> basically compiled into little functions that take in the variable state and >>> produce a value. In this way, every expression in the tree can be compiled, >>> including local variable sets and gets, loops, and so on. >>> Now the tricky bit... >>> The root node for a given script contains one or more expressions that >>> should be >>> executed in sequence, with the final result being returned. The way I'm >>> handling this in method handles is as follows (invokebinder code but >>> hopefully >>> easy to read): >>> MethodHandle[] handles = >>> Arrays >>> . stream (rootNode.children()) >>> .map(node -> compile(node)) >>> .toArray(n -> new MethodHandle[n]); >>> return Binder. from (Object. class , Object[]. class ) >>> .permute( new int [handles. length ]) >>> .filter( 0 , handles) >>> .drop( 0 , handles. length - 1 ) >>> .identity(); >>> In pseudo-code, this basically duplicates the Object[] as many times as >>> there >>> are lines of code to execute, and then uses filterArguments to evaluate >>> each in >>> turn. Then everything but the last result is culled and the final result is >>> returned. >>> Unfortunately, this doesn't work right: filterArguments appears to execute >>> in >>> reverse order. When I try to run a simple script like "a = 1; a" the "a" >>> value >>> comes back null, because it is executed first. >>> Is this expected? Do filters, when executed, actually process from the last >>> argument back, rather than the first argument forward? >>> Note: I know this would be possible to do with guaranteed ordering using >>> the new >>> loop combinators in 9. I'm working up to that for examples for a talk. >>> - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
