Brad Lucier <xxxxxx@IRO.UMontreal.CA> writes:
> <David Rush topic="(values ...)">
> Ok, it's a procedure that accesses the current continuation
> then. It is a very odd procedure in since it can only be called in
> tail position. It *still* does not construct a data object, so it
> cannot be the "contents" of an array element.
> </ David Rush>
>
> we can use these procedures and macros to build new data
> abstractions if we want.
>
> So we could have (array-ref a i) and (array-set! a i v)
> be special forms (macros) that expand to
>
> (call-with-values
>     (lambda () i)
>   (lambda indices
>     (array-body-ref a indices)))
>
> and
>
> (call-with-values
>     (lambda () i)
>   (lambda indices
>     (call-with-values
> 	(lambda () v)
>       (lambda vals
> 	(array-body-set! a indices vals)))))

This just moves the problem down one layer. What do you get from it?
At some point you get to storage, which is what I originally
understood your reference to the "contents" of an array-ref to
be. There is still no way to store the 'result' from the VALUES form
here.

If what you're getting at is that you want to specify array-ref and
array-set! as fully abstract operations with reference to a concrete
representation, this might have some more value. My concern with the
array abstraction issue has been that I have a top-level interface
that I can specialize easily (via macrology/modularity/functorization).

Is this what we're arguing about? If it is, I think that the focus
should remain on the top-level interface. Implementations are free to
do what they want.

> So I don't believe these vehement denials that this is possible.

I think we're getting bogged down in what we're saying is
(im)possible. You can't store the 'result' of evaluating a VALUES
form. You certainly can use VALUES to implement a particular
interface.

david rush
--
C makes it easy to shoot yourself in the foot, C++ makes it harder,
but when you do, it blows away your whole leg -- Bjarne Stroustrup