We can insert scheme expressions with the construct
scm[sexp]. You can insert it like, remember that this ideam is always executed at the composition of a list e.g. they are not lazy by any means.
:- scm[(export a b c)]
2) function arguments and list arguments
f(X) :- g(X, scm[(dub (<scm> X))], scm[*global-variable*])
3) In expression constructs
f(X) :- X is scm[(dub X)].
It’s possible to execute a scheme expression in a goal for secondary effects by e.g.
do[...], the value of the scheme expression inside the bracket will never be exposed and, it’s fine to put the do expressions inside a list, they will be constructed a lazy expression and only evaluated if it later is executed as a goal. Another variant if this is
with[...], the difference is that the value of the scheme expression inside a bracked will guide the success of the goal if it is false then the goal failes.
To note is that currently we have no way of protecting code that are read by e.g.
read_term to include any of these expressions, hence there it is not safe to read in code and execute it, beware. A feature request is an ability to turn off this feature when reading in terms. There is two other holes left in order to safely be able to execute code inside a sandbox. First namespacing has to be controlled and secondly namespaced code that are read in, that refers to a macro inside the guile code base will run. The solution to the first is already implemented, we can specify which namespaces we allow for the code read in. And for the second issue we can add code that checks that the read in functions does not refer to a macro, again included in our Todo.
#t,#f can be used as literals as well as keywords like
#:keyword. The reason for this is to be able to interoperate with scheme and kanren as well as be able you ues goal functions that have keyword argument(s).