From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!not-for-mail From: Erik Naggum Newsgroups: comp.lang.lisp Subject: Re: Small read macro issue Date: 10 Oct 2002 21:02:48 +0000 Organization: Naggum Software, Oslo, Norway Lines: 51 Message-ID: <3243272568030579@naggum.no> References: <3242987175062451@naggum.no> <3242995842037739@naggum.no> <3243028580124863@naggum.no> <3243031919607252@naggum.no> <3243105699171281@naggum.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: maud.ifi.uio.no 1034283769 17446 129.240.65.5 (10 Oct 2002 21:02:49 GMT) X-Complaints-To: abuse@ifi.uio.no NNTP-Posting-Date: 10 Oct 2002 21:02:49 GMT Mail-Copies-To: never User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.lisp:43656 * Vassil Nikolov | But to make the above argument complete, it must be noted that the reader | cannot use MULTIPLE-VALUE-BIND to call the macro reader function since if | it did, it wouldn't know when zero values were returned. Correct, and a good point. | (1) By using MULTIPLE-VALUE-LIST to receive the values returned by the | reader macro function. This is the more straightforward | implementation, and it leads naturally to a logic where the list thus | obtained is tested first for being empty, and then, if it is not, its | first element is extracted, while the rest of the elements, if any, | are silently ignored. In this model, which I think is the most rational choice, it takes extra effort to check for the redundant values. | (2) By using MULTIPLE-VALUE-CALL, with a function whose lambda list | is something like | | (&optional (read-value nil read-value-p) &rest ignore) | | where the implementor must be `smart enough' since the &REST | parameter must be explicitly added. If it isn't, then it will be an | error for the reader macro function to return more than one value. But this model, while possible, would mean that the function so called would be a closure that would act on the hitherto collected elements of a list or other structure. Remember,we are using this to collect datums from a stream to return to our caller. It seems strange to do this with a downward-passing mechanism that would collect upon return. However, the more I think about this, the more I think that maybe the support for multiple-values in Common Lisp is slightly lacking. More often than not, multiple values may be returned in registers, but there is no way to access both the values and the number of returned values even though most (if not all) implementations return that number with the returned values. When multiple values are returned, a function should be able to dispatch on the number of return values. The only way to do this is with `multiple-value-callĀ“ and hope that the multiple-value-return block and the argument block to a function are not too costly to convert between. It would be interesting to compare the various implementations on this point. -- Erik Naggum, Oslo, Norway Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.