On Sep 10, 10:35 am, gary ng <garyng2...@gmail.com> wrote: > On Fri, Sep 10, 2010 at 8:49 AM, Isaac Gouy <igo...@yahoo.com> wrote: > >> Huh ? point ? it was just a casual comment, no point was intended. And > >> I have read some comments by Don that what is in the shoutout is way > >> faster than Data.HashTable > > > If you knew there was another option why write "I doubt there is any > > choice for Haskell" ? > > That was referring to the original comment about 'making a mutable > implementation' meaning the program itself ASKED for that particular > functionality. The one in the shoutout is one implementation of it, > the one in Data.HashTable is another. When I said no choice, I was > saying no choice but to implement a mutable hash table, in respond to > the underlying message of 'why did they implement a mutable hashtable' > as if making it mutable is only for performance purpose.
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. > >> >> 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'm not going to speculate about what unnamed "verteran Haskellers" > > have or have not said. > > > Read the bug report and you'll see that the root problem was GC - do > > you think changing GC is a quick fix? > > Don suggested on reddit for some fixes that tackle the GC issue(not > changing the GC, but the way to get around the performance caused by > GC), using similar approach as in the shoutout. -- 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
