chicken-users
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]