<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffee" text="#000000">
Vesa Karvonen wrote:<br>
<br>
<blockquote
cite="mid:9e43b9a0703040515t794edcbep6dce1f323d2dd7a1@mail.gmail.com"
type="cite">
<blockquote type="cite">I've been thinking that it would make sense
to develop a signature
<br>
»SORTABLE« in »public/sequence«.
<br>
</blockquote>
<br>
A good place for such concept signatures might be
public/sequence/concept.
<br>
(Hmm... Maybe we should abbreviate sequence to seq.) I think that at
<br>
least two separate concept signatures are needed: SORTABLE_IN_PLACE and
<br>
SORTABLE. IOW, One for mutable sequences that can (and perhaps should)
be
<br>
sorted in-place (e.g. arrays) and another for immutable sequences that
can
<br>
not (e.g. vectors, strings, lists, ...).
<br>
</blockquote>
<br>
Okay, I'll look into preparing a proposal for these. I already put
together some common signatures for sequences (SEQUENCE_CORE,
SEQUENCE_FINITE, SEQUENCE_INFINITE). <br>
<br>
<blockquote
cite="mid:9e43b9a0703040515t794edcbep6dce1f323d2dd7a1@mail.gmail.com"
type="cite">I think that many Haskell libraries provide their own
symbol in addition
<br>
to mplus. For example, Parsec uses <|> and, IIRC, STM uses
orElse. Using
<br>
++ with a precedence lower than the precedence of >> and
>>= might be
<br>
sufficiently convenient for many libraries.
</blockquote>
<br>
Okay, though I am not sure what the conclusion of this was. Did we want
to rename plus in the MONADP signature to ++ or should it just be an
alias?<br>
<br>
<blockquote
cite="mid:9e43b9a0703040515t794edcbep6dce1f323d2dd7a1@mail.gmail.com"
type="cite">Ok. Couldn't you instead just have
<br>
<br>
fun fail exn = fn _ => raise exn
<br>
<br>
with the spec
<br>
<br>
val fail : exn -> 'a -> 'b
<br>
<br>
and then write, regardless of the underlying monad,
<br>
<br>
some computation >>= fail exn
<br>
^^^
<br>
not >>
<br>
<br>
where fail gets a type of the form
<br>
<br>
exn -> 'a -> 'b monad .
<br>
<br>
Actually, the Extended Basis provides the function raising
<br>
<br>
<a class="moz-txt-link-freetext" href="http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/extended-basis/unstable/public/basic.sig?view=auto">http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/extended-basis/unstable/public/basic.sig?view=auto</a>
<br>
<br>
which is equivalent to the above fail function
<br>
<br>
So, with raising, you should already be able to just write
<br>
<br>
some computation >>= raising exn
<br>
<br>
without having to extend any of the MONAD* signatures.
<br>
</blockquote>
<br>
Fair enough. I'm still thinking about the question of whether zero
should be able to take an error parameter. Right now I'm thinking that
at least for my purposes it may be sufficient to just add an additional
»set error« function to my state monad.<br>
<br>
<blockquote
cite="mid:9e43b9a0703040515t794edcbep6dce1f323d2dd7a1@mail.gmail.com"
type="cite">
<blockquote type="cite"> (* Like "o" but for monadic functions *)
<br>
val oo : ('b -> 'c monad) * ('a -> 'b monad) -> ('a ->
'c monad)
<br>
</blockquote>
<br>
The idea looks good. Do you use both oo and o in the same scope a lot?
<br>
If not, then I think that it might be better to just use the same
symbol
<br>
for both. This way one can "reuse" the fixity declaration.
<br>
Alternatively, the Extended Basis currently provides the infix operator
<br>
<--> with the same fixity as o. The <--> symbol is
(currently) used for
<br>
isomorphism and embedding composition. I'm not sure whether it would
be
<br>
better to just use o for those as well.
<br>
</blockquote>
I do indeed use them in the same scope. I did some grepping and I even
use them in the same line<br>
<br>
...<br>
mapM ((getKdInfo oo getKdTypPat) o Pair.snd) newstps<br>
...<br>
<br>
though this may just be bad style. Naming it »oo« is not particularly
satisfying, but »<-->« would probably be non-obvious to
decipher. I'm not sure what to suggest.<br>
<br>
<blockquote
cite="mid:9e43b9a0703040515t794edcbep6dce1f323d2dd7a1@mail.gmail.com"
type="cite">Anyway, the type/idea of lift looks good, but I wonder
about the name. In
<br>
Haskell (<a class="moz-txt-link-freetext" href="http://members.chello.nl/hjgtuyl/tourdemonad.html#liftM">http://members.chello.nl/hjgtuyl/tourdemonad.html#liftM</a>), the
<br>
name lift is used for functions having a type of the form
<br>
<br>
('a1 -> ... -> 'aN -> 'r) -> 'a1 monad -> ... -> 'aN
monad -> 'r monad
<br>
</blockquote>
<br>
Hmmm. Again, I'm not sure what to suggest. »hoist«? <br>
<br>
<blockquote
cite="mid:9e43b9a0703040515t794edcbep6dce1f323d2dd7a1@mail.gmail.com"
type="cite">
<blockquote type="cite"> (* Turn a "pure" thunk into a computation
*)
<br>
val thunk : 'a Thunk.t -> 'a monad
<br>
</blockquote>
<br>
Hmm... Does this mean that type constructor monad is always of the
<br>
following form?
<br>
<br>
type 'a monad = 'a monad_dom -> 'a monad_cod
<br>
<br>
I'm not sure that it makes sense to restrict the MONAD concept
signatures
<br>
to such monads only. This should probably go into a separate concept
<br>
signature.
<br>
</blockquote>
No, this is applicable to all monads. It is just shorthand where<br>
<br>
thunk f == (return () >>= (return o f))<br>
<br>
<blockquote
cite="mid:9e43b9a0703040515t794edcbep6dce1f323d2dd7a1@mail.gmail.com"
type="cite">Also, I don't particularly like the Haskell naming
conventions. Note that
<br>
the name map is already used in FUNC. Here is what I propose. Use the
<br>
name seq when you want to obtain the list of results and the name app
when
<br>
you aren't interested in the results. Use the suffix With when you
want to
<br>
map over the list of monads. These conventions would give us:
<br>
<br>
val seq : 'a monad_ex List.t -> 'a List.t monad_ex
<br>
val seqWith : ('a -> 'b monad_ex) -> 'a List.t -> 'b List.t
monad_ex
<br>
val app : 'a monad_ex List.t -> Unit.t monad_ex
<br>
val appWith : ('a -> 'b monad_ex) -> 'a List.t -> Unit.t
monad_ex
<br>
<br>
or possibly
<br>
<br>
val app : Unit.t monad_ex List.t -> Unit.t monad_ex
<br>
val appWith : ('a -> Unit.t monad_ex) -> 'a List.t -> Unit.t
monad_ex
<br>
</blockquote>
<br>
I chose to go with the former as it is useful to have the more
general types in some cases. The extra static checking of the latter
might be nice, but I'm not sure it is worth having two sets of
functions for it.<br>
<br>
<br>
<blockquote
cite="mid:9e43b9a0703040515t794edcbep6dce1f323d2dd7a1@mail.gmail.com"
type="cite">Hmm... I like the Zip : ZIP name. Yes, I think that Zip :
ZIP would be
<br>
better than ListTriple. Stephen Weeks and I wrote several variations
of
<br>
such a module (named ListProduct or SeqProduct) a while back and you
can
<br>
find those on the MLton list.
</blockquote>
<br>
I found an instance of ListProduct in the archives. I'll look into
revising/polishing it to put into the extended basis as Zip. <br>
<br>
<br>
<pre class="moz-signature" cols="72">--
[Geoff Washburn|<a class="moz-txt-link-abbreviated" href="mailto:geoffw@cis.upenn.edu">geoffw@cis.upenn.edu</a>|<a class="moz-txt-link-freetext" href="http://www.cis.upenn.edu/~geoffw/">http://www.cis.upenn.edu/~geoffw/</a>]
</pre>
</body>
</html>