[Openmcl-devel] peek-char, interpretation of first argumenthttp://www.nbcolympics.com/video?ocid=Yahoo

[Erik Pearson]

<pjb at informatimago.com> wrote:

> Erik Pearson <erik at adaptations.com> writes:
>
> > Never one to not jump to my own defense or fail to flog a dead
> > equine, and almost always finding that this is a mistake, I
> > nevertheless venture one last flail. When researching the etymology
> > of the construction "if peek-char is not supplied or nil", I find in
> > the MacLisp manual the precedent for this "variable arity
> > polymorphism based on type" in the definition of "read":
> >
> > (READ [file] [eofval])
> >
> > If only one argument is given, it may be either stream or eofval. If
> > it is a file, an sfa, or NIL, it will be assumed to be stream;
> > otherwise, it will be taken as eofval.
> >
> > If file is not supplied or is NIL, the default input stream as
> > controlled by the variables ^Q, INFILE, and TYI will be used.
> >
> > Interesting, perhaps, to an infinitiesimal sliver of humanity.
>
>
> However, this kind of function signature cannot be specified with CL
> lambda lists, that is, the parsing of the arguments for those functions
> cannot be performed by cl:defun.
>
> You would have to write something like:
>
>
>     (defun maclisp:read (&rest arguments)
>       (let ((file   (maclisp::internal-select-stream maclisp:^q
> maclisp:infile maclisp:tyi))
>             (eofvar nil))
>        (case (length arguments)
>         ((0))
>         ((1)  (typecase (first arguments)
>                  (stream (setf file   (first arguments)))
>                  (t      (setf eofval (first arguments)))))
>         ((2)  (setf file   (first arguments))
>               (setf eofval (second arguments)))
>         (otherwise (error "Too many arguments")))
>       (maclisp::internal-read file eofvar)))
>
>
> Now, one could write an extended defun macro that would take a lambda
> list specification that would include the types and default values of
> the arguments and expand to something similar to the above.  For
> example:
>
>     (extended:defun maclisp:read (&typed-optional
>                                   (file   stream
> (maclisp::internal-select-stream
>                                                   maclisp:^q maclisp:infile
>                                                   maclisp:tyi))
>                                   (eofvar boolean nil))
>       (maclisp::internal-read file eofvar))
>
>
> This wouldn't be too difficult.  However, it would have dire
> consequences to the Common Lisp programming style, because it would
> require much more control on the type of the arguments of functions,
> ie. on the type of all the values in the program.
>
>
> For example, if you write:
>
>     (cl:defun example:read (&optional
>                               (file (maclisp::internal-select-stream
>                                      maclisp:^q maclisp:infile
>                                      maclisp:tyi))
>                               (eofvar nil))
>       (example::internal-read file eofvar))
>
> you can pass to example:read any value, even not a strem, to the file
> parameter.  There's nothing in example:read that really requires file to
> be a stream, since file is only used as a parameter to
> example::internal-read, the typing of file is defered to this function.
> In effect, what we have here is a generic function (in the general
> sense, not that of CL generic-function), not a function restricted to
> stream types.  In practice in CL, it's used to let one pass T or NIL, or
> a string with a fill-pointer,   instead of a stream to such functions as
> FORMAT, with a meaning assigned to those values.
>
>     (let ((out (make-array 100 :adjustable t :fill-pointer 0
>                                :element-type 'character)))
>       (format out "Hello ~A" 'world)
>       out)
>     --> "Hello world"
>
> This wouldn't be possible anymore if FORMAT was defined with
> &typed-optional arguments.
>
> In the worst case, they would define a FORMAT-DESTINATION type to wrap
> the various cases:
>
>     (format (make-instance 'format-specification :string-target out)
>             "Hello ~A" 'world)
>
>     (format (make-instance 'format-specification :stream *query-io*)
>             "Hello ~A" 'world)
>
>     (format (make-instance 'format-specification :string-result t)
>             "Hello ~A" 'world)
>
>     (format (make-instance 'format-specification :symbolic-stream t)
>             "Hello ~A" 'world)
>
> just to be able to write also:
>
>     (format "Hello ~A" 'world)
>
> !
>
> Go down this slope, and you end up with Java!
>
>
Heaven forbid!

Very interesting, thanks for the exposition, it has gone into the ol'
hopper.

I was thinking more from the function-specification point of view. That is,
if a function specification text makes a promise about things like domain
and range, interpretation of arguments, effect on the internal logic from
different argument types or values, side effects, exceptions and so forth,
as a user one must rely on that alone. However, one would hope that such
promises are practical, that the logic is clearly stated, unambiguous, and
easy to follow, all possible use cases exhausted, and so forth. I
understand that sometimes CL library function arguments are defined as the
value acceptable to some other function, but I still expect the library
function to do the "right thing" for the programmer.

In any case, as you point out CL gives us tools to implement something like
this, i.e. &optional, typecase, and argument-supplied-p. They allow us to
create functions which  express polymorphism that is not explicitly
provided by defun. Would you agree? (I'm no expert on argument mechanics.)

Something like peek-char is a little extreme in my experience, in terms of
expressing the its ancestry. For example, my surmise is that earlier Lisps
like Maclisp, without keyword arguments, were forced to use fixed order
optional arguments, employing default values and filler nil values. In the
case of peek-char, I'm sure that most usage is (peek-char nil stream nil),
so today that construction looks a little silly. A quick scan of the CLHS
shows that by far most usage of the phrase "is not supplied or nil" refers
to keyword arguments not optional ones.

Regarding your example, format. I do buy your point, it introduces a mess,
and am not really rooting for multi-artiy functions as we have discussed
(i.e. skipping predecessor arguments.)

Erik.



>
> --
> __Pascal Bourguignon__
> http://www.informatimago.com/
> "Le mercure monte ?  C'est le moment d'acheter !"
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>



-- 
Erik Pearson
Adaptations
;; web form and function
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20140220/1e612f7e/attachment.htm>