Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
New qq #188
Instead of analysing and generatic code that will recreate R's SEXP tree,
do define "x_hs" (mkSEXP x_hs) define "y_hs" (mkSEXP y_hs) x <- tryEval "plot(x_hs, y_hs)" undefine "x_hs" undefine "y_hs" return x
Non simplified version uses withGlobalyDefined helper instead of
This approach seems very reasonable unless we don't want to change
In this form parsed expressions could be floated out. However it's
There seem to be two main issues, or 1 issue and 1 maybe-issue-depends-who-you-ask. First the obvious one from the diff, closures being broken:
Seems like a pretty big regression. AFAIK @qnikst wanted some review before digging into it further though. I don't know what the policy is but I wonder if it'd be better to have ‘expecting to fail with such and such message’ test rather than just comment it out. At least then we might catch when something changes again.
Second problem is change of semantics in how values that get mutated work. Notably, on master:
but with this PR:
What the right result should be is ‘it depends’. Personally I'd expect 12, i.e. look from the Haskell side where values are immutable and we're effectively splicing, something like
This gives a suggestion on how to implement such a thing, that is by binding each separate occurance of
But if you ask
Whatever we settle on, I think we should have a test: this is a change in behaviour that went under the radar.
Just going to leave very minor nitpicks in-code but otherwise I see no other issues.
1st problem with closures.
> x <- 5 > z <- function(y) x + y > z(0)  5 > x <- 4 > z(0)  4
Why everything worked before: we have modified SEXP tree, and instead of reference, we substibuted a value. So there we no lookup at all, and tree that for
so after execution of
How could we workaround this problem.
2nd problem is very interesting. On the contrary to the first one I have not considered that issue and never tested that (as you can see we had no test to caught that problem).
I think that the "sanity-test" here will be: observable result of splitting QQ into several one should be equal to result of the expression. In this example:
The only solution for that bug that I see is to create a separate entry for each use of the variable, i.e.
let v = mkSEXP assign("x_hs_1", v, globalEnv) assign("x_hs_2", v, globalEnv) parseEval("abs(x_hs_1) + x_hs_2") unassign("x_hs_1") unassing("x_hs_2")
Or just document this problem with a big fat warning that user should not do such a tricks.
Surely meant to be
I think that assigning a different name for each place Haskell variable is used is the easiest approach with new qq.
Warnings only work when the user is in control of the whole code… What if the user is using a library which does something like this?
No, it should be
I agree with that, so I think we need to agree on details of implementation here.