Re: Dotted pair call argument

[Mark H Weaver <mhw@netris.org>]

David Kastrup <dak@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>> I guess my "real" problem is that I'd like to do call wrapping by writing
>>>
>>> (lambda ( . x) (fun . x))
>>>
>>> instead of having to write
>>>
>>> (lambda ( . x) (apply fun x))
>>>
>>> I assume eval is not supposed to try dealing with dotted lists?
>>
>> The problem is that (f . (g x y)) is equivalent to (f g x y).
>> Therefore, while Scheme could in theory support procedure calls with a
>> dotted tail that happened to be an atom, it would do something rather
>> different and confusing if the dotted tail was itself a procedure/macro
>> call.
>
> A list in dotted tail position is evaluated via (map ... eval) rather
> than (eval ...).  I don't see much of a problem with that.

No, it's worse than that.  I think you failed to understand my point, so
let me try again.  You propose that (f . x) should be equivalent to
(apply f x).  Therefore, (f . (g x y)) should also be equivalent to
(apply f (g x y)).

However, (f . (g x y)) is read as (f g x y), so it's impossible for
'eval' to distinguish these two cases.  Unfortunately, (f g x y) has a
very different meaning than (apply f (g x y)).  The first means to apply
'f' to three arguments.  The second means to apply 'g' to two arguments,
and then apply 'f' to the list of arguments resulting from (g x y).

To make this more concrete, suppose 'f' is 'vector and 'g' is 'list':

  (vector . (list 1 2))

If we were to adopt your proposal, users would naturally expect this to
evaluate to #(1 2).  However, the evaluator sees (vector list 1 2) and
thus produces a vector of three elements: #(#<procedure list _> 1 2).

In summary, your proposed syntax could only be detected if the dotted
tail happened to be an atom.

Scheme has a very useful property which your proposed syntax would
destroy: any valid expression can be substituted for any other valid
expression, and the result has the same meaning except for the
substitution.  This property is desirable for many reasons.  Users
should be able to freely substitute expressions (possibly using a global
find/replace operation, or via macros) without changing the meaning of
the resulting expressions in surprising ways.

Does this make sense?

      Mark