Re: Dotted pair call argument

[David Kastrup <dak@gnu.org>]

Mark H Weaver <mhw@netris.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>> 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.
>>
>> guile> (display . (close (current-output-port)))
>> #<primitive-procedure close>guile> 
>>
>> Now try
>>
>> (define x (close (current-output-port)))
>> (display . x)
>
> Admittedly I could have been more clear, but I certainly didn't mean to
> imply that anything that _looks_ like a valid expression can be
> replaced.  That would be absurd.

Exactly.

> What I meant is that any _subexpression_ can be replaced with any other
> valid expression, without changing the meaning of the program in any
> other way.

So the solution would be to not call dotted pair endings of argument
lists a "subexpression", and everybody will be happy.

> Whether something is a subexpression depends on its _position_ within
> the larger expression.

Yes.  That's the point.  The dotted list end is a specific position.
Not "subexpression" position.  If a list is there, it is evaluated
element by element.  If a non-list is there, we get an error.  Instead,
I prefer evaluating it and using the evaluated result, whatever it may
be, as the argument list tail.  Personally, I would not even demand
actual argument lists to be proper lists as long as the declared
argument list is a dotted list as well: you can still match arguments
then.

> The only advantage I see to this proposed syntax is that in some
> restricted cases it is more aesthetically pleasing.

apply can't handle improper lists either.

> I suspect that most experienced Schemers have at some point wondered
> why dotted-tail notation is not allowed in procedure calls.  I
> certainly have, but upon further consideration I became convinced that
> the pitfalls of adopting such an ambiguous and potentially confusing
> syntax far outweigh the advantages.

Nothing that is currently valid would change its meaning.

-- 
David Kastrup