Mark H Weaver <m...@netris.org> writes: > David Kastrup <d...@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