[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Sascha Ziemann <ceving@x>*Subject*: Re: [Scheme-reports] How about relaxing a dot notation restriction?*From*: taylanbayirli@x (Taylan Ulrich B.)*Date*: Fri, 22 Mar 2013 21:26:26 +0100*Cc*: scheme-reports@x*In-reply-to*: <CAGUt3y7k8HqyzxHFiCVKUbNAp3V0Wgd9KX8ZmEsMs54XRXEh1A@mail.gmail.com> (Sascha Ziemann's message of "Fri, 22 Mar 2013 14:06:26 +0100")*References*: <CAGUt3y7k8HqyzxHFiCVKUbNAp3V0Wgd9KX8ZmEsMs54XRXEh1A@mail.gmail.com>

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

**References**:**[Scheme-reports] How about relaxing a dot notation restriction?***From:*Sascha Ziemann <ceving@x>

- Prev by Date:
**Re: [Scheme-reports] R7RS - questions concerning variable definitions and binding constructs** - Next by Date:
**[Scheme-reports] IO operations and random access** - Previous by thread:
**Re: [Scheme-reports] How about relaxing a dot notation restriction?** - Next by thread:
**[Scheme-reports] R7RS - questions concerning variable definitions and binding constructs** - Index(es):