Containers in the Haskell Platform

[Edward Kmett]

Note the Steam classes you mention already have an analogue hiding in parsec
3 -- minus the null check that is.
Since, there, unconsing returns m (Maybe (c,s)). rather than m (c,s),
permitting the check and uncons to be performed in the same operation, but
denying access to them separately.

-Edward Kmett

On Fri, Aug 7, 2009 at 4:49 AM, Johan Tibell <johan.tibell at gmail.com> wrote:

> Hi Alex,
>
> On Thu, Aug 6, 2009 at 9:15 AM, Alexander
> Dunlap<alexander.dunlap at gmail.com> wrote:
> > The way I see it, we have a few options. We could introduce some type
> > classes to cover the various container operations and ask all Platform
> > packages to only use operations from these classes, where applicable.
> > (The ListLike library would probably be a good place to start.) The
> > issue here is efficiency, massive class dictionaries, and type system
> > issues (we need MPTCs or TFs; also, since not all sequence types are
> > polymorphic, we probably need to have separate map and rigidMap
> > functions like in ListLike, and even that doesn't work for types like
> > uvector that can take some, but not all, concrete element types).
>
> I don't like the *Like naming much. I think that the type class
> deserves the shorter name and concrete instantiations should use more
> specialized names. Sequence wouldn't be a too bad name for data types
> that support indexing. Stream would be a good name for types that
> don't. There's an issue with regards to monads though. What type
> classes do we use for a Stream backed by e.g. an I/O resource? Example
> using a concrete element type:
>
> class ByteStream s where
>    uncons :: s -> (Word8, s)
>    null :: s -> Bool
>
> class ByteStreamM s where
>    uncons :: Monad m => s -> m (Word8, s)
>    null :: Monad m => s -> m Bool
>
> Do we need two type classes for each "concept" (e.g. stream, sequence)?
>
> > We could also implement a standard module-naming scheme: for every
> > package that operates on strings, for instance, we could require the
> > list-based code to go in Foo.Bar.String and the Text code to go in
> > Foo.Bar.Text. Whenever we "blessed" a new string datatype (presumably
> > not very often), all packages would have to add a new module. The
> > issue is code duplication.
>
> I would like to propose this as a general recommendation for module
> naming as there's already plenty of modules that do it this way. It
> also seems to be the most sensible place to put the data type as it
> groups related modules in the module hierarchy and thus in the
> documentation. I don't know about requiring all packages to add a new
> module every time there's a new type though.
>
> >
> > We could also implement a package naming scheme: have foo-text and
> > foo-string for the two different datatypes.
>
> This seems like a good scheme to me. It's the same
> <general>-<specific> scheme that's proposed for modules above.
>
> >
> > What does everyone think about the need for standardization here and
> > how we ought to do it? I'm sorry that, having less experience with
> > Haskell than many, I can't give as much in the way of concrete
> > proposals, but I think it's important that we hash something out here
> > to get more organization in our Platform.
>
> I definitely think the container problem needs to be tackled. However,
> I don't know what the solution should look like.
>
> Cheers,
>
> Johan
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090807/72a3fb9f/attachment.html