It's tough to say, because the ~ross link is broken. If a user-controlled value is forced, even if it's a container like Maybe or a tuple, then strict versions of the functions can be implemented user-side. Otherwise, it's orthogonal. Cheers, Edward Excerpts from Henning Thielemann's message of Sat May 21 13:37:10 -0400 2011:

On Sat, 21 May 2011, Edward Z. Yang wrote:

...

As it stands, we have strict functions for certain operations, such as insertWith. But this current selection is somewhat arbitrary. For illustrative purposes, here are other functions that ought to be strictified in IntMap, because there is no easy way for a user to implement them.

Is it possible to solve this with the proposed Location interface?

"Library proposal: add a Location interface for element-wise operations on Data.Map" http://www.haskell.org/pipermail/libraries/2011-January/015593.html

Excerpts from Milan Straka's message of Sun May 22 06:50:07 -0400 2011:

...

- the types Data.IntMap.IntMap, Data.IntMap.Lazy.IntMap and Data.IntMap.Strict.IntMap should be equal -- so I can use strict methods on IntMap someone else created with lazy methods. That is simple in absence of type classes.

Comment: This would mean you would get no static assurances against mixing up a strict IntMap with a lazy IntMap; for all intents and purposes, this is equivalent to implementing strict versions of all functions on top of a lazy data type.

Exactly. Do you think we should have different types for static and lazy maps? It feels odd to me to have these distinguished on type level. To me it is more about how you want to work with the structure, not the structure itself. But maybe others feel differently. Cheers, Milan

Unsure, ask again in a few days. Benefits for encoding at the data type level: 1. You'll never "forget" to add an appropriate `seq`, so the code looks essentially the same in the lazy and strict cases. 2. It's true that converting between lazy and strict maps can be something of a pain. However, I suspect that it is good discipline to know what strictness your map is (I may be wrong here.) Cheers, Edward

I'm warming up to the same underlying type approach. Unfortunately, it's not fully general (for example, you couldn't use this to manage lazy/strict bytestrings) but I could see this spreading to other libraries (e.g. transformers) Edward Excerpts from Edward Z. Yang's message of Sun May 22 07:04:20 -0400 2011:

Unsure, ask again in a few days.

Benefits for encoding at the data type level:

1. You'll never "forget" to add an appropriate `seq`, so the code looks essentially the same in the lazy and strict cases.

2. It's true that converting between lazy and strict maps can be something of a pain. However, I suspect that it is good discipline to know what strictness your map is (I may be wrong here.)

Cheers, Edward

On 22/05/2011 11:58, Milan Straka wrote:

...

Excerpts from Milan Straka's message of Sun May 22 06:50:07 -0400 2011:

...

- the types Data.IntMap.IntMap, Data.IntMap.Lazy.IntMap and Data.IntMap.Strict.IntMap should be equal -- so I can use strict methods on IntMap someone else created with lazy methods. That is simple in absence of type classes.

Comment: This would mean you would get no static assurances against mixing up a strict IntMap with a lazy IntMap; for all intents and purposes, this is equivalent to implementing strict versions of all functions on top of a lazy data type.

Exactly.

Do you think we should have different types for static and lazy maps? It feels odd to me to have these distinguished on type level. To me it is more about how you want to work with the structure, not the structure itself.

But maybe others feel differently.

I like your proposal. If the two were different types, I'm fairly sure we would end up needing strict operations on the lazy IntMap occasionally. Making the two types equivalent adds some useful flexibility at the expense of some static checking - it's a tradeoff, and reasonable people could differ on which they prefer, but I personally would rather have one IntMap with strict and lazy APIs. Cheers, Simon

On Mon, May 23, 2011 at 1:31 PM, Sebastian Fischer wrote:

I am also in favour of the "same type approach" because it seems it can help to avoid duplicating the implementations. Would it be efficient to define a type Data.IntMap.Strict.IntMap with strict fields (also for values) and then define Data.IntMap.Lazy in terms of this implementation and a wrapper type? data Lazy a = Lazy { getLazy :: a } newtype IntMap a = LazyIntMap { getLazyIntMap :: Data.IntMap.Strict (Lazy a) } lookup :: Int -> IntMap a -> Maybe a lookup n = fmap getLazy . Data.IntMap.Strict.lookup n . getLazyIntMap

Not really, it adds two words worth of overhead and one extra indirection. Johan

On 5/22/11 6:52 AM, Edward Z. Yang wrote:

Excerpts from Milan Straka's message of Sun May 22 06:50:07 -0400 2011:

...

- the types Data.IntMap.IntMap, Data.IntMap.Lazy.IntMap and Data.IntMap.Strict.IntMap should be equal -- so I can use strict methods on IntMap someone else created with lazy methods. That is simple in absence of type classes.

Comment: This would mean you would get no static assurances against mixing up a strict IntMap with a lazy IntMap; for all intents and purposes, this is equivalent to implementing strict versions of all functions on top of a lazy data type.

Not really for *all* intents and purposes. Separating them into different modules makes it very easy to make a top-level decision to import one or the other (or use qualified imports), which is a good deal cleaner than having primes scattered hither and yon. Personally I'm a fan of this approach, because it means we never have to convert between representations but we also clean up the API (as mentioned above). I'm less concerned about the possibility that someone might hand me a map containing thunks. Also, it allows for easily making partially strict IntMaps when you want to be lazy in general but know you must be strict for specific operations. Moreover, if you really want to make the type-level distinction, why not use newtypes? The conversion will be free in one direction, and the other direction can be done by just forcing all the elements in-place (instead of cloning the tree[1]). The only reason to actually duplicate the structure definition is if there's a whole lot of overhead for asking whether elements have already been evaluated. [1] And if you do end up having separate ADTs, then there should be explicit functions for casting from one to the other, so that you don't need to go via (fromAscList . toAscList) -- Live well, ~wren