2009/12/12 Luke Palmer <lrpal...@gmail.com>: > On Fri, Dec 11, 2009 at 7:07 PM, Jason Dusek <jason.du...@gmail.com> wrote: > > Where do we draw the line between "machinery" and "packages"? > > The types don't tell us what libraries we need. > > ...you might mean what *haskell* libraries does a piece of > code depend on?
Yes, that's what I mean. > To address that, note that I consider a statement like: > > import Control.Monad.State > > As a form of impurity in a sense... It's not referentially transparent, that's for sure. > I have brainstormed solutions to this problem while thinking about my > (currently on hold or dead) Udon project... I remember reading about that. As regards the object identity problem, say we just talk about uniquely naming bytestrings. Well, different bytestrings are different so they are "their own name"; if we don't want to compare them via substring matching, though, then we need a consensus algorithm to name them identically across nodes on the WAN. I wonder if a solipsistic internal namespace is not a workable solution? My repo knows objects (patches) I created as having unqualified names; objects from your computer are labelled as "Luke's repo/..." and vice versa. The repo can be garbage collected for patches that are actually the same by background string equality checks. As someone -- I think it was you? -- suggested on the list a little while ago, the chance of hash collision is not zero. -- Jason Dusek _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe