First of all, updating to the recent plt version will be good, since there have been a lot of optimizations since then, including a lot of work to the compiler and the jitter.
Arc needs to do some list marshaling in any case to deal with nil -- and as such it reimplements nearly all of the list operations, deferring to mzscheme functions only for a few things. Because of this, using `mcons' shouldn't be too problematic (not even for speed, since arc functions in general are not careful about cyclic lists, a plain implementation will be fast enough -- for example, mzscheme's `map' is now implemented in scheme). I have done some tests in the past to measure
Probably the only major problem is how to deal with a rest argument. One option is to make it illegal to mutate rest arguments. Another is to hook on the fact that rest arguments are not modified often -- so instead of copying them to a mutable list on every call, they can be converted only when needed, by the functions that change the contents of these lists. Given the above (need to implement list functionality anyway), this wouldn't be difficult -- basically some wrapper around a mzscheme list that can do the necessary work. As a side benefit it can be used to deal with nil too, which will make that run faster as well.
(BTW, this will be much faster than using r6rs or r5rs modes.)
One option is to make it illegal to mutate rest arguments.
Currently, in arc.arc, list is defined as
(def list args args)
so this would need to change if rest arguments couldn't be mutated. (Which would be OK with me, I can't think of a single case where I ever mutated a rest argument).
Another is to hook on the fact that rest arguments are not modified often -- ... they can be converted only when needed
How could this possibly work??
((fn args
(= (cadr args) 'X)
args)
'a 'b 'c)
sure, it would be easy for set-cdr! to see that the second pair is immutable and decide to create a new mutable cons. But args is still going to be pointing to the original list of immutable pairs!
As a side benefit it can be used to deal with nil too, which will make that run faster as well.
Can you explain? (I need smaller steps to be able to follow you :-)
(BTW, this will be much faster than using r6rs or r5rs modes.)
Yes, I was getting that impression browsing through the r6rs and r5rs code.
The way I'm leaning right now is to first rewrite the Arc compiler to generate PLT 4 code in the simplest possible way, for example to always convert rest arguments to mutable lists. Then, things like making rest arguments immutable could be done as an optimization if desired.
For the "on-demand" conversion some PLT magic will be needed -- I'm basically talking about doing something at the level of the PLT function that is the result of compiling an arc function. In any case, explaining more through this medium will be hard for me...
Nope. All you can do is use mcons ('mutable cons'), mcar, mcdr, etc. But apparently there are only a few functions that work with these things. It's like using lists in a language that doesn't support lists well. Useless.
Hmmmmmm... I had thought that r6rs compatibility mode wasn't very useful, if it just made car a synonym for mcar etc. But it does more, for example unlike in regular plt-4 where in (lambda args ...) args is an immutable list, in r6rs mode:
#!r6rs
(import (rnrs) (rnrs mutable-pairs (6)))
(define x ((lambda a a) 'a 'b 'c))
(set-car! (cdr x) 'd)
(write x)
(newline)
$ plt-4.1.5/bin/mzscheme -t a.scm
(a d c)
This looks like it could solve a lot of problems with a port to plt-4, since otherwise we'd need to be rewriting the Arc compiler to change the expansion of (fn args ...) etc.
Played around with it a bit more, r6rs appears problematic as apparently ++ is not a legal symbol in r6rs (!)
I took a look at PLT's implementation of lambda for r6rs/r5rs (it's in collects/r5rs/main.ss), and they just simply convert to a mutable list if the lambda has a rest parameter:
(define-syntax (r5rs:lambda stx)
;; Convert rest-arg list to mlist, and use r5rs:body:
(syntax-case stx ()
[(_ (id ...) . body)
(syntax/loc stx (#%plain-lambda (id ...) (r5rs:body . body)))]
[(_ (id ... . rest) . body)
(syntax/loc stx
(#%plain-lambda (id ... . rest)
(let ([rest (list->mlist rest)])
(r5rs:body . body))))]))
(the list->mlist is the part I'm looking at)
So having for example (fn args ...) compile to an (arc-lambda args ...) which does the same thing might be simpler than trying to get Arc to compile and run in the whole complicated r6rs environment.
I participated a bit in the discussion while r6rs was being created, but it quickly became apparent to me that the goals that the editors were striving for weren't things that I personally cared about.
So, anyway, due to the "compromise", can we get mutable pairs if we run MzScheme in r6rs compatibility mode?
a.scm:
#!r6rs
(import (rnrs) (rnrs mutable-pairs (6)))
(define x (cons 'a 'b))
(set-car! x 'c)
(write x)
(newline)
$ ./mzscheme a.scm
(c . b)
So yes, though it turns out that in r6rs compatibility mode cons is really just mcons, so we don't actually gain anything.
Indeed, our experience is that making the result of `cons' immutable
does not create many porting problems. Nevertheless, if your code does
use `set-car!' or `set-cdr!', and if converting to a more functional
style is difficult, then consider using `mcons' and the `scheme/mpair'
library.
