I made a mistake; the correct version is:
(defun nfirst-n (l n)
(setf (cdr (nthcdr (1- n) l)) '()))
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Vassil Nikolov <········@poboxes.com> writes:
> I made a mistake; the correct version is:
>
> (defun nfirst-n (l n)
> (setf (cdr (nthcdr (1- n) l)) '()))
problem is that when (> n (length l)) you run into problems. you
probably shouldn't generate an error in that case, but you do.
dave
In article <···············@engc.bu.edu>,
David Bakhash <·····@bu.edu> wrote:
> Vassil Nikolov <········@poboxes.com> writes:
>
> > I made a mistake; the correct version is:
> >
> > (defun nfirst-n (l n)
> > (setf (cdr (nthcdr (1- n) l)) '()))
>
> problem is that when (> n (length l)) you run into problems. you
> probably shouldn't generate an error in that case, but you do.
Sure there's a problem. It is in the absence of a specification
for NFIRST-N, and consequently of any documentation for it given
by myself. The BLPFH's answer would be, `The documentation says
the consequences are undefined if (> N (LENGTH L)).' (BLPFH is,
of course, Bastard Lisp Programmer From Hell.)
There is in fact one more serious problem with my implementation
(actually with the implied spec to which it was written) in that
it returns NIL and not L.
My obvious intent was to show the general idea in a most concise
manner. The real issue is, what do you want to do with NFIRST-N
and hence what its spec is. Apparently you want something along
these lines:
(defun nfirst-n (l n)
(let ((result-last (nthcdr (1- n) l)))
(when result-last (setf (rest result-last) '())))
l)
but I'm already making more than a healthy amount of assumptions
what your spec for NFIRST-N really is.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Sorry, this is off-topic but this post amazed me:
On Sun, 28 Mar 1999 20:28:52 GMT, Vassil Nikolov <········@poboxes.com> wrote:
>Sure there's a problem. It is in the absence of a specification
>for NFIRST-N, and consequently of any documentation for it given
>by myself. The BLPFH's answer would be, `The documentation says
>the consequences are undefined if (> N (LENGTH L)).' (BLPFH is,
>of course, Bastard Lisp Programmer From Hell.)
>
>There is in fact one more serious problem with my implementation
>(actually with the implied spec to which it was written) in that
>it returns NIL and not L.
>
>My obvious intent was to show the general idea in a most concise
>manner. The real issue is, what do you want to do with NFIRST-N
>and hence what its spec is. Apparently you want something along
>these lines:
Look at the right margin! It's perfectly aligned! And yet there's no
extra whitespace between the words anywere! A single space between
words, and two spaces after periods, just like it's supposed to be!
How is that possible? :) I think I'll hack together a Lisp program
that tries to do this kind of alignment. (See, I made it on-topic
after all!)
Fredrik Sandstrom | "I have never let my schooling
·······@infa.abo.fi | interfere with my education."
http://infa.abo.fi/~fredrik | - Mark Twain
From: David Bakhash
Subject: Re: correction: NFIRST-N
Date:
Message-ID: <wkvhfh1svk.fsf@mit.edu>
Vassil Nikolov <········@poboxes.com> writes:
> but I'm already making more than a healthy amount of assumptions
> what your spec for NFIRST-N really is.
I was only implying that, as with `last' and `butlast', when n exceeds
the length of the list, you don't run into problems. But whatever.
it's not important.
dave
In article <··············@mit.edu>,
David Bakhash <·····@mit.edu> wrote:
> Vassil Nikolov <········@poboxes.com> writes:
>
> > but I'm already making more than a healthy amount of assumptions
> > what your spec for NFIRST-N really is.
>
> I was only implying that, as with `last' and `butlast', when n exceeds
> the length of the list, you don't run into problems. But whatever.
> it's not important.
I hoped you would mention the problems with circular lists:
* my implementation of FIRST-N used SUBSEQ which does not work with
circular lists at all; a straightforward implementation of FIRST-N
from basic primitives would happily return something that may or may
not be very useful if passed a circular list;
* my implementation of NFIRST-N as well as a straightforward
implementation of NFIRST-N from basic primitives would return
something that may or may not be very useful if passed a circular
list, and would destroy the circularity.
(Note that BUTLAST/NBUTLAST just don't work with circular lists but
the case with FIRST-N/NFIRST-N might be different since it is `more
correct' to say that a circular list has a first cons than a last
cons: even if #1=(A B C . #1#) doesn't have a `true first cons,'
(A . #1=(B C . #1#)) does, and neither of them has a `true last
cons' (I hope I don't have to formalise this intuitive notion of
`true first/last cons').)
So while this whole issue is not very important indeed, within
the issue the really important thing is *what one wants FIRST-N and
NFIRST-N for*: for some specific purpose where circular lists
just don't matter, or as general purpose list manipulation
utilities for which circular lists should be taken into account
somehow.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own