You can get the latest code at http://ycombinator.com/arc/arc3.1.tar
HN has been running this version for about a week. It seems to be a bit faster, maybe 10-20%.
There are a few other small changes. For example, intrasymbol + has been replaced by &. And these two bugs
http://arclanguage.org/item?id=10188
http://arclanguage.org/item?id=10160
have been fixed.
It seems that plt4's immutable conses have been worked around via low-level pointer hacking. I can only hope this doesn't introduce subtle bugs, but given that Eli Barzilay seems to work on plt scheme, hopefully this is not the case.
I've pushed the changes to anarki's "official" branch.
-----
This resolves part of the issue from before (http://bitbucket.org/fallintothis/arc-vim/issue/1/highlighti...). For the full changeset, see http://bitbucket.org/fallintothis/arc-vim/changesets/.
-----
Tested on Debian (Squeeze) with MzScheme 4.1.4 (the one in the official repositories), no problem :-)
Note: don't use 'mzscheme -m -f as.scm' but just 'mzscheme -f as.scm' instead (see "how-to-run-news").
For information, the 'coerce / 2.0 integer is fixed by defining an Arc integer (exint) as (and (integer? x) (exact? x)). The bug with dotted lists in quasiquote is fixed using a new small function 'imap, that is like 'map but "don't demand '()-terminated list".
-----
;; set a pointer to the cons cell, then dereference it as a pointer,
;; and bang the new value in the given offset
Hmm... so the fix was to "cast" the immutable cons cell to a mutable cons cell? Glad it works, but I was kind of hoping to learn that the immutable cons cell thing was workable for Arc. I guess I should read up on the MzScheme decision to make it immutable and see what pros/cons are associated with it.-----
http://blog.plt-scheme.org/2007/11/getting-rid-of-set-car-an...
Further discussions can be found in the mail archive.
-----
-----
Thank you all very much for your work on this.
-----
mzscheme -f as.scm
To get this to run (without the -m) otherwise I got the message "main: not defined or required into the top-level environment"
-----
-----
If you're asking why immutable conses could speed up a programming language in general, well, a compiler can make more powerful optimizations if it's allowed to assume that lists won't mutate mid-flight. Obviously a specific program that used mutability of conses would need to be rewritten, and might end up faster or slower; but code that doesn't take advantage of the mutability of conses (of which there is a lot, Scheme having the functional heritage it does) can be speeded up.
Of course, given that Arc's mutable conses are accomplished by using pointer hacking to mutate plt4's supposedly immutable conses, one would hope the plt4 compiler doesn't take real advantage of the immutability of their conses, otherwise it might make assumptions that Arc will break, leading to difficult-to-detect bugs.
-----
; Eli's code to modify mzscheme-4's immutable pairs.
;; to avoid a malloc on every call, reuse a single pointer, but make
;; it thread-local to avoid races
(define ptr (make-thread-cell #f))
(define (get-ptr)
(or (thread-cell-ref ptr)
(let ([p (malloc _scheme 1)]) (thread-cell-set! ptr p) p)))
;; set a pointer to the cons cell, then dereference it as a pointer,
;; and bang the new value in the given offset
(define (set-ca/dr! offset who p x)
(if (pair? p)
(let ([p* (get-ptr)])
(ptr-set! p* _scheme p)
(ptr-set! (ptr-ref p* _pointer 0) _scheme offset x))
(raise-type-error who "pair" p)))
(define (n-set-car! p x) (set-ca/dr! 1 'set-car! p x))
(define (n-set-cdr! p x) (set-ca/dr! 2 'set-cdr! p x))
Really. (This is an excerpt from arc3.1's ac.scm.)-----