If a fhash provided exactly the same API as a hashtable (which it could) then it is a hashtable, and this improved performance for small numbers of entries ought be a feature of any modern quality implementation. The only reason it needs a different name is that if the implementation doesn't provide it, there is no portable way to modify the implementation's implementation. BTW, the implementation probably could do a better job than portable user code at reducing the slight reduced performance for large fhash. Lisp has called these things hash tables ever since they were invented -- do we need two names for the same thing? If so, I've got a problem with this "cons" thingus. Or perhaps I'm just feeling grumpy tonite. A more serious future issue is that as CL slowly moves towards SMP one of the hairy implementation issues is providing efficient hash tables that are hazard free. It is really hard to do this in user code without huge efficiency loss. So fhash might be restricted to uses that cannot be shared between threads, unless it's performance improvement were provided by the native implementation.
Oh, yes, thank you very much for bringing up the issue of threads! I have to mention that they are not thread-safe. The CL definition does not say whether hash tables are thread-safe since the CL definition has no thread concept. CCL hash tables are thread-safe. Right now, they aren't CLOS instances at all. It was sort of a little pedagogical point of the exercise that an abstraction doesn't have to be a CLOS object. This is part of my whole claim that CLOS, unlike, say, CLU, isn't trying to be an encapsulation mechanism. If you want encapsulation, that's what packages are for. Java tries to both and ends up with baroque rules about how "protected" interacts with "in different packages". But Fare pointed out to me that being able to add generic functions specialized on these would be a good thing. This would mean making them use CLOS not for encapsulation but for genericty. So maybe there could be a subclass that did the locking. Java's new collection library also provides basic non-thread-safe collections, and then thread-safe ones built upon them. Thread-safety costs. I really ought to measure that, though.
On Tue, 14 Jun 2011 09:32:50 -0400, Daniel Weinreb said:
But Fare pointed out to me that being able to add generic functions specialized on these would be a good thing. This would mean making them use CLOS not for encapsulation but for genericty.
Use can specialize methods on defstruct classes too, so they don't have to be CLOS instances defined with defclass. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/
On Jun 14, 2011, at 19:30 , Martin Simmons wrote:
On Tue, 14 Jun 2011 09:32:50 -0400, Daniel Weinreb said:
But Fare pointed out to me that being able to add generic functions specialized on these would be a good thing. This would mean making them use CLOS not for encapsulation but for genericty.
Use can specialize methods on defstruct classes too, so they don't have to be CLOS instances defined with defclass.
Built-in classes too[1], which means that you can have methods specialized on (e.g.) single-float and double-float, fixnum and bignum, list and vector, etc. [1] I think, but I cannot find the relevant reference just now.
Raymond Wiker <rwiker@gmail.com> writes:
On Jun 14, 2011, at 19:30 , Martin Simmons wrote:
> On Tue, 14 Jun 2011 09:32:50 -0400, Daniel Weinreb said:
But Fare pointed out to me that being able to add generic functions specialized on these would be a good thing. This would mean making them use CLOS not for encapsulation but for genericty.
Use can specialize methods on defstruct classes too, so they don't have to be CLOS instances defined with defclass.
Built-in classes too[1], which means that you can have methods specialized on (e.g.) single-float and double-float, fixnum and bignum, list and vector, etc.
Well, only if those types also happen to have a corresponding implementation-specific class. SINGLE-FLOAT, DOUBLE-FLOAT, FIXNUM, and BIGNUM are specified as types. LIST and VECTOR are system classes. FLOAT is also a system class. I recently ran into some accidentally unportable code that specialized a method argument on DOUBLE-FLOAT. It worked in SBCL but failed in CLISP because CLISP provides no DOUBLE-FLOAT class. Zach
On Jun 14, 2011, at 19:48 , Zach Beane wrote:
Raymond Wiker <rwiker@gmail.com> writes:
On Jun 14, 2011, at 19:30 , Martin Simmons wrote:
>> On Tue, 14 Jun 2011 09:32:50 -0400, Daniel Weinreb said:
But Fare pointed out to me that being able to add generic functions specialized on these would be a good thing. This would mean making them use CLOS not for encapsulation but for genericty.
Use can specialize methods on defstruct classes too, so they don't have to be CLOS instances defined with defclass.
Built-in classes too[1], which means that you can have methods specialized on (e.g.) single-float and double-float, fixnum and bignum, list and vector, etc.
Well, only if those types also happen to have a corresponding implementation-specific class. SINGLE-FLOAT, DOUBLE-FLOAT, FIXNUM, and BIGNUM are specified as types. LIST and VECTOR are system classes. FLOAT is also a system class.
I recently ran into some accidentally unportable code that specialized a method argument on DOUBLE-FLOAT. It worked in SBCL but failed in CLISP because CLISP provides no DOUBLE-FLOAT class.
You're right - looks like I should have spent a little time on looking things up (again) :-) CLTL2 lists (table 28-1, page 846) a number of predefined types with their class precedence lists. This table includes things like float, rational, integer and complex, but not things like single-float, double-float. Sooo, it *is* possible to specialize on built-in types, but not necessarily on *all* of them.
On 14 jun. 2011, at 19:48, Zach Beane <xach@xach.com> wrote:
I recently ran into some accidentally unportable code that specialized a method argument on DOUBLE-FLOAT. It worked in SBCL but failed in CLISP because CLISP provides no DOUBLE-FLOAT class.
Yes, I had the same thing once with specializing on SIMPLE-VECTOR in SBCL while it had to be a VECTOR in CLISP.
participants (6)
-
Daniel Weinreb -
Erik Winkels -
Martin Simmons -
Raymond Wiker -
Steve Haflich -
Zach Beane