I’d love to read a blog post about your library, especially where you exploit the flexibility of explicit memoizers.

Oh! Now I see that you have written. I’d still like to see some nice examples if you get around to it.

Any thoughts on this dilemma?

Well, there’s not much point memoizing a constant function. Also, a strict instance for () is more consistent with the other instances.

[...] I don’t think the typeclass approach to memoization is a good one. Here you are limited to one memo trie per type. But there are many ways to memoize a given type!

Yep. A problem with typeclasses in general. Even more generally, a problem with hiding implementation mechanism. Prettier but less flexible. I gather you’ve found the flexibility particularly useful with memoization.

data-memocombinators, which I just released on hackage two days ago [...]

Sounds awfully cool. I’d love to read a blog post about your library, especially where you exploit the flexibility of explicit memoizers.

Yow! It sure does.

this one is not essential, but rather a bug, I think.

Oh, I see the problem:

> let f () = 42
> (\ () -> 42) undefined 
*** Exception: Prelude.undefined
> (const 42) undefined 
42

Hmm. I can fix the f case by changing the nonstrict const a to the strict \ () -> a in the definition of untrie (UnitTrie a). But then I run into the dual problem:

> let g = const 42 :: () -> Int
> g undefined
42
> memo g undefined
*** Exception: Prelude.undefined

Any thoughts on this dilemma?

    take 5 (repeat True)        = [True,True,True,True,True]
    memo (take 5) (repeat True) = ⊥
    
    -- this one is not essential, but rather a bug, I think.
    let f () = 42
    f ⊥      = ⊥
    memo f ⊥ = 42

I am not quite sure in what essential way the strictness is changed. For example, it is theoretically possible to memoize a function of infinite streams, given that the return type is compact, so it’s not just that it makes it fully strict in its argument’s domain. I haven’t gotten around to implementing this awesome possibility just yet

(1) So far, I don’t believe associated types are necessary. HasMemo should be implementable with the simple interface:

class HasMemo a where
    memo :: (a -> r) -> (a -> r)

All the compositions you have used, and every other composition I have been able to think of, are implementable with this structure.

(2) This one is more subjective, but I don’t think the typeclass approach to memoization is a good one. Here you are limited to one memo trie per type. But there are many ways to memoize a given type! Indeed, you could use newtypes, but that’s clunky and a lot of work. data-memocombinators, which I just released on hackage two days ago (uh… are you and I the same person? , exposes memoizers as first-class functions so that they can be custom built; i.e. so you can memoize only integers less than 1,000,000 (the best way to solve one of the Euler problems), or only memoize the Left side of an Either (let’s say the right doesn’t have a trie), etc.

I think competition on Hackage will be nice, to see which approach ends up being more useful. The two approaches can be trivially combined by picking a default memoizer for each type. I wonder if there is a deeper, more flexible way to combine them.