[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-users] Re: Scheme, Chicken, and Parrot
From: |
Leopold Toetsch |
Subject: |
[Chicken-users] Re: Scheme, Chicken, and Parrot |
Date: |
Fri, 08 Jul 2005 14:52:41 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 |
John Lenz wrote:
Introduction
--------------------------------------------
I have a very alpha patch to add a parrot backend to the CHICKEN compiler.
CHICKEN is a scheme to C compiler, and parrot is a continuation (rather
than stack) based virtual machine.
Wow, another poultry for parrot.
http://www.cs.wisc.edu/~lenz/parrot
Parrot Issues (scroll down a ways for Chicken issues)
jump P1
What's this? New opcode or typo?
As such, I propose a fasttailcall opcode. This opcode acts exactly like
the tailcall opcode, except it does not pass any arguments and leaves the
registers alone.
This should aready work in branches/leo-ctx5. If there is no get_params
opcode, no arguments are passed, only the current context is updated to
hold e.g. the new current subroutine. Registers should be unchanged.
3) Closures
Thus, I propose a ClosureArray PMC type that ignores the pad_stack. It
will inherit from both Sub and FixedPMCArray. It stores the array in the
data section just like a FixedPMCArray, but you can call invoke on it.
pmclass ChickenClosure dynpmc need_ext extends Sub extends FixedPMCArray
group chicken_group { ...}
is probably all that is needed to achieve this functionality.
4) Standard PMCs. Almost all scheme types are already covered by PMCs,
except for a few missing ones. The first is the pair type. We need a
standard pair type rather than the DictionaryEntry type that the current
pair is (See my other message on the PMCs: Should We Use Them).
Again, subclass Pair and implement the keyed access functions.
John
leo