Note the Steam classes you mention already have an analogue hiding in parsec 3 -- minus the null check that is.<div><br><div>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.</div>
<div><div><div><br></div><div>-Edward Kmett<br><br><div class="gmail_quote">On Fri, Aug 7, 2009 at 4:49 AM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com">johan.tibell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Alex,<br>
<br>
On Thu, Aug 6, 2009 at 9:15 AM, Alexander<br>
<div class="im">Dunlap<<a href="mailto:alexander.dunlap@gmail.com">alexander.dunlap@gmail.com</a>> wrote:<br>
</div><div class="im">> The way I see it, we have a few options. We could introduce some type<br>
> classes to cover the various container operations and ask all Platform<br>
> packages to only use operations from these classes, where applicable.<br>
> (The ListLike library would probably be a good place to start.) The<br>
> issue here is efficiency, massive class dictionaries, and type system<br>
> issues (we need MPTCs or TFs; also, since not all sequence types are<br>
> polymorphic, we probably need to have separate map and rigidMap<br>
> functions like in ListLike, and even that doesn't work for types like<br>
> uvector that can take some, but not all, concrete element types).<br>
<br>
</div>I don't like the *Like naming much. I think that the type class<br>
deserves the shorter name and concrete instantiations should use more<br>
specialized names. Sequence wouldn't be a too bad name for data types<br>
that support indexing. Stream would be a good name for types that<br>
don't. There's an issue with regards to monads though. What type<br>
classes do we use for a Stream backed by e.g. an I/O resource? Example<br>
using a concrete element type:<br>
<br>
class ByteStream s where<br>
uncons :: s -> (Word8, s)<br>
null :: s -> Bool<br>
<br>
class ByteStreamM s where<br>
uncons :: Monad m => s -> m (Word8, s)<br>
null :: Monad m => s -> m Bool<br>
<br>
Do we need two type classes for each "concept" (e.g. stream, sequence)?<br>
<div class="im"><br>
> We could also implement a standard module-naming scheme: for every<br>
> package that operates on strings, for instance, we could require the<br>
> list-based code to go in Foo.Bar.String and the Text code to go in<br>
> Foo.Bar.Text. Whenever we "blessed" a new string datatype (presumably<br>
> not very often), all packages would have to add a new module. The<br>
> issue is code duplication.<br>
<br>
</div>I would like to propose this as a general recommendation for module<br>
naming as there's already plenty of modules that do it this way. It<br>
also seems to be the most sensible place to put the data type as it<br>
groups related modules in the module hierarchy and thus in the<br>
documentation. I don't know about requiring all packages to add a new<br>
module every time there's a new type though.<br>
<div class="im"><br>
><br>
> We could also implement a package naming scheme: have foo-text and<br>
> foo-string for the two different datatypes.<br>
<br>
</div>This seems like a good scheme to me. It's the same<br>
<general>-<specific> scheme that's proposed for modules above.<br>
<div class="im"><br>
><br>
> What does everyone think about the need for standardization here and<br>
> how we ought to do it? I'm sorry that, having less experience with<br>
> Haskell than many, I can't give as much in the way of concrete<br>
> proposals, but I think it's important that we hash something out here<br>
> to get more organization in our Platform.<br>
<br>
</div>I definitely think the container problem needs to be tackled. However,<br>
I don't know what the solution should look like.<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Johan<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div></div></div></div>