[clpython-devel] inline

Willem Broekema metawilm at gmail.com
Thu Mar 20 23:08:11 UTC 2008


Hello Eric,
Welcome to the list.

On Thu, Mar 20, 2008 at 10:34 PM, Jones, Eric SPC MIL USA FORSCOM
<eric.jones22 at us.army.mil> wrote:
> This may be a bit of the topic but would support for in-lining be
>  acceptable or even just close interoperability of the two languages.
>  Python and Lisp are similar but some pieces of code are more easily
>  implemented in one or the other. Maybe something like:
>
>  (LISP CODE)
>    (LISP CODE)
>       :@python
>         python code
>         python code
>       :@PYTHON
>    (LISP CODE)
>  (LISP CODE)

This is something I have thought about. There are some issues that
make this idea not very simple to do. Syntactically, indentation-based
Python code does not mix well with Lisp code. For that reason I think
the right granularity for mixed sources is whole top-level forms, not
inlined expressions like you in your example above. A semantic issue
when mixing code is that you have to define how Lisp bindings map to
Python variables, and how Python modules and Lisp packages should
relate to each other.

Note that the CLPython REPL has already some support for mixing
languages. The rule here is that input parsable as Python code is
Python code, everything else is Lisp code:

clpython(6): (repl)
[CLPython -- type `:q' to quit, `:help' for help]
>>> (1/2)      ;; valid Python code: truncating integer division
0
>>> (/ 1 2)    ;; invalid Python code, valid Lisp division: a ratio
1/2

Calling Python functions from Lisp or the other way around is not
straightforward. You could make use of the special variable '_'
indicating the result of the last expression. It is defined both as a
Python variable and a Lisp special variable:

>>> def f(x): return x+1
#<python-function f @ #x10fd7022>
>>> f(2)
3
>>> (funcall f 3)
;; Python parse failed:  SyntaxError: At line 1, parser got unexpected
token: `f'.
;; Lisp eval failed:  Attempt to take the value of the unbound
variable `clpython.app.repl::f'.
;; Current input is therefore ignored.
>>> f
#<python-function f @ #x10931b52>
>>> _
#<python-function f @ #x10931b52>
>>> (funcall _ 3)
4

Does this fit your use cases?

Cheers,
- Willem



More information about the Clpython-devel mailing list