prolog? leaks pvars out of its context.

[NHALX]

(0-) (let PZ (prolog? (return Free)) \\ Free isn't derefed
       (prolog? (receive PZ)
                (unify PZ 1)         \\ Should fail because PZ should not be a logic variable in this context
                (return PZ)))
1

(1-) (shen.pvar? (prolog? (return Free)))
true

(2-) (symbol? (prolog? (return Free)))
false

It's more noticeable in larger code where the old pvar get's reclaimed before being used again: "Exception in vector-ref: 19 is not a valid index for #(10 shen.-null- ...."

[tizoc]

@NHALX how does this behave in SP?

[NHALX]

@tizoc SP does the same thing.

This thread talks about it a bit https://groups.google.com/forum/#!topic/qilang/xE67c7o7zkk

It's unclear how it should best be handled, but the way it is now isn't so great.

[tizoc]

@NHALX does SP with the new prolog still behave like this? if not, which decision was made?

[NHALX]

@tizoc Not sure how SP handles this now, but I think the best choice is to either modify 'return' or create a variant which converts unbound pvars to normal variables with the same name (or some special 'dead' value). The full dereferencing which currently happens on return needs to traverse and re-build the whole term anyway so there would be no performance hit.

Making PVars reusable in different contexts is possible, but it adds extra constraints to the implementation which may have performance implications.

Anyway, the first option doesn't preclude the second, and is basically just a cut and paste job with minor modifications.