Hi,
I'm the lead developer of Jatha (http://jatha.sourceforge.net/), an
open source LISP implementation in Java. It has been under development
off and on for about 15 years now (it started out in C++) and is
finally achieving a critical mass of functionality.
We'd like to retrofit multiple return values into the implementation
and I'd be interested in hearing advice on how to do so. Jatha's
execution engine is based on the implementation in Kogge's book, "The
Architecture of Symbolic Machines". Results of function calls are
placed on a stack where they are picked up by the next function call.
However, with multiple values some of those results can be single
values and others can be multiple values.
Do you have any advice on how to handle multiple values? I'm looking
for a minimal solution since we have limited development resources.
Thanks,
Mike Hewett
······@cs.stanford.edu writes:
> Hi,
>
> I'm the lead developer of Jatha (http://jatha.sourceforge.net/), an
> open source LISP implementation in Java. It has been under development
> off and on for about 15 years now (it started out in C++) and is
> finally achieving a critical mass of functionality.
>
> We'd like to retrofit multiple return values into the implementation
> and I'd be interested in hearing advice on how to do so. Jatha's
> execution engine is based on the implementation in Kogge's book, "The
> Architecture of Symbolic Machines". Results of function calls are
> placed on a stack where they are picked up by the next function call.
> However, with multiple values some of those results can be single
> values and others can be multiple values.
>
> Do you have any advice on how to handle multiple values? I'm looking
> for a minimal solution since we have limited development resources.
The easiest reasonable strategy would probably be to use three slots
on the stack, one for the primary return value, one for the number of
values returned, and one for a list of values after the primary one.
Code that only looks for the primary return value could continue to
look at the one slot on the stack, and only needs to do more work if
it wants to handle multiple values.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
From: Russell McManus
Subject: Re: Implementing multiple values in Jatha
Date:
Message-ID: <877jho5v9v.fsf@cl-user.org>
If you are concerned about keeping the code path short for the usual
case of 1 returned value, then another approach is to (always) put the
first returned value onto the stack, and use a pair of (logical)
registers to record what else was returned.
Register MV# would hold the number of values returned. Register MV
would have a list of 2..N returned values. In this way only code that
cares about multiple values would have to examine MV# and MV, and less
stack juggling would be required in the common case.
Then (values 4 5 6) becomes something like:
DUP ; MV#: MV: st: (4 5 6) (4 5 6)
LENGTH ; MV#: MV: st: (4 5 6) 3
LOAD MV# ; MV#: 3 MV: st: (4 5 6)
DUP ; MV#: 3 MV: st: (4 5 6) (4 5 6)
CDR ; MV#: 3 MV: st: (4 5 6) (5 6)
LOAD MV ; MV#: 3 MV: (5 6) st: (4 5 6)
CAR ; MV#: 3 MV: (5 6) st: 4
in some mythical vm.
-russ
> I'm the lead developer of Jatha (http://jatha.sourceforge.net/), an
> open source LISP implementation in Java. It has been under development
> off and on for about 15 years now (it started out in C++) and is
> finally achieving a critical mass of functionality.
This seems like a very interesting project.
Something I am curious about I cant find any info in documentation. Is
there no FFI to access Java objects and call java methods directly from lisp
(without writing a lot of glue code in java)?
I would have thought that would be a very useful functionality to have if
one wants to use jatha as a scripting language for a large java application.
cheers
pj
> We'd like to retrofit multiple return values into the implementation
> ...
> Results of function calls are
> placed on a stack where they are picked up by the next function call.
Why do you put the results of function calls on the stack at all?
Remember, a stack is made for storing things over a longer period of time.
Whereas results of function calls are used immediately by the caller.
There is no real code that is run between the moment a function produces
its multiple values and the moment where the caller analyzes the number
of values that was produced.
In summary, I'm suggesting to put the multiple values into an array
(global, or in multi-threaded implementations, per-thread). Only
constructs like MULTIPLE-VALUE-CALL need to move the whole set of
multiple values to the stack; most callers will only take the first
value.
Bruno