[pypy-dev] Re: recent lisp support / cross-language

[Michael Hudson]

holger krekel <hpk at trillke.net> writes:

> hello pypy,
>
> i think it's nice that we start to have clisp support. but there
> are no unit-tests and 'translator/gencl.py' adds more code to keep
> in sync with our model.  So without tests i wouldn't like this code
> to exist.

Yeah, perhaps it shouldn't have been checked in.  But it's not very
much code, and it's quite neat.

Oh, and don't say "clisp": that's the name of an *implementation* of
Common Lisp.  If you can't be bothered to type "Common Lisp" out, "CL"
is a better abbreviation.

> I guess we need some boilerplate that allows starting lisp-programs
> from commandline with instructions which functions to call and
> parsing the results. 

Unfortunately, the CL world being what it is, this depends on which
implementation you have installed... we could demand you set an env
var appropriately.

> the unittests could then do the same what they do for pyrex:
> checking that the function at least computes correctly.
>
> btw, I can imagine a cross-language sprint aimed at producing multiple
> backends (C, Pyrex, CLISP, whatever) or multiple frontends (prolog...). 
> That would certainly help to get the wider language research/developer
> community get interested. 

Yep!  Count me in for PPC assembler :-)

> A dumb side-question: can clisp-source be annotated with types
> or is it just another VHLL :-) ? 

Yeah, CL has type declarations.  Whether they make any difference is
(spot a pattern?) implementation dependent, but they can make a huge
difference in, e.g., CMUCL.

> P.S.: if Seo wants to maintain the lisp area for the time beeing i am
>       for giving him commit privs. 

Me too!

Cheers,
mwh

-- 
  That's why the smartest companies use Common Lisp, but lie about it
  so all their competitors think Lisp is slow and C++ is fast.  (This
  rumor has, however, gotten a little out of hand. :)
                                        -- Erik Naggum, comp.lang.lisp