On 08/17/2015 01:34 AM, Taylan Ulrich Bayırlı/Kammer wrote:
> Per Bothner <xxxxxx@bothner.com> writes:
>
>> I will not implement this for default-mode Kawa (i.e. not requiring
>> an import) because Kawa already has a cleaner and more concise notation:
>> Treat a vector/list/string as a pseudo-function:
>>
>> #|kawa:1|# (define vec1 #(a b c d))
>> #|kawa:2|# (vec1 2)
>> c
>> #|kawa:3|# (define vec2 (vector-copy vec1))
>> #|kawa:4|# (set! (vec2 2) 'C)
>> #|kawa:5|# vec2
>> #(a b C d)
>> [... snip ...]
>
> That's a pretty nice idea, but having
>
>      (set! (x y ...) z)
>
> equal
>
>      ((setter x) y ... z)
>
> has been around since SRFI-17, and is apparently even baked deep into
> some Scheme implementations (at least, Guile).

and Kawa.

> So, it's an unfortunate difference but I guess we'll have to live with
> it.

I don't see how it's a "difference".
(set! (vec2 2) 'C) == ((setter vec2) 2 'C) == (vector-set! vec2 2 'C)

> Well, it might still be possible to have a smart implementation of
> `setter' which does the right thing,

In Kawa, it does.

> but that would be pretty awkward,

I disagree.  It seems pretty natural to view an array/vector as a kind of function,
and it's arguably good to use the same syntax for function application
and array/vector indexing, as it abstracts over the implementation.

The point of the ref or ~ operator (besides terseness) is to abstract
away from representation choices, thus making it easier to change implementation
details.  Using function notation goes one step further.

> and currently I don't see the "applicable data structures" syntax
> catching on in Scheme.

Perhaps, but one might say the same for using ~.  Also consider
SRFI-25/SRFI-122-style multi-dimensional arrays.  People
working with matrixes would probably rather write:
   (* (A i j) (B i j))
than:
   (* (array-ref A i j) (array-ref B i j))
or even:
   (* (~ A i j) (~ B i j))
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/