[Top][All Lists]

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

Re: [Gcl-devel] Dotted lists

From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] Dotted lists
Date: Sun, 25 Aug 2002 22:28:58 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526

Camm Maguire пишет:
> Greetings!
> Gcl has apparently been designed to only handle proper lists.  I have a
> working tree which can compile itself and maxima, and which extends
> functionality to dotted lists in general, but may yet have a few loose
> ends.  Before I commit, I'd like to consult with the list.
> 1) One solution of course is to modify the reader to store dotted
>    lists in proper form.  This of course would eliminate the
>    distinction between the two forms of list.  I take it one wants the
>    ability to distinguish between the two, but I can't see why.  Is
>    the standard just written to included dotted lists because some
>    original implementations tried to save the space of the final cons?
>    Or are they useful as distinct from proper lists?
> 2) The solution I have preserves the distinction, but alters the endp
>    macro to redirect the list to a special cons pointing to the final
>    cdr atom when passed an argument of this atom.  In this way, all
>    bodies of loops over lists will handle all elements properly
>    including the last.  At loop end, the list variable holds Cnil for
>    a proper list, or a special symbol indicating the end of a dotted
>    list.  This allows certain functions which return their answers as
>    lists to either dot the last element or cons it as usual.  Such end
>    loop processing has to be done function by function, but I made the
>    determination that such functions which care about the form of the
>    end of a list, apart from the fact that the list is at end, are
>    few, and preserving uniform treatment of loop body code is more
>    important.  The compiler actually wrote calls to endp with
>    arguments which could not be redirected in certain places, so these
>    have been adjusted as well.  There are only two places in the
>    compiler where it still seems necessary to use the old endp
>    behavior (i.e. for proper lists only), but this may actually be
>    used only for compiler internals, and in any case might be worked
>    around n the future.  On the other hand, if there are certain
>    definable areas where dotted lists should not be allowed, it would
>    be better to preserve the old endp in such places.  In any case,
>    the behavior for proper lists should be completely unchanged.  All
>    of Paul's related bug reports are fixed in this tree, to my
>    understanding.
> Is this the right strategy here?
> a) Do we need to support dotted lists as separate objects from proper lists?
> b) Is the idea that all elements of both should be
>    handled the same in most places, with exceptions treated by hand,
>    valid?
> c) Does anyone know if inferences can be made regarding the type lists the
>    compiler uses at various points?  I can give specifics on request.
> Take care,

Frankly, I don't quite understand you.  Why do you think that GCL
does not support dotted list?  Actually the only structure any Lisp
(and CL and GCL in particular) works with are binary trees which
recursively consist of so called dotted pairs (CAR . CDR) where
CAR and CDR are either atoms or dotted pairs onece again.
Notice that such structures are comletetely symmetric with
respect to CAR and CDR. However it is true that usually it is convenient and sufficient to work with subclass od binary trees
- proper lists.  And many CL bult in functions expect proper
lists as their arguments.  With this exception proper and dotted
lists must be treated on equal footing.

I don't know about compiler but a) and b) seems to be OK.
Dotted lists are absolutely essential and must not be
mapped into proper lists.  Any practical distiction must
be addressed at each concrete functin.

Best wishes,


      Vadim V. Zhytnikov


reply via email to

[Prev in Thread] Current Thread [Next in Thread]