From: Marco Antoniotti
Subject: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <y6c8zmki2ri.fsf@octagon.mrl.nyu.edu>
Hi

I was writing a little function that returns T is a sequence is a
prefix of another.

Here is what I came up with

(defun prefixp (s1 s2 &key
                      from-end (test #'eql) (test-not (complement test))
		      (key #'identity) (start1 0) (start2 0) end1 end2)
  (let ((mismatch-pos (mismatch s1 s2
				:from-end from-end
				:test test
				:test-not test-not
				:key key
				:start1 start1
				:end1 end1
				:start2 start2
				:end2 end2)))
    (or (null mismatch-pos)
	(= mismatch-pos (length s1)))))


It works, but I have some doubts about the combination of the defaults
for :TEST and :TEST-NOT.  (Also the default for :KEY seems dubious,
since the CLHS seems to imply a NIL default for it in the description
of MISMATCH).

Any comments/ideas on this?

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group	tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA			http://bioinformatics.cat.nyu.edu
             Like DNA, such a language [Lisp] does not go out of style.
			      Paul Graham, ANSI Common Lisp

From: Chris Riesbeck
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <riesbeck-D2E7A9.12503605032001@news.acns.nwu.edu>
Steele, (p 388) explicitly says "It is an error
to use [:TEST and :TEST-NOT] in the same call."

I don't see this in the HyperSpec. Did it go away, or
is there some place in the spec that has the prefatory
material for chapter 14 that I'm not seeing.


In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti 
<·······@cs.nyu.edu> wrote:

>Hi
>
>I was writing a little function that returns T is a sequence is a
>prefix of another.
>
>Here is what I came up with
>
>(defun prefixp (s1 s2 &key
>                      from-end (test #'eql) (test-not (complement test))
>		      (key #'identity) (start1 0) (start2 0) end1 end2)
>  (let ((mismatch-pos (mismatch s1 s2
>				:from-end from-end
>				:test test
>				:test-not test-not
>				:key key
>				:start1 start1
>				:end1 end1
>				:start2 start2
>				:end2 end2)))
>    (or (null mismatch-pos)
>	(= mismatch-pos (length s1)))))
>
>
>It works, but I have some doubts about the combination of the defaults
>for :TEST and :TEST-NOT.  (Also the default for :KEY seems dubious,
>since the CLHS seems to imply a NIL default for it in the description
>of MISMATCH).
From: Kent M Pitman
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <sfwd7bw3sfy.fsf@world.std.com>
Chris Riesbeck <········@ils.nwu.edu> writes:

> 
> Steele, (p 388) explicitly says "It is an error
> to use [:TEST and :TEST-NOT] in the same call."
> 
> I don't see this in the HyperSpec. Did it go away, or
> is there some place in the spec that has the prefatory
> material for chapter 14 that I'm not seeing.

17.2.1 Satisfying a Two Argument Test has it, rather than repeating
it everywhere.
From: Chris Riesbeck
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <riesbeck-28FE22.13003406032001@news.acns.nwu.edu>
In article <···············@world.std.com>, Kent M Pitman 
<······@world.std.com> wrote:

>Chris Riesbeck <········@ils.nwu.edu> writes:
>
>> 
>> Steele, (p 388) explicitly says "It is an error
>> to use [:TEST and :TEST-NOT] in the same call."
>> 
>> I don't see this in the HyperSpec. ...
>
>17.2.1 Satisfying a Two Argument Test has it, rather than repeating
>it everywhere.

I didn't follow that link because I assumed that meant
that it was about binary predicates and interactions
with things like :KEY. 

But I notice that this section says the results are
unspecified, while Steele said "is an error." 
The glossary says "unspecified" means 
"unpredictable but harmless". 

Surely 17.2.1 should say error, no?
From: Kent M Pitman
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <sfwbsrev9kw.fsf@world.std.com>
Chris Riesbeck <········@ils.nwu.edu> writes:

> In article <···············@world.std.com>, Kent M Pitman 
> <······@world.std.com> wrote:
> 
> >Chris Riesbeck <········@ils.nwu.edu> writes:
> >
> >> 
> >> Steele, (p 388) explicitly says "It is an error
> >> to use [:TEST and :TEST-NOT] in the same call."
> >> 
> >> I don't see this in the HyperSpec. ...
> >
> >17.2.1 Satisfying a Two Argument Test has it, rather than repeating
> >it everywhere.
> 
> I didn't follow that link because I assumed that meant
> that it was about binary predicates and interactions
> with things like :KEY. 
> 
> But I notice that this section says the results are
> unspecified, while Steele said "is an error." 
> The glossary says "unspecified" means 
> "unpredictable but harmless". 
> 
> Surely 17.2.1 should say error, no?

"unpredictable but harmless" probably doesn't mean what you think it means.
It certainly includes "signals an error".

There was a huge debate about this, and I'm in the camp of thinking the
old terminology was better.  My actions as editor were those of neutral
scribe, so I abided by group consensus on this since it seemed "unpredictable
but harmless" to do so (heh).

Basically, the old "is an error" terminology was phased out, though due to
budgetary concerns didn't get wholly removed.  It never meant "signals
an error", it always meant "might signal an error".  

Some people, chief among them Dick Gabriel, as I recall, but others, too,
argued that there was a subtle distinction between errors of the kind
that Lisp itself would trap (e.g., unbound variable) and errors so severe
that they might hurt Lisp's integerity or things outside Lisp.  So, as
we were recently talking about in another thread, if you jump to random 
memory and start executing data (assuming your memory model permits this),
you're in the "undefined consequences".  Errors that might get signaled
but might be harmless are in the unspecified rrange.  Suppose, for example,
that I put NIL or some unbound object into a variable value cell and
then turn off value cell checking?  Well, then if you access the variable
you'll get NIL or an unexpected value.  That's considered "unspecified"
because you are still within Lisp and all of your models of the effect
of normal programmatic techniques for moving from [Lispy] instruction to
[Lispy] instruction are still in play.

Anwyay, so back to what we said above, there is no inconsistency with
saying that using both test and test-not is unspecified.  Either one will
get used or the other, or the system will notice it and flag the error.
All of these are well-defined within the langauge, and that's what
"is unspecified" means.  Further, that's exactly what woudl have happened
under the "is an error" terminology.

I personally don't like the "is unspecified" vs "has undefined consequences"
terminology because it forces people to reason about things that are outside
the real realm of anything we can tell them about.  It's like reasoning
about whether one infinity is bigger than another infinity, but without 
the ability to appeal to a neutral framework like mathematics to tell you
for sure if it's ever going to matter...

PLUS, the thing that REALLY bugs me about it, is that the whole notion
of "harmless" is too calming.  For example,
 (if (unspecified-but-hopefully nil) (harmful))
is hardly harmless if it returns t, a defined-to-be-harmless result.

Go it goes at the design end.

My question is in reverse.  Does anyone USE this distinction in the language
and has it ever proved productive?

The really ironic thing about this is that in most other situations in
editing the spec, Dick Gabriel was a real force for simplifying out the 
distinctions that didn't matter.  He's the one that tought me that phrases
like "x really and truly ought to do y" really means "x is unspecified"
or "x can either do y or not as it pleases" because you either have the force
of contract behind an operator or you don't.  There is no "ought" or "should"
in normal English that has force of weight in standards.  Mostly in such
cases, we just lined out sentences that said things about ought and should
since they did not add to the specification.  The exception is the error
terminology "should signal" which we gave formal meaning to, of course.  But
other uses of "should" don't have this formality.  So Gabriel went through
a bunch of text lining out things that he tought were wishy-washy and I
followed through checking his claims and mostly ending up agreeing, and this
tightened up a lot of the text from what was in CLTL(1).  But this particular
case of "is an error" stands as what I see as an exception to his
probably-correct zeal for simplicity where I think we introduced distinctions
that we could not prove and that were only going to confuse people.

I only went along with it because it seemed, as I said, like something no
one would ever be able to get anything out of.  And because I didn't have
the personal time to fight against this weird thing.  There were myriad 
things to attend to in producing the standard and we all had to pick our
battles pretty carefully.
From: Chris Riesbeck
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <riesbeck-1B8EE4.17271506032001@news.acns.nwu.edu>
In article <···············@world.std.com>, Kent M Pitman 
<······@world.std.com> wrote:

>"unpredictable but harmless" probably doesn't mean what you think it means.
>It certainly includes "signals an error".
>
>There was a huge debate about this, and I'm in the camp of thinking the
>old terminology was better.  
>
> ...
>
>PLUS, the thing that REALLY bugs me about it, is that the whole notion
>of "harmless" is too calming.  

I'm with you. I always understood "is an error" didn't mean "signals
an error," but signalling an error doesn't feel harmless to me in
the middle of a demo to funding agents.

>Anwyay, so back to what we said above, there is no inconsistency with
>saying that using both test and test-not is unspecified.  Either one will
>get used or the other, or the system will notice it and flag the error.

Also legal, I presume, is applying the conjunction of TEST and 
TEST-NOT. I'm sure there's some example where that would be
convenient. Is there a reason why that wasn't used in the CL
originally? Like something that will make me go "duh" as soon
as it's mentioned?
From: Barry Margolin
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <ALtp6.27$%K3.16744@burlma1-snr2>
In article <······························@news.acns.nwu.edu>,
Chris Riesbeck  <········@ils.nwu.edu> wrote:
>I'm with you. I always understood "is an error" didn't mean "signals
>an error," but signalling an error doesn't feel harmless to me in
>the middle of a demo to funding agents.

No.  In CLTL, "is an error" always meant what the standard refers to as
"consequences are undefined".  See section 1.2.4 "Errors" where it clearly
explains the distinction between "is an error" and "an error is signaled."

X3J13 added finer distinctions of erroneous situations.  We added
"consequences are unspecified", "should be prepared to signal", and "may be
signalled" (the last indicates that the error must be detected and
signalled in safe code, but might not be detected in unsafe mode).

>>Anwyay, so back to what we said above, there is no inconsistency with
>>saying that using both test and test-not is unspecified.  Either one will
>>get used or the other, or the system will notice it and flag the error.
>
>Also legal, I presume, is applying the conjunction of TEST and 
>TEST-NOT. I'm sure there's some example where that would be
>convenient. Is there a reason why that wasn't used in the CL
>originally? Like something that will make me go "duh" as soon
>as it's mentioned?

If you want to apply multiple tests, use :TEST or :TEST-NOT, and make your
predicate check both things, e.g.

 :test (lambda (x) (and (pred1 x) (not (pred2 x)))))

I think the designers felt that allowing both :TEST and :TEST-NOT would
likely be confusing (you could probably justify defining them to be either
a conjunction or a disjunction).  The only reason :TEST-NOT even exists is
as a simple convenience, to avoid having to write :test (lambda (x) (not ...)).

-- 
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Chris Riesbeck
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <riesbeck-E0AA10.18030407032001@news.acns.nwu.edu>
In article <··················@burlma1-snr2>, Barry Margolin 
<······@genuity.net> wrote:

>In article <······························@news.acns.nwu.edu>,
>Chris Riesbeck  <········@ils.nwu.edu> wrote:
>>I'm with you. I always understood "is an error" didn't mean "signals
>>an error," ...
>
>No.  In CLTL, "is an error" always meant what the standard refers to as
>"consequences are undefined".  

I phrased that confusingly. I was trying to say above that the
phrase "is an error" did not imply in any way "signals an error." 
If something was an error, you were on your own
as to what might happen. 

So I think I understood the same thing you're saying.

It's the "harmless" part of the new wording that throws me, when
it includes signalling an error.

>>Also legal, I presume, is applying the conjunction of TEST and 
>>TEST-NOT.... Is there a reason why that wasn't used in the CL
>>originally? 
>
>I think the designers felt that allowing both :TEST and :TEST-NOT would
>likely be confusing (you could probably justify defining them to be either
>a conjunction or a disjunction). 

Though I'm not sure this alternative has ended up any less
confusing.  Are there other instances where a tricky choice was
resolved as "it's an error" rather than choosing one? Certainly
with multiple inheritance problems, CLOS always has an answer, whereas
C++ says "none of the above."
From: Barry Margolin
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <GtAp6.41$%K3.21911@burlma1-snr2>
In article <······························@news.acns.nwu.edu>,
Chris Riesbeck  <········@ils.nwu.edu> wrote:
>In article <··················@burlma1-snr2>, Barry Margolin 
><······@genuity.net> wrote:
>
>>In article <······························@news.acns.nwu.edu>,
>>Chris Riesbeck  <········@ils.nwu.edu> wrote:
>>>I'm with you. I always understood "is an error" didn't mean "signals
>>>an error," ...
>>
>>No.  In CLTL, "is an error" always meant what the standard refers to as
>>"consequences are undefined".  
>
>I phrased that confusingly. I was trying to say above that the
>phrase "is an error" did not imply in any way "signals an error." 

Actually, the problem was that I misread what you wrote; you said "didn't
mean" and I read "to mean", i.e. the exact opposite of what you meant!

>If something was an error, you were on your own
>as to what might happen.

True.  However, in many cases implementations *will* signal an error.  For
instance, Lisp Machines ignore type declarations and always do hardware
type checking, and in safe mode most other implementations also do type
checking, so violating a type declaration will still result in an error
being signalled.  You can't officially depend on it portably, but
informally it's a good bet.

>So I think I understood the same thing you're saying.
>
>It's the "harmless" part of the new wording that throws me, when
>it includes signalling an error.

That's part of the distinction between "undefined" and "unspecified".  CLTL
didn't have this, but it was added by X3J13.

>>>Also legal, I presume, is applying the conjunction of TEST and 
>>>TEST-NOT.... Is there a reason why that wasn't used in the CL
>>>originally? 
>>
>>I think the designers felt that allowing both :TEST and :TEST-NOT would
>>likely be confusing (you could probably justify defining them to be either
>>a conjunction or a disjunction). 
>
>Though I'm not sure this alternative has ended up any less
>confusing.  Are there other instances where a tricky choice was
>resolved as "it's an error" rather than choosing one? Certainly
>with multiple inheritance problems, CLOS always has an answer, whereas
>C++ says "none of the above."

Any choice would have been totally arbitrary, and I don't think a good
justification could have been made.  It's likely that different
implementations were already handling them differently; the code probably
looks something like:

(cond ((test (funcall test key)))
      ((test-not (not (funcall test-not key))))
      (t key))

but some implementations might change the order of the test and test-not
clauses.  To select one or the other would favor some implementations and
force the others to change incompatibly for no good reason.

Furthermore, there's a third potential interpretation, which might be even
more intuitive to end users.  If you think of :TEST-NOT as just a shorthand
for :TEST with an inverted predicate, then you might expect them to
override each other, the way multiple instances of the same keyword do
(i.e. :test #'foo :test #'bar is equivalent to :test #'bar -- the last
:test takes precedence).  But implementing this would be difficult.  The
built-in &key processor automatically handles duplicates of the same
keyword, but when two different keywords are involves it's hard to tell
which order they appeared in the original argument list; the functions
would have to have an &rest argument to get all the keywords, and then scan
it manually to see the order.

-- 
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Joe Marshall
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <lmqi5wq2.fsf@content-integrity.com>
Kent M Pitman <······@world.std.com> writes:

> Some people, chief among them Dick Gabriel, as I recall, but others,
> too, argued that there was a subtle distinction between errors of
> the kind that Lisp itself would trap (e.g., unbound variable) and
> errors so severe that they might hurt Lisp's integrity or things
> outside Lisp.

I think that distinction is too subtle. 

> Anwyay, so back to what we said above, there is no inconsistency with
> saying that using both test and test-not is unspecified.  Either one will
> get used or the other, or the system will notice it and flag the error.

But that *isn't* what it says.  It says unspecified, which means you
can't really depend on it to do *anything* at all.

> PLUS, the thing that REALLY bugs me about it, is that the whole notion
> of "harmless" is too calming.  For example,
>  (if (unspecified-but-hopefully nil) (harmful))
> is hardly harmless if it returns t, a defined-to-be-harmless result.

I agree completely.

Perhaps in a future spec things like this could be nailed down more
concretely, maybe like this:

  If both :test and :test-not are specified an implementation may
  signal an error, or simply ignore one or the other.

  


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Kent M Pitman
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <sfwsnksqeup.fsf@world.std.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> I was writing a little function that returns T is a sequence is a
> prefix of another. [...]
> It works, but I have some doubts about the combination of the defaults
> for :TEST and :TEST-NOT.  (Also the default for :KEY seems dubious,
> since the CLHS seems to imply a NIL default for it in the description
> of MISMATCH).
> 
> Any comments/ideas on this?

I'd either just leave out test-not or do something like:

 (defun  ... (... &key test test-not ...)
   (cond ((and test test-not) (error "Can't have both :test and :test-not."))
         (test-not (setq test (complement test-not))))
   ... use only test, ignore test-not ...)


[No, I didn't test it.  All those dots kept causing reader errors. :-)]
From: Barry Margolin
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <KBQo6.16$8q1.21652@burlma1-snr2>
In article <···············@octagon.mrl.nyu.edu>,
Marco Antoniotti  <·······@cs.nyu.edu> wrote:
>
>Hi
>
>I was writing a little function that returns T is a sequence is a
>prefix of another.
>
>Here is what I came up with
>
>(defun prefixp (s1 s2 &key
>                      from-end (test #'eql) (test-not (complement test))
>		      (key #'identity) (start1 0) (start2 0) end1 end2)
>  (let ((mismatch-pos (mismatch s1 s2
>				:from-end from-end
>				:test test
>				:test-not test-not
>				:key key
>				:start1 start1
>				:end1 end1
>				:start2 start2
>				:end2 end2)))
>    (or (null mismatch-pos)
>	(= mismatch-pos (length s1)))))
>
>
>It works, but I have some doubts about the combination of the defaults
>for :TEST and :TEST-NOT.  

As well you should.  Section 17.2.1 says "The consequences are unspecified
if both a :TEST and a :TEST-NOTargument are supplied in the same call to F."

>			   (Also the default for :KEY seems dubious,
>since the CLHS seems to imply a NIL default for it in the description
>of MISMATCH).

In 17.2.1 it says that if NIL is supplied, the key is the same as the
element, which is equivalent to saying that NIL is treated the same as
#'IDENTITY.

The simple way to implement your function is:

(defun prefixp (s1 s2 &rest mismatch-keywords)
  (let ((mismatch-pos (apply mismatch s1 s2 mismatch-keywords)))
    (or (null mismatch-pos)
        (= mismatch-pos (length s1)))))

-- 
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Marco Antoniotti
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <y6c1yschx34.fsf@octagon.mrl.nyu.edu>
Barry Margolin <······@genuity.net> writes:

> In article <···············@octagon.mrl.nyu.edu>,
> Marco Antoniotti  <·······@cs.nyu.edu> wrote:
> >
> >Hi
> >
> >I was writing a little function that returns T is a sequence is a
> >prefix of another.
> >
> >Here is what I came up with
> >
> >(defun prefixp (s1 s2 &key
> >                      from-end (test #'eql) (test-not (complement test))
> >		      (key #'identity) (start1 0) (start2 0) end1 end2)
> >  (let ((mismatch-pos (mismatch s1 s2
> >				:from-end from-end
> >				:test test
> >				:test-not test-not
> >				:key key
> >				:start1 start1
> >				:end1 end1
> >				:start2 start2
> >				:end2 end2)))
> >    (or (null mismatch-pos)
> >	(= mismatch-pos (length s1)))))
> >
> >
> >It works, but I have some doubts about the combination of the defaults
> >for :TEST and :TEST-NOT.  
> 
> As well you should.  Section 17.2.1 says "The consequences are unspecified
> if both a :TEST and a :TEST-NOTargument are supplied in the same call to F."
> 
> >			   (Also the default for :KEY seems dubious,
> >since the CLHS seems to imply a NIL default for it in the description
> >of MISMATCH).
> 
> In 17.2.1 it says that if NIL is supplied, the key is the same as the
> element, which is equivalent to saying that NIL is treated the same as
> #'IDENTITY.
> 
> The simple way to implement your function is:
> 
> (defun prefixp (s1 s2 &rest mismatch-keywords)
>   (let ((mismatch-pos (apply mismatch s1 s2 mismatch-keywords)))
>     (or (null mismatch-pos)
>         (= mismatch-pos (length s1)))))
> 

I have only one answer to all the responses: dah!

I should have thought of it myself.

Thanks

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group	tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA			http://bioinformatics.cat.nyu.edu
             Like DNA, such a language [Lisp] does not go out of style.
			      Paul Graham, ANSI Common Lisp
From: Janis Dzerins
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <874rx8nm62.fsf@asaka.latnet.lv>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> Hi
> 
> I was writing a little function that returns T is a sequence is a
> prefix of another.
> 
> Here is what I came up with
> 
> (defun prefixp (s1 s2 &key
>                       from-end (test #'eql) (test-not (complement test))
> 		      (key #'identity) (start1 0) (start2 0) end1 end2)
>   (let ((mismatch-pos (mismatch s1 s2
> 				:from-end from-end
> 				:test test
> 				:test-not test-not
> 				:key key
> 				:start1 start1
> 				:end1 end1
> 				:start2 start2
> 				:end2 end2)))
>     (or (null mismatch-pos)
> 	(= mismatch-pos (length s1)))))
>
> It works, but I have some doubts about the combination of the defaults
> for :TEST and :TEST-NOT.  (Also the default for :KEY seems dubious,
> since the CLHS seems to imply a NIL default for it in the description
> of MISMATCH).
> 
> Any comments/ideas on this?

Why not this:

(defun prefixp (s1 s2 &rest keys)
  (let ((pos (apply #'mismatch s1 s2 keys)))
    (or (null pos)
        (= pos (length s1)))))

-- 
Janis Dzerins

  If million people say a stupid thing it's still a stupid thing.
From: Kent M Pitman
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <sfwn1b0qdrc.fsf@world.std.com>
Janis Dzerins <·····@latnet.lv> writes:

> Why not this:
> 
> (defun prefixp (s1 s2 &rest keys)
>   (let ((pos (apply #'mismatch s1 s2 keys)))
>     (or (null pos)
>         (= pos (length s1)))))

Oh, I didn't look closely at the function.  I agree with this.  However,
an idiom that is often useful in this kind of case which gets you better
error checking is to make the arglist say:

 (sq1 s2 &rest keys &key &allow-other-keys)

This says that although it takes a rest list arglist, the keys should be
in even pairs, and technically licenses the compiler to check that calls
to PREFIXP are made with even pairs (where such can be determined).
From: Mike McDonald
Subject: Re: Best way to default :TEST and :TEST-NOT parameters.
Date: 
Message-ID: <1rTo6.258$a3.9636@typhoon.aracnet.com>
In article <···············@world.std.com>,
	Kent M Pitman <······@world.std.com> writes:

> Oh, I didn't look closely at the function.  I agree with this.  However,
> an idiom that is often useful in this kind of case which gets you better
> error checking is to make the arglist say:
> 
>  (sq1 s2 &rest keys &key &allow-other-keys)

  And 

 (defun prefixp (s1 s2 &rest keys 
                 &key test test-not 
                      start1 start2
                      end1 end2
                      key from-end &allow-other-keys)
   (declare (ignore test test-not start1 start2 end1 end2 key from-end))
   (let ((pos (apply #'mismatch s1 s2 keys)))
     (or (null pos)
         (= pos (length s1)))))

  will add the what the expected keywords are for documentation purposes. 

  Mike McDonald
  ·······@mikemac.com