[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: PATHNAME-WILD (version 5)
- To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: PATHNAME-WILD (version 5)
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Tue, 13 Jun 89 13:53:43 MDT
- Cc: Sandra J Loosemore <email@example.com>, David N Gray <Gray@DSG.csc.ti.com>, CL-Cleanup@sail.stanford.edu, Gray@Kelvin.csc.ti.com
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 13 Jun 89 14:50 EDT
Your additional example has suddenly made it clear to me that I'm even
more confused than I thought I was, and that one of the reasons I'm
confused is the vagueness of the terminology in the proposal. It
seems clear from this example that my interpretation of the terms
"field" and "portion that matches" is not what you really had in mind.
Can you define these terms more precisely and perhaps annotate the
other examples to explain what exactly the "field" and "portion" are?
You seem to be interpreting "portion" to mean "the part that matches
the *" but I'm not at all clear how that would extend to a more
complicated wildcard pattern like a regular expression.
> I think they did in an earlier version, and some commentor made me change
> it to T, so as to make the language less ambiguous. Did you have a specific
> useful value in mind for them to return? If so, maybe we could just specify
> that that is what they return. If not, let's stick with T.
Well, I thought that PATHNAME-MATCH-P might conceivably return some
kind of an object representing the "portion that matches". But more
generally, all the other predicates in the language that I can think
of are defined to either return "true" or NIL. Also, in some
implementations it's slightly more efficient to return an argument
instead of T, for example.