Sascha Ziemann <[email protected]> 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
