New language: Parrot Common Lisp
Cory Spencer
I'd like to announce the creation of the Parrot Common Lisp project, which
aims to implement a significant subset of the Common Lisp language. At
present it's nowhere near achieving that goal, but it's progressing slowly
as I figure out the intricacies of writing a Lisp implementation.
A brief overview of current features:
* It currently has ~100 functions defined - some written in IMC, some
in Lisp. Most of them aren't all *that* interesting, but once the
basic flow-control special forms and macros are completed, the tools
should be in place to do more interesting things.
* All the basic reader macros (except backquote and ,) are more or less
in place. Some are written in IMC, some in Lisp.
* Support for global, dynamic and lexical scoping more or less works.
* Support for packages more or less works.
* Other exciting features that I'm unable to recall.
A few caveats:
* It's not a compiler yet, although I've got plans for that down the
road.
* Its got bugs and almost certainly won't do what you want it to do
(but will, eventually).
* There are some outstanding issues with the Dead Object
Detection/Garbage collection systems that I've yet to track down. If
you plan on running PCL on the current (as of April 2005) Parrot
source base you'll very likely have to run it with DOD/GC disabled.
ie) ~$ parrot -G lisp.pbc
Depending on the system (I develop on both x86/Linux and g4/OS X),
you'll get a Bus Error, Segmentation Fault or some other random error
if you don't disable the GC.
(If anyone is able to track down aforementioned DOD/GC problems,
you'll earn my eternal gratitude.)
For examples of what it can currently do, look in the lisp/ subdirectory
in the files loaded at run time (bootstrap.l system.l and primitives.l).
Anyone who would like to have a peek at what I've got so far is invited to
download the 0.1.0 release from here:
http://www.sprocket.org/pcl/pcl-0.1.0.tar.gz
Bug reports, patches and comments are most certainly welcome. :)
Enjoy!
-c
Leopold Toetsch
> I'd like to announce the creation of the Parrot Common Lisp project, which
> aims to implement a significant subset of the Common Lisp language.
Wow. I can even do something with it:
$ ../parrot lisp.imc
-> (+ 2 5)
7
-> (list 1 2 3)
(1 . (2 . (3 . NIL)))
Ehem, that's almost all I know about Lisp.
> Depending on the system (I develop on both x86/Linux and g4/OS X),
> you'll get a Bus Error, Segmentation Fault or some other random error
> if you don't disable the GC.
> (If anyone is able to track down aforementioned DOD/GC problems,
> you'll earn my eternal gratitude.)
Can you please provide a code snippet that exhibits the error.
> -c
leo
Chip Salzenberg
> I'd like to announce the creation of the Parrot Common Lisp project
Excellent!
> * It's not a compiler yet, although I've got plans for that down the
> road.
(declare (type PerlString s)) ? :-)
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
Open Source is not an excuse to write fun code
then leave the actual work to others.
Cory Spencer
>> (If anyone is able to track down aforementioned DOD/GC problems,
>> you'll earn my eternal gratitude.)
>
> Can you please provide a code snippet that exhibits the error.
Just running the program gives me errors on both Linux/x86 and OS X.
Running with GC disabled works fine.
On OS X with GC enabled:
forge:~/svn/parrot-lisp/trunk$ parrot lisp.pbc
Can't find method '__set_string_native' for object 'LispSymbol'
On OS X with GC disabled:
forge:~/svn/parrot-lisp/trunk$ parrot -G lisp.pbc
->
On Linux with GC enabled:
anvil:~/svn/parrot-lisp/trunk$ parrot lisp.pbc
Can't find method '__set_string_native' for object 'LispSymbol'
On Linux with GC disabled:
anvil:~/svn/parrot-lisp/trunk$ parrot lisp.pbc
->
This is on the Parrot checked out of Subversion this morning (revision
7846). Which OS/build number were you using?
-c
Leopold Toetsch
> * There are some outstanding issues with the Dead Object
> Detection/Garbage collection systems that I've yet to track down.
I've fixed a bug that happened in combination with Hash iterators.
Exactly the symptoms that I saw, when running:
(print (+ 2 3))
i.e. vanishing strings from global namespace hashes.
leo
Matt Diephouse
> For examples of what it can currently do, look in the lisp/ subdirectory
> in the files loaded at run time (bootstrap.l system.l and primitives.l).
>
> Anyone who would like to have a peek at what I've got so far is invited to
> download the 0.1.0 release from here:
>
> http://www.sprocket.org/pcl/pcl-0.1.0.tar.gz
>
> Bug reports, patches and comments are most certainly welcome. :)
Excellent. Lisp is a lot of fun, although I'm admittedly very rusty.
And generally mixed up about the differences between Lisp and Scheme
(especially the keywords).
One question:
-> (defun (square x) (* x x))
** DEFUN: (((SQUARE . (X . NIL)) . ((* . (X . (X . NIL))) . NIL)) . (1 . NIL))
T
-> (square 2)
*** ERROR: SQUARE is not a function name
Is that because (a) that's not implemented yet or (b) I'm doing
something wrong? I haven't found the time to delve into the source
yet.
Also, while playing I around I found this happening:
-> (* 2 3)
9
-> (* 4 3)
9
Looks like a bug. Maybe I'll find time to brush off my Lisp and start
writing some tests in the process. :-)
--
matt diephouse
http://matt.diephouse.com
Leopold Toetsch
Uwe Voelker
Let's port emacs to it :-)
Bye,
Uwe
Lars Balker Rasmussen
> >I'd like to announce the creation of the Parrot Common Lisp project,
>
> Let's port emacs to it :-)
Erik Naggum, is that you?
--
Lars Balker Rasmussen Consult::Perl
Leopold Toetsch
> http://www.sprocket.org/pcl/pcl-0.1.0.tar.gz
Below is a patch against 0.1.0
- handle a command line file argument:
$ cat t.lisp
(print (+ 2 3))
$ ../parrot lisp.imc t.lisp
5
- use a FixedPMCArray for cons
- much faster _LIST_LENGTH (not that I start optimizing it, but the
trace with the original version was *really* big)
- trailing ws removed by a vim macro
> -c
leo
Cory Spencer
> -> (defun (square x) (* x x))
> *** ERROR: SQUARE is not a function name
>
> Is that because (a) that's not implemented yet or (b) I'm doing
> something wrong? I haven't found the time to delve into the source
> yet.
Oops, that wasn't supposed to have made it in there - I haven't finished
up macros yet, and as (defun ...) is a macro construct, it doesn't work
properly (at the moment it's just a useless stub).
To define new functions, you can use the behind-the-scenes backdoor method
that I'm currently using:
(sys:set-symbol-function 'square #'(lambda (x) (* x x)))
> Also, while playing I around I found this happening:
>
> -> (* 2 3)
> 9
> -> (* 4 3)
> 9
That is probably related to an issue I'd reported last night and for which
Leo (I think) has committed a fix. I haven't had a chance to check out
the new revision, but I'm fairly certain it's the case.
> Looks like a bug. Maybe I'll find time to brush off my Lisp and start
> writing some tests in the process. :-)
Absolutely. I've been meaning to start up a test suite and anything you
can do to further that end would be GREATLY appreciated. :)
-c
Bob Rogers
Date: Fri, 22 Apr 2005 10:45:17 -0600 (MDT)
> -> (defun (square x) (* x x))
> [...]
> *** ERROR: SQUARE is not a function name
>
> Is that because (a) that's not implemented yet or (b) I'm doing
> something wrong? I haven't found the time to delve into the source
> yet.
Oops, that wasn't supposed to have made it in there - I haven't finished
up macros yet, and as (defun ...) is a macro construct, it doesn't work
properly (at the moment it's just a useless stub).
This is Scheme syntax; for Common Lisp, you want the following:
(defun square (x) (* x x))
Which, because DEFUN is a stub, doesn't work either . . .
-- Bob Rogers
http://rgrjr.dyndns.org/
Leopold Toetsch
> Okay, I've got things all moved over into the languages subdirectory and
> playing nicely with the Configure.pl/make process. Can I commit these
> to Subversion myself at some point (my CPAN id is cspencer), or is
> commit access fairly restricted? :)
You'll need AFAIK a perl.org account. Then drop a note to Robert Spier
who sets the commit priv bits.
languages/* maintainers should be able to manage their stuff so I'm
fully for providing ci privs to you. BTW don't forget to update MANIFEST.
> -c
leo
PS CC'ed to list
Cory Spencer
On Fri, 22 Apr 2005, Matt Diephouse wrote:
> -> (defun (square x) (* x x))
> -> (square 2)
> *** ERROR: SQUARE is not a function name
A quick follow-up - I've just checked in code implementing some primitive
macros, so if you wanted to give (defun ...) a go again, you should find
that it works now. (Note that Lisp is now included in the languages
subdirectory of the latest Parrot SVN tree.)
> Also, while playing I around I found this happening:
>
> -> (* 2 3)
> 9
> -> (* 4 3)
> 9
I've noticed this is also happening for floating point numbers:
-> (* 2 3.2)
9.6
-> (+ 1.2 3)
I'm not sure what kind of magic you worked last time with Integers,
Leo, but would you mind working it again? (Or pointing me in the right
direction so that I can fix it myself. :)
-c
Leopold Toetsch
> -> (* 2 3.2)
> 9.6
> -> (+ 1.2 3)
> I'm not sure what kind of magic you worked last time with Integers,
> Leo, but would you mind working it again? (Or pointing me in the right
> direction so that I can fix it myself. :)
Short answer: will be fixed soon.
The longer story is:
The problem is the different memory layout of Integer/LispInteger or
Float/LispFloat. As a LispInteger isa(Integer) it inherits all the MMD
functions from Integer. These functions used to do:
a = PMC_intval(left); # or PMC_num_val for Float
b = PMC_intval(right);
c = a <op> b;
But that doesn't work, if it's a LispInteger / LispFloat. The correct
way to go is:
a = VTABLE_get_integer(INTERP, left);
...
This calls get_integer() implemented in the deleg_pmc.pmc class, which
is implicitely a parent of all objects that subclass native PMCs.
Some aren't converted (mainly Float). Integer functions mostly call
VTABLE_get_integer(). This is the reason that currently you get wrong
results for Float operations.
Unfortunately calling VTABLE_get_integer twice slows down e.g. "add" by
almost 30% which isn't really nice.
*But* I'm working currently on some code that should eventually allow
the orginal fast access. The plan(tm) is to dynamically install a
mmd_wrapper function for such subclassed native types. This wrapper
extracts the first attribute (the Integer or Float, ...), calls the MMD
function and stores the return result in the object (or creates one) if
there is a result.
This works already for all the opcodes. Still todo are some more nasty
cases with explicit method calls or bound methods that ought to call the
wrapper too.
> -c
leo