Richard Fateman wrote:
....
>Adding python to the mix doesn't add utility, though it may serve to smooth
>the path for someone who wishes to write "free" and "portable" code, and for
>someone who doesn't like Lisp, or who thinks that Lisp is old and Python is
>new....
>
>
besides the point of "new" (fashionable language), adding Python will serve:
- python is easier for newbies than lisp, so they will start doing
things quicker
- python users will continue to use their favourite modules, while they
can't do this after moving to lisp.
>My approach would put (some) Lisp program in the center, rather than
>inserting some new center. The advantage is that at least one significant
>program can be used without any handicaps at all by the central hub. This
>choice of the central program environment means that encapsulization of its
>own types can be done rather easily. That is, encoding a lisp object in
>lisp, perhaps with a wrapper like (maxima ...lisp_stuff...) is pretty
>simple.
>
IMO this would be better approach, but its probably too late to convince
SAGE developers on doing this step :)
> Creating a python wrapper for a lisp object that allows for ANY lisp
>object seems much more challenging.
>
>
>
I'm right in the middle of creating Perl module that uses LISP at C
level w/o sockets *and* transparently passes both ways LISP objects.
This allows, for example, to use Tcl/Tk interface thorough Perl without
sockets.
The module is tiny, based on Stuart Sierra's perl-in-lisp.
If there's interest in this, I can prepare an example on using Maxima in
such tight integration with Tcl/Tk and Perl.
Best regards,
Vadim.