NAME
Language::Lisp::ECLs - Perl extension for ECL lisp
SYNOPSIS
use Language::Lisp::ECLs;
my $cl = new Language::Lisp::ECLs;
my $r = $cl->eval_string("(format nil \"[~S]\" 'qwerty)");
my $lam = $cl->eval_string("(lambda (x y) (+ x y))");
$lam->funcall(5,9); # results 14DESCRIPTION
Language::Lisp::ECLs is a bit easier to use than Language::Lisp because of embeddable nature of ECLs. Language::Lisp uses different approach because they are other way down: Lisp calls Perl and not vice versa.
new()
The new method used to create Language::Lisp::ECLs object which is used to talk with underlying lisp. This object looks like an interpreter instance, although there is actually no interpreter instance created. Instead, this object is used to create a handy way of invoking API: given that you have $cl object you can execute:
my $res = $cl->eval_string("(format nil \"~A\" (expt 2 1000))");which is equivalent to
my $res = Language::Lisp::ECLs::eval_string(undef, "....");but is much better to use.
Passing parameters to ECL and getting results from ECL
Required Perl objects converted to Lisp objects and vice versa. Compatible types are converted as-is (e.g. ECL type t_integer becomes SvIV), all other types are blessed into some package, for example into Language::Lisp::ECLs::Symbol
This is done behind the scenes and user should not bother about this.
This makes following code to work:
my $lam = $cl->eval_string("(lambda (x y) (+ x y))");
print $lam->funcall(40,2); # prints 42
print $cl->funcall($lam,40,2); # ... another way to say the same$cl->eval_string(string)
runs string within ECLs interpreter and returns whatever lisp returns to us. Internally this transforms to the call si_safe_eval(...);
$cl->eval(lisp_object)
same as eval_string but takes lisp object instead of string as argument.
$cl->keyword("QWERTY")
returns LISP keyword as a symbol (from Per side this means it is blessed to Language::Lisp::ECLs::Symbol package). In Lisp this symbol belongs to the 'keyword' package.
$lispobj->funcall(...)
given lisp object blessed to package Language::Lisp::ECLs::Code calls the procedure.
AUTOLOADing
$cl->someFunctionName(args) get transformed into function call to "some-function-name"
This is done by finding lisp object for evaluating arguments, and blessing it into Language::Lisp::ECLs::Code package
$cl->prin1("qwerty");
TODOECL Objects
Language::Lisp::ECLs::Symbol
LISP symbols are blessend to this package
Language::Lisp::ECLs::Package =head3 Language::Lisp::ECLs::String
Language::Lisp::ECLs::Char
Object to represent character type within Lisp. Here are 3 equivalent ways to get it:
$ch = $cl->char("c");
$ch = $cl->char(ord("c"));
$ch = Language::Lisp::ECLs::char("c");Another way is:
$ch = $cl->eval_string('#\c');Language::Lisp::ECLs::Code =head3 Language::Lisp::ECLs::Generic
Language::Lisp::ECLs::List
If you have a list object in Lisp, it will be automatically blessed into the Language::Lisp::ECLs::List package:
my $list = $cl->eval_string("'(a b c d qwerty)");List object have item(n) method to return n-th value from the list.
List object have TIEARRAY, FETCH, FETCHSIZE methods and so ready for tie-ing as array with a tie perl funciton:
tie my @arr, "Language::Lisp::ECLs::List", $list;Even simplier, $list have _tie method to return tied array reference:
my $arr = $list->_tie;Fetching items from this array works, storing them currently do not work.
Language::Lisp::ECLs::HashTable
EXPORT
None. No namespace pollution, the greens are happy.
BUGS
ECL uses Boehm GC, and at the moment of writing it did not had reliable interface on returning memory to GC, so the leaks of memory are unavoidable.
funcallcan not take more than 10 args - this should be fixed.
SEE ALSO
Language::Lisp
See ecls.sf.net to read about ECL lisp project.
AUTHOR
Vadim Konovalov, <vkon@cpan.org>
COPYRIGHT AND LICENSE
Copyright (C) 2008 by VKON
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.004 or, at your option, any later version of Perl 5 you may have available.