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'. 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. > > >> >> >> And Data.HashTable also use some mutable array thing so it is still not >> >> >> the idiomatic Haskell of everything is immutable. >> >> >> > afaict idiomatic is everything referentially transparent not >> >> > everything immutable, as in - "I needed a halfway decent mutable >> >> > collection type – having a properly tested mutable collection that >> >> > actually performs well would be a godsend." >> >> >> how can you assure that(let's put aside the under the hood things >> >> where it is done in C) if you break the assumption that value can be >> >> changed. >> >> > Reading the first paragraph "Introduction to Uniqueness Typing" of >> > this paper should help you with that question - >> >> >http://www.st.cs.ru.nl/papers/2008/vrie08-IFL07-UniquenessTypingSimpl... >> >> Would try to digest that. > > 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. -- 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
