Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.lisp Subject: Re: Types in Common Lisp (was Re: In defense of call/cc) Message-ID: <1991Feb20.040855.21375@Think.COM> Date: 20 Feb 91 04:08:55 GMT References: <1350036@otter.hpl.hp.com> <1991Feb18.031643.10720@cs.cmu.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 56 In article kers@hplb.hpl.hp.com (Chris Dollin) writes: > >Steve Knight said: > > > [3] equality doesn't work the way it does in other lisps & is > >a nasty source of problems (e.g. portability) > >and got various responses on the lines "but how would the system know to do any >better?". Surely the answer is "it doesn't; but the programmer does, and they >can tell the system what to do"; viz, attatch to datatypes a user-definable >equality procedure with a suitable default (probably structural equality). > >Thus a defstruct would have a equality-predicate option (eqp?) and all the >system types would come equipped with standard-defined eqp's (which might be >indirected through symbols, so they could be changed if one felt reckless). The >standard function eqp could then just dispatch through a type-indexed table. I started writing a paper for Lisp Pointers on this subject a couple of years ago, but never got it polished enough for submission. I covered both equality and copying. My proposal used CLOS to define the generic operations. One issue I grappled with is that equality and copying are dependent on context, not just types. For instance, if you pass a pair of conses to an equality predicate, the equality algorithm depends on whether you are treating it as a tree, an association list, or a set. My solution was to allow particular types to define keyword arguments so that they can be further parametrized. It's then up to the caller of the function to realize that the data structure contains types that need such parametrization, and supply the options if necessary. For instance, the method for CONSes accepts keywords that specify a predicate for determining whether an object is a leaf node and how leaf nodes should be compared. >The only question that comes to mind is whether the indexing should be on one >argument or two, and if on one, whether we assume that two objects of different >data-type can ever be equal - sorry eqp - eg is (eqp 1.0 1) true or not? Since CLOS allows specialization on multiple arguments, I didn't constrain this, although I think I specified that the default primary method treats objects of different types as unequal. > > >-- > >Regards, Kers. | "You're better off not dreaming of the things to come; >Caravan: | Dreams are always ending far too soon." -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar