>>>>> On Thu, 9 Apr 1998 19:36:20 -0500 (CDT), CoRey <omega.uta.edu at cjc9024> said:

> I have some bugs and questions to report regarding the 
> free Linux version of acl, 4.3.

There is a free version of Acl for Linux?  Where can I find out more
about it?


> BUGS: 
> -----
> First, (subseq "HellO" 0 7) will return "HELLO<GARBAGe>"!!!
> Where GARBAGE appears to be random noise in the computer's memory!
> This should never happen in LISP!  You see stuff like this in C, but
> Lisp's run time type checking should make sure this never occurs - it
> should throw an error (see CLTL2)

As Roy Turner noted, this happens in ACL 4.3 on Unix too.  On the
other hand I do not think this is really a bug in the sense that it is
not compliant with CLTL2, although GCL, HP Lisp (which is I think Lucid)
both signal an error in this case whether the first argument is an
array or a list.  Acl happily does the following:
(subseq '(H e l l 0) 0 7)
(H E L L 0)

Looking at chapter 14 of CLTL2
(http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node1.html), it says:

    Many operations allow the specification of a subsequence to be
    operated upon. Such operations have keyword arguments called
    :start and :end. These arguments should be integer indices into
    the sequence, with startend (it is an error if start>end).
                           ^^

[I think there should be a <= between start and end in "startend"
above.]

And it further defines "is an error"

    1.2.4. Errors

    When this book specifies that it ``is an error'' for some
    situation to occur, this means that:

         No valid Common Lisp program should cause this situation to occur. 

         If this situation occurs, the effects and results are
         completely undefined as far as adherence to the Common Lisp
         specification is concerned.

         No Common Lisp implementation is required to detect such an
         error. Of course, implementors are encouraged to provide
         for detection of such errors wherever reasonable.

In other words, if you do not like the behavior, do not that!  :-)

> The emacs lisp files that come with ACL are pretty nice, but the
> indentation routines are not canonical; when doing an if form, the two
> possible conditions that come after the test are not lined up
> properly.  I see something similar with a setf with a multiple number
> of setting forms.  And the annoying thing is, if I indent those 
> forms in the style of Lisp, after I hit newline, the stupid emacslisp
> program REINDENTS them the WRONG way!!!

I have the following in my .emacs file to fix indenting of IF and SETF
(the way they were intended :-)

(add-hook 'fi:common-lisp-mode-hook
	  '(lambda ()
	     (put 'setf 'fi:lisp-indent-hook nil)
	     (put 'setq 'fi:lisp-indent-hook nil)
	     (put 'if 'fi:lisp-indent-hook nil)))

Art