Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-05 Thread Charles Oliver Nutter
- 5aa401f > OMR - 101e793 > IBM - b4a79bf) > > so it's an implementation bug, #2 seems to be the right solution. > > Rémi > > -- > > *De: *"John Rose" > *À: *"Da Vinci Machine Project" > *Envoyé: *Mercredi

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-03 Thread John Rose
o be the right solution. > > Rémi > > De: "John Rose" > À: "Da Vinci Machine Project" > Envoyé: Mercredi 3 Janvier 2018 20:37:42 > Objet: Re: Writing a compiler to handles, but filter seems to executed in > reverse > On Jan 2, 2018, at 12:35 PM, Ch

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-03 Thread Remi Forax
, AOT enabled) OpenJ9 - 5aa401f OMR - 101e793 IBM - b4a79bf) so it's an implementation bug, #2 seems to be the right solution. Rémi > De: "John Rose" > À: "Da Vinci Machine Project" > Envoyé: Mercredi 3 Janvier 2018 20:37:42 > Objet: Re: Writing a compile

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-03 Thread John Rose
On Jan 2, 2018, at 12:35 PM, Charles Oliver Nutter wrote: > > Is there a good justification for doing it this way, rather than having > filterArguments start with the *last* filter nearest the target? No, it's a bug. The javadoc API spec. does not emphasize the ordering of the filter invocation

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-03 Thread John Rose
On Jan 2, 2018, at 12:36 PM, Charles Oliver Nutter wrote: > > An alternative workaround: I do the filters myself, manually, in the order > that I want them to executed. Also gross. (Under the theory that the spec. is ambiguous, leading to implementor's choice, this would be your only option.) _

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-03 Thread Remi Forax
.@headius.com >>> ] > >>> À: "Da Vinci Machine Project" < [ mailto:mlvm-dev@openjdk.java.net | >>> mlvm-dev@openjdk.java.net ] > >>> Envoyé: Mardi 2 Janvier 2018 21:36:33 >>> Objet: Re: Writing a compiler to handles, but filter seems to

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-02 Thread Charles Oliver Nutter
;> 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 >>> >>> -- >>> >&g

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-02 Thread Charles Oliver Nutter
uage to a loop >> combinator somewhere, >> i will try to find that (or rewrite it) tomorrow. >> >> cheers, >> Rémi >> >> -- >> >> *De: *"Charles Oliver Nutter" >> *À: *"Da Vinci Machine Project&qu

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-02 Thread Charles Oliver Nutter
orrow. > > cheers, > Rémi > > -- > > *De: *"Charles Oliver Nutter" > *À: *"Da Vinci Machine Project" > *Envoyé: *Mardi 2 Janvier 2018 21:36:33 > *Objet: *Re: Writing a compiler to handles, but filter seems to executed > in re

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-02 Thread Remi Forax
gt; À: "Da Vinci Machine Project" > 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. A

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-02 Thread Charles Oliver Nutter
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 wrote: > Ahh I believe I see it now. > > filterArguments starts with the first filter, and wraps the incoming > target handle

Re: Writing a compiler to handles, but filter seems to executed in reverse

2018-01-02 Thread Charles Oliver Nutter
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_