On Sep 10, 11:54 am, gary ng <garyng2...@gmail.com> wrote: > On Fri, Sep 10, 2010 at 11:13 AM, Isaac Gouy <igo...@yahoo.com> wrote: > > Clearly, they did choose "to write all that code" "in order to get a > > much faster program" - I can't tell you if Andy had noticed the > > benchmark was about "Hashtable update and k-nucleotide strings" or > > whether he knew about Data.HashTable. > > I know they did it to get a faster program, but under the requirement of : > > IT MUST BE MUTABLE HASHTABLE > > If you change the requirement to something else that acheives the end > result without this specific requirement, they may not use hashtable > at all. Which is also the message I get from various place like reddit > or stackoverlow about this same issue. That is 'use your language's > strength to solve the problem, not to mimic other language, i.e. the > what not the how'.
It's starting to look like actually there was a point you wanted to make ;-) If you change the requirement to something else you'd simply be missing the point - which was to look at hashtable updates and strings. Does it actually say that the hashtable updates have to be destructive? > And this sentiment is not unique to Haskell. I recently saw similar > questions on J language of 'how can I write a Haskell style > filter(HOF)', the overall answers there are 'you don't need haskell > style filter and can achieve the same result in a J way'. Similarly > for Haskell which is 'you don't need to use mutable hash table and can > very likely get the same result using other immutable data structure' > > But in this case the problem is 'implement a mutable hashtable' which > is what my 'no choice' was referring to. Unlike language say Python or > F# where hash table is in general considered to be part of the > language, Data.HashTable is not. It is just one 'sample' of > implementation of mutable hash table which happens to be slow. There's no choice in binary-trees either - you must use binary-trees and you must allocate all the memory. There's no choice in pi-digits either - you must use that particular step-by-step spigot algorithm taken from that Haskell paper. There's no choice in fannkuch-redux either - you must use that particular ordering of permutations taken from that Lisp paper. etc etc Forgive me but you do seem to be belabouring the obvious. -snip- > > Bite-sized: > > > "An important property of pure functional programming languages is > > referential transparency: the same expression used twice must have the > > same value twice." > > > "A side effect on a variable (file) is okay as long as that variable > > is never used again: it is okay for a function to modify its input if > > the input is not shared. Referential transparency then trivially holds > > because the same expression never occurs more than once." > > > "Rather than just returning the read character, fgetc returns a pair > > consisting of the read character and a new file, file1. Although file0 > > and file1 point to the same file on disk, they are conceptually and > > syntactically different, and thus it is clear that a and b may have > > different values." > > I read this part, trying to fit that into this mutable hashtable > context. Below this paragraph, it mentioned some > requirement/assumption that file0, file1 ... cannot be 're-used' which > I don't know how to apply to hashtable. Do you know if we re-write that as - Rather than just returning the updated value, htAddOrUpdate returns a pair consisting of the updated value and a new hashtable, hashtable1. Although hashtable0 and hashtable1 point to the same structures in memory, they are conceptually and syntactically different, and thus it is clear that a and b may have different values. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
