Niels Möller wrote: > When specifying the use of rest arguments for procedures > (r7rs, sec 4.1.4), it seems to imply that the passed > argument list is mutable?
Yes, because it states "the sequence of actual arguments is converted into a newly allocated list, and the list is stored in a fresh location" and "The value stored in the binding of the last variable will be a newly allocated list" (PDF version, page 13, right column, description of formals); it is new at every function call, so we can do everything with it. > This is convenient in some ways, e.g., I think the > following definition of the list procedure should be > correct > (define (list . args) args) Yes. Vicare defines it as: (define list (lambda x x)) > However, for a natural implementation which evaluates > arguments and conses the results up to a list, this seems > to require an extra copy of the argument list, after all > values are evaluated and before the list is bound to the > rest parameter. Yes, but it depends on what is "natural" for you. In Vicare, when calling a Scheme function, all the arguments are pushed on the Scheme stack segment (similar to calling a C function) and then the function is called; the callee takes the leftover arguments and puts them into a newly allocated list. In this implementation there is no duplication of list's spine (with heap memory allocation), just use of stack slots. > To see why, assume that evaluation of one of the arguments > captures its continuation and returns several times. this > isn't the first argument evaluated, without the extra > copying, one gets several calls to the procedure with the > rest argument sharing structure, and if the shared part is > mutated, things go bad. Yes it would go that way. But the standard mandates that a new list must be built at every call and stored into a fresh location at every call; no shared structure is allowed. HTH -- "Now feel the funk blast!" Rage Against the Machine - "Calm like a bomb"
