Re: [pro] "fhash"

On 14 jun. 2011, at 19:48, Zach Beane 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

Re: [pro] "fhash"

On Jun 14, 2011, at 19:48 , Zach Beane wrote: > Raymond Wiker 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 t

Re: [pro] "fhash"

Raymond Wiker 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 us

Re: [pro] "fhash"

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 encapsulatio

Re: [pro] "fhash"

> 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 defst

[pro] Fwd: "fhash"

[Daniel, excuse me for the double post] -- Forwarded message -- From: Ala'a Mohammad Date: Tue, Jun 14, 2011 at 11:29 AM Subject: Re: [pro] "fhash" To: Daniel Weinreb On Mon, Jun 13, 2011 at 11:18 PM, Daniel Weinreb wrote: >... > I have recently been cleaning this up, one reas

Re: [pro] "fhash"

On Tue, Jun 14, 2011 at 3:38 PM, Daniel Weinreb wrote: > Could you tell me where to find that?  Thanks. -- Dan The paper - titled "User-extensible sequences in Common Lisp" by C. Rhodes - can be found for example here:

Re: [pro] "fhash"

Could you tell me where to find that? Thanks. -- Dan On Tue, Jun 14, 2011 at 3:50 AM, Alessio Stalla wrote: > On Tue, Jun 14, 2011 at 9:37 AM, Marco Antoniotti > wrote: > > > > On Jun 13, 2011, at 21:18 , Daniel Weinreb wrote: > > > >> Friends, > >> > >> I wrote a little package for "fash hash

Re: [pro] "fhash"

Thank you for letting me know about this. One of the things I feel strongly about, though, is avoiding names like dictionary-get. Fhash's package is the kind where you're not supposed to do a "use". You're supposed to get at the external symbols by using explicit package prefixes, so the diction

Re: [pro] "fhash"

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 inst

Re: [pro] "fhash"

On Tue, Jun 14, 2011 at 9:37 AM, Marco Antoniotti wrote: > > On Jun 13, 2011, at 21:18 , Daniel Weinreb wrote: > >> Friends, >> >> I wrote a little package for "fash hash tables", which provide an >> abstraction that is analogous to that of Common Lisp hash tables, but >> is faster for tables with

Re: [pro] "fhash"

On Jun 13, 2011, at 21:18 , Daniel Weinreb wrote: > Friends, > > I wrote a little package for "fash hash tables", which provide an > abstraction that is analogous to that of Common Lisp hash tables, but > is faster for tables with few elements, and only slightly inferior for > tables with many e

Re: [pro] "fhash"

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 provi