Aha, I finally realized that with respect to my specific complaint of obj expanding into uses of atomic, there's no need to protect the setting of the values in the table with atomic since the newly created table will not be visible to other threads at least until obj returns. The fix is easy:
A third perspective is that the bug isn't in the use of =, but that obj evaluates its value arguments too late.
In a function call
(f (g) (h))
g and h are evaluated before f is called. A user might expect obj to work the same way for its value arguments (though, as a macro, of course it doesn't have to):
(obj a (g) b (h))
This expectation can be fulfilled by evaluating the value arguments before storing them in the table. The existing macro could be modified to do that, though perhaps this implementation would be simpler:
If anyone wants to take on being a distributor for a Windows port (or for different variants of Linux, for that matter), I do have a patch for date here: http://catdancer.github.com/date.html
Another option is the Anarki stable branch (http://github.com/nex3/arc/commits/stable/), which has most of fixes necessary to make most of Arc work portably on Windows and other OSes. (And, being a bug-fix branch, the amount of other random material is limited.)
I agree with the option, but I also think these posts will fall off the deep end in about 2 months. By then new members may only discover the option after they've discovered the problem. So we're not really saving new members wasted efforts unless the install page guides people.
pg: Even if you'd rather not think about supporting Windows portability yourself, providing a link to the Anarki stable branch would help new Windows users. Finding this stuff on the forum after it's fallen off the top couple of pages is not very easy.
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...
