From: David Bakhash
Subject: a generalized #'equal function
Date:
Message-ID: <wk3e5mq38a.fsf@mit.edu>
hey,
What do people think of this idea:
write a macro that creates an #'equal (like) function which obeys
certain criteria. here's an example of how it might look:
(def-generalized-equal my-equal
(:string :case-sensetive)
(:char :case-sensetive)
(:list :recursive) ; like #'tree-equal
)
...etc. The idea is that you can specify how it behaves, and pow. And
then, if `def-generalized-equal' can deduce (based on the constraints)
that what you want is equivalent to #'equalp or some other pre-existing
fnc, then it can just make an alias with:
(setf (symbol-function 'my-equal) #'equalp)
comments? does a facility like this already exist?
dave
David Bakhash <·····@mit.edu> writes:
> What do people think of this idea:
> write a macro that creates an #'equal (like) function which obeys
> certain criteria. here's an example of how it might look:
> (def-generalized-equal my-equal ...)
It's not an unreasonable idea. (Though I'm not sure why you don't just
make a generalized-equal that takes a lot of keyword arguments.
Not that that's the only way to do it, but it seems more like the style
of things that are already there. Still, we're just talking personal
taste, and Lisp accomodates multiple tastes. What you suggest is not
outside the bounds of reason...)
Also, if you haven't read my EQUAL Rights paper from Lisp Pointers at
http://world.std.com/~pitman/PS/EQUAL.html
you might find it useful in thinking about this. Every time anyone
talks about "fixing" equal (or working around its brokenness) I wish
whatever solution they picked would solve the related set of issues
for COERCE and and other related operations. What is really in play
is not that EQUAL doesn't know the right thing to do, but that there
are several right things to do because looking at the representational
type can't help you distinguish between two intentional types (such
as trees and dotted pairs) that use the same representational type
(trees). When you don't pass enough information to your function,
it's forced to only work part of the time and you're forced to need
lots of functions (one for each possible situation). This will
hopefully be more clear if you read the article.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Also, if you haven't read my EQUAL Rights paper from Lisp Pointers at
> http://world.std.com/~pitman/PS/EQUAL.html
>you might find it useful in thinking about this. Every time anyone
>talks about "fixing" equal (or working around its brokenness) I wish
>whatever solution they picked would solve the related set of issues
>for COERCE and and other related operations.
I don't see his macro as a way to "fix equal", but merely as a way to solve
the problem of remembering which equal is which, as well as construct other
varieties that meet his application's needs. Rather than trying to have a
single function that does the right thing (which your paper points out
can't really exist), it allows the programer to define the
application-specific predicate he needs and give it a name that's
meaningful in his context. If it happens to match the specification of a
built-in function, it simply defines an alias, otherwise it defines the
appropriate function. It seems to be addressing the issue in the right
way, rather than the intuitive way that many programmers try to come up
with.
I finally got around to reading the Steele talk that's been discussed in
another thread, and I think his idea fits in with that philosophy: it's a
design pattern that takes the place of growing the language with lots of
specialized features.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
Barry Margolin <······@bbnplanet.com> writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
> >Also, if you haven't read my EQUAL Rights paper from Lisp Pointers at
> > http://world.std.com/~pitman/PS/EQUAL.html
> >you might find it useful in thinking about this. Every time anyone
> >talks about "fixing" equal (or working around its brokenness) I wish
> >whatever solution they picked would solve the related set of issues
> >for COERCE and and other related operations.
>
> I don't see his macro as a way to "fix equal", but merely as a way to solve
> the problem of remembering which equal is which
Yeah, I didn't really mean to say he was trying to fix equal.
I was more saying I think someone should fix equal, or we'll be
doomed to people forever working around it. It's me that thinks
it's broken, and me who infers these other weird things as people
saying to the language designers "I couldn't figure out why this
function that looks so generic doesn't really work for all the
cases I need it to work for" and so they keep creating solutions
for problems I don't think they should be having. Guilt driving
my perceptions, I suppose. But, hey, I DID propose just flushing
EQUAL from the language rather than put it in there with such a
weird and messy definition. On some days, I think omitting EQUAL
would have been better. On others, I think people get value from
clumsy tools like this (even if I also think it would be more
value if they understood the nature of the clumsiness, which I
think sometimes they're lulled into ignoring). And on others still,
I wish for a solution like the one I keep pointing to in the EQUAL
article--with a "type" argument to equal.