Re: [pro] "fhash"

> * Daniel Weinreb [2011-06-30 18:12:02 -0400]: > > Just for the record, I think extensible sequences would be really great! Just for the record, CLISP has had extensible sequences since forever (far predating my involvement). See clisp/src/defseq.lisp which defines the standard sequences (vector

Re: [pro] "fhash"

On Wed, Jun 29, 2011 at 12:06 AM, Daniel Weinreb wrote: > Hi.   I read Christophe's paper on extensible sequences.  I don't think > this bears on my new package, though, for two reasons: > (1) it's only about sequences; maps don't fit into its framework. Yes, I was aware of that; I suggested the

Re: [pro] "fhash"

Please don't take this personal, but: Pessimism is infectious. It would be better if you would keep your pessimism for yourself. There is some amount of good enthusiasm still in this community, and it needs to be encouraged further, not discouraged! If there is enough interest and enthusiasm, t

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

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

Re: [pro] "fhash"

On Mon, Jun 13, 2011 at 12:18 PM, Daniel Weinreb wrote: > Here are pros and cons of changing it that I can see. > Pro: I's not a hash table in the small-cardinality case; it's a linear > lookup.  So the name is not actually accurate. Yes it is! It's a hash table with one bucket. But I prefer th

Re: [pro] "fhash"

Daniel Weinreb writes: > 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 elements. > > I did this beca

Re: [pro] "fhash"

FWIW, I'd call 'em maps. I think that would be more accurate and fit better with the rest of the programming culture in the large (whatever _that_ might be!). -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter

[pro] "fhash"

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 elements. I did this because performance analysis showed that ou