| [reply] |
Yeah, once I've gotten the binding down I hope to be able to do something like:
use Slang::Scheme::Guile;
guile-sub add( $a, $b ) { + $a $b }
say add(1,3); # 4
because my *ultimate* goal is to use this to embed the logic programming language Kanren into Perl 6, which is a set of Scheme primitives that provide goal-searching and backtracking. You could do something like:
use Slang::Kanren;
kanren-fact parent('marcia','jeff');
kanren-fact parent('mike','jeff');
kanren-fact parent('gerald','mike');
# Find out if Jeff shares a common parent with Gerald
kanren-goal { parent('gerald',X), parent(X,'jeff') }
This is of course fairly abstract, and I haven't really researched what the function binding is, I've been working more on the Scheme side. | [reply] [d/l] [select] |
Wouldn't it be more productive -- not to mention more useful -- to build a native Scheme frontend for the MoarVM?
| [reply] |
Scheme running on MoarVM would be nice, to be sure, if only to prove that it can be done. It would be several orders of magnitude slower because modern Scheme compilers (like modern Lisps) compile to machine code.
Connecting to the interpreter thread is one function call, and unmarshalling back to Perl 6 is a very simple and fast callback, I expect that most of the time spent on a single invocation of $g.run('(+ 5 4)') is in the unmarshalling of the single SCM cons cell back to Perl 6.
As to being more productive, I suppose I could have taken several months to learn MoarVM, read R6RS, do two or three test implementations until I worked out the approach, lost D20 SAN implementing call/cc, and gotten for my efforts a trivial Scheme running hundreds of times slower than any actual working implementation, and then still would have to write the Perl 6 - Scheme bridge, this time on MoarVM.
Or I could take a few nights to read the GNU Guile docs, write a 200-line helper library, and get Perl 6 quickly talking to a fast, debugged, and more importantly working Scheme implementation. Perl 6 is -Ofun, and while doing all of the MoarVM backfill may be fun to some, and maybe if I get into it it'd be fun to me, but right now it's someone else's itch to scratch.
All in all, I'll take the NativeCall route, and let someone that knows the MoarVM innards and loves the challenge of building a new grammar, AST generator, compiler and debugging the entire toolchain do the work. Life's too short.
| [reply] |
I suppose it depends on what you intend to use it for; but I for one don't see a whole lot of utility in being able merely to call out to another language as a black box, like a coprocessor. I'd want my scheme (or whatever) code to be able to access my perl code & variables, just as if it were written in perl. Using a common machine like MoarVM or JVM makes this possible.
| [reply] |