Re: [Scheme-reports] How about relaxing a dot notation restriction?

[taylanbayirli@x (Taylan Ulrich B.)]

Sascha Ziemann <ceving@x> writes:
> Hello,
>
> the dot notation is allowed in function definitions:
>
> (define (plus first . rest)
>   (if (null? rest)
>       first
>       (+ first (apply plus rest))))
>
> (plus 1 2 3) => 6
>
> And in literals:
>
> (plus 1 . (2 3)) => 6
>
> But not in function applications:
>
> (define two-three '(2 3))
> (plus 1 . two-three) => ERROR
>
> How about relaxing this restriction?
>
> Regards
> Sascha

I happen to have time to waste, so here's a long explanation; if you
actually knew most of it, that's OK:


This is a mis-understanding of how s-expressions work to represent code
in the Lisp family of languages.

A piece of code (or anything else) written in s-expressions is just a
serialized binary tree, and it isn't treated as code until it is passed
into an evaluator after being read into memory (by the "reader").

(plus 1 . (2 3)) represents the same data structure as (plus 1 2 3),
since list-notation is just a syntactic short-cut for linked lists in
the s-expression data format.  Therefore, when an s-expression reader
reads these expressions (not even knowing that they are Lisp code), it
creates the same data structure in memory, so a Lisp evaluator cannot
distinguish between them.

The expression (plus 1 . two-three) on the other hand results in a data
structure in memory that is an "improper list," a linked-list that is
not terminated by the empty-list atom (), but instead the symbol
`two-three' in this case.  This data structure is not valid Lisp code
for an evaluator.  The evaluator could treat said structure as a
special-case for when the terminating symbol denotes an identifier bound
to a list, but this is not a "clean" logic, because consider the
following:

(plus 1 . (list 2 3))

Going by the intuitive thought that a variable-reference evaluating to a
list should be equivalent to a function-call evaluating to a list, one
would expect this to work.  It will not work, because the above
s-expression represents the same data structure as the s-expression
(plus 1 list 2 3).  The evaluator cannot know that it was originally
written in the form (plus 1 . (list 2 3)), because the reader discards
that information.


By the way I'm not sure whether the standards even explicitly specify
that code is written in s-expressions.  A BNF for the whole grammar
(s-expression format mixed with built-in syntax forms) is provided, so I
wouldn't be surprised if an implementation treating (plus 1 . (2 3)) as
invalid syntax is regarded as a conforming implementation.  Please
correct me if I'm wrong; I think it would be neat if the standards made
the separation between the s-expression data format, and the semantics
of a binary tree representing Lisp code clear, possibly spending less
time on specifying grammar.

Regards,
Taylan

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports