On Wed, Mar 14, 2012 at 5:50 PM, wren ng thornton wrote:
> Do note, however, that in certain cases the ST approach can be much slower
> than the obvious immutable approach (i.e., the State monad--- especially
> when implemented directly via argument passing, rather than using the
> monadic interfa
On 3/11/12 11:52 PM, Ben Gamari wrote:
That being said, there are some cases where you really do want to be
able to utilize a mutable data structure inside of an otherwise pure
algorithm. This is precisely the use of the ST monad. ST serves to allow
the use of mutable state inside of a function w
On Sun, Mar 11, 2012 at 8:38 PM, E R wrote:
> A pure function can allocate and modify memory as long as a) it never
> returns a reference to the memory or b) it never again modifies the
> memory once it returns (i.e. it returns an immutable object).
>
That's a reasonable first approximation to t
There is a "trick" to `nub` where you couldn't implement the internal
lookup list with an (assumed faster) search tree anyway.
`nub` only mandates equality not ordering, so building a ordered
structure like a binary tree is impossible. In practice i would be
hard to beat list as the intermediate s
On Sun, Mar 11, 2012 at 8:38 PM, E R wrote:
> 1. leave it to the compiler to find these kinds of opportunities
> 2. just use the immutable data structures - after all they are just as
> good (at least asymptotically)
> 3. you don't want to use mutable data structures because of _
> 4. it does
I'm sure others will want to chime in here, but I'll offer my two cents.
On Sun, 11 Mar 2012 22:38:56 -0500, E R wrote:
snip
>
> So, again, what is the Haskell philosophy towards using mutable data
> structures in pure functions? Is it:
>
> 1. leave it to the compiler to find these kinds of opp
