Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: (not (equalp 'flet objects)) Message-ID: <3215@skye.ed.ac.uk> Date: 16 Aug 90 15:35:31 GMT References: <1990Aug15.221853.12292@Neon.Stanford.EDU> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 84 I suggested writing a "module" like this: (let (...) ; private variables (labels (...) ; private functions (defun ...) ; public functions ... )) The entire form can be quite large, and so it would be a pain if, to recompile any of it, I had to recompile all of it. In article <1990Aug15.221853.12292@Neon.Stanford.EDU> michaelg@Neon.Stanford.EDU (Michael Greenwald) writes: >gumby@Cygnus.COM (David Vinayak Wallace) writes: [This is about my module example above.] >> It's possible I'm not understanding you clearly. Why isn't what you >> describe simply a single instance of a class? The private variables >> are slots, the private functions are GENERIC-LABELS (or in pre-CLOS >> flavors, DEFUN-IN-FLAVOR's) and the DEFUNs are DEFMETHODs? >>Because the generic functions would have to recieve the single >>instance of an argument, while under Jeff's scheme (and in Scheme) the >>sole discriminator is the name. Of course in scheme, unlike cl, the >>defun-ed/define-ed names would not be apparent outside the bounding >>let. >I thought of that, but I decided "Nah, he couldn't have meant that" >since he said "(perhaps with the aid of some macros)". Since there's >a single instance of this class, it wouldn't be hard to write the >macrology he wants like > >(defmacro (&rest arglist) > `( *single-instance* . ,arglist)) > >so he must want to do something more complicated that I don't understand. No, I want something *simpler*. Perhaps I should have been clearer about the role of macros. I meant the expansion would have the form I suggested above, not that the macros would produce something that had roughly similar (or better!) semantics. Of course, there might be better solutions that make use of CLOS in one way or another. However there isn't an equivalent to DEFUN-IN-FLAVOR (though I suppose something sufficiently like it might be constructed). GENERIC-LABLES might well have the same problems as LABELS. Nonetheless, I think you're right that something using classes and methods, with suitable syntactic sugar, might be the way to go. >With this macrology is the sole discriminator. In Scheme >you're doing the same thing - the name is bound to a closure: the >function and the environment (in our case, the instance). In Scheme >the language does it under the covers, in CL you have to do it explicitly. But CL has closures too. I can do more or less the same thing in CL that I can in Scheme, can't I? (Unless you have in mind the first-class environments some Schemes have.) >You can do the same thing passing around an explicit environment >instead of the instance, but accessing slots is probably faster than >any home grown environment you'd construct. It's ugly, but I think >it's what he wants. My suggestion was to use the normal lexical environments provided by the CL implementation. Access to a variable from within a closure should be faster than slot access. >In short, classes provide a way to do modules without recompiling. >But is the requirement of recompilation of the whole module the only >"lack of support" in CL? If so, why is this more of a problem in CL >than in other languages? If this isn't the only problem you were >alluding to, then I missed (or misunderstood) your (Jeff's) original >complaint. Just because something is a problem in other languages too doesn't mean it isn't one in CL too. My only role in this discussion, however, was to suggest, in response to an observation that the parent wouldn't be very large, that it might be larger than one might guess.