[MLton-user] Re: RFC: Extended Basis Library

[Geoffrey Alan Washburn]

Vesa Karvonen wrote:

>> I've been thinking that it would make sense to develop a signature
>> »SORTABLE« in »public/sequence«.
>
> A good place for such concept signatures might be 
> public/sequence/concept.
> (Hmm... Maybe we should abbreviate sequence to seq.)  I think that at
> least two separate concept signatures are needed: SORTABLE_IN_PLACE and
> SORTABLE.  IOW, One for mutable sequences that can (and perhaps 
> should) be
> sorted in-place (e.g. arrays) and another for immutable sequences that 
> can
> not (e.g. vectors, strings, lists, ...).

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). 

> I think that many Haskell libraries provide their own symbol in addition
> to mplus.  For example, Parsec uses <|> and, IIRC, STM uses orElse.  
> Using
> ++ with a precedence lower than the precedence of >> and >>= might be
> sufficiently convenient for many libraries. 
  
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?

> Ok.  Couldn't you instead just have
>
>  fun fail exn = fn _ => raise exn
>
> with the spec
>
>  val fail : exn -> 'a -> 'b
>
> and then write, regardless of the underlying monad,
>
>  some computation >>= fail exn
>                   ^^^
>                  not >>
>
> where fail gets a type of the form
>
>  exn -> 'a -> 'b monad .
>
> Actually, the Extended Basis provides the function raising
>
>  http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/extended-basis/unstable/public/basic.sig?view=auto 
>
>
> which is equivalent to the above fail function
>
> So, with raising, you should already be able to just write
>
>  some computation >>= raising exn
>
> without having to extend any of the MONAD* signatures.

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.

>>    (* Like "o" but for monadic functions *)
>>    val oo : ('b -> 'c monad) * ('a -> 'b monad) -> ('a -> 'c monad)
>
> The idea looks good.  Do you use both oo and o in the same scope a lot?
> If not, then I think that it might be better to just use the same symbol
> for both.  This way one can "reuse" the fixity declaration.
> Alternatively, the Extended Basis currently provides the infix operator
> <--> with the same fixity as o.  The <--> symbol is (currently) used for
> isomorphism and embedding composition.  I'm not sure whether it would be
> better to just use o for those as well.
I do indeed use them in the same scope.  I did some grepping and I even 
use them in the same line

        ...
        mapM ((getKdInfo oo getKdTypPat) o Pair.snd) newstps
        ...

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.

> Anyway, the type/idea of lift looks good, but I wonder about the name. In
> Haskell (http://members.chello.nl/hjgtuyl/tourdemonad.html#liftM), the
> name lift is used for functions having a type of the form
>
>  ('a1 -> ... -> 'aN -> 'r) -> 'a1 monad -> ... -> 'aN monad -> 'r monad

    Hmmm.  Again, I'm not sure what to suggest.  »hoist«?

>>    (* Turn a "pure" thunk into a computation *)
>>    val thunk : 'a Thunk.t -> 'a monad
>
> Hmm... Does this mean that type constructor monad is always of the
> following form?
>
>  type 'a monad = 'a monad_dom -> 'a monad_cod
>
> I'm not sure that it makes sense to restrict the MONAD concept signatures
> to such monads only.  This should probably go into a separate concept
> signature.
    No, this is applicable to all monads.  It is just shorthand where

       thunk f == (return () >>= (return o f))

> Also, I don't particularly like the Haskell naming conventions.  Note 
> that
> the name map is already used in FUNC.  Here is what I propose.  Use the
> name seq when you want to obtain the list of results and the name app 
> when
> you aren't interested in the results.  Use the suffix With when you 
> want to
> map over the list of monads.  These conventions would give us:
>
>  val seq  : 'a monad_ex List.t -> 'a List.t monad_ex
>  val seqWith : ('a -> 'b monad_ex) -> 'a List.t -> 'b List.t monad_ex
>  val app : 'a monad_ex List.t -> Unit.t monad_ex
>  val appWith : ('a -> 'b monad_ex) -> 'a List.t -> Unit.t monad_ex
>
> or possibly
>
>  val app : Unit.t monad_ex List.t -> Unit.t monad_ex
>  val appWith : ('a -> Unit.t monad_ex) -> 'a List.t -> Unit.t monad_ex

    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.


> Hmm... I like the Zip : ZIP name.  Yes, I think that Zip : ZIP would be
> better than ListTriple.  Stephen Weeks and I wrote several variations of
> such a module (named ListProduct or SeqProduct) a while back and you can
> find those on the MLton list. 

    I found an instance of ListProduct in the archives.  I'll look into 
revising/polishing it to put into the extended basis as Zip. 


-- 
[Geoff Washburn|geoffw at cis.upenn.edu|http://www.cis.upenn.edu/~geoffw/]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20070311/988481b6/attachment.html