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

[Vesa Karvonen]

I posted my answer back to the list.  I hope you don't mind.

Thanks for reporting the conflict with smlnj-lib.  I hadn't encountered it
as I mainly develop using MLton.  (Hint: It would be good to have someone
developing mainly on SML/NJ to help maintain the library.)  I also haven't
played with SML/NJ's bootstrapping process so I can't help with that
offhand.

One simple way around the IntInf conflict might be to create a CM wrapper
around smlnj-lib that simply does not export IntInf (assuming that you
want to use the extended basis version of IntInf).  Given

  (* my-smlnj-lib.cm *)
  library
    library($/smlnj-lib.cm) - signature INT_INF - structure IntInf
  is
    $/smlnj-lib.cm

and

  (* both.cm *)
  group
    library(my-smlnj-lib.cm)
    library([path-to]/mltonlib/com/ssh/extended-basis/unstable/basis.cm)
  is
    my-smlnj-lib.cm
    [path-to]/mltonlib/com/ssh/extended-basis/unstable/basis.cm

then

   CM.make "both.cm" ;

executes without errors.

As soon as I have the time, the next major thing I'd like to do to the
extended basis library is to change it to use combinable signatures as
described in the following post:

  http://mlton.org/pipermail/mlton/2006-December/029469.html

This also means changes to the implementation.

I also plan to incorporate a number of ideas from Stephen's Basic library:

  http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/sweeks/basic/unstable
  http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/sweeks/basic/unstable/README?view=auto

Also on my list is to add/move unit tests to the library (see
  http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/misc-util/unstable/unit-test.sml?view=markup
  http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/misc-util/unstable/qc-test-example.sml?view=markup
  http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/misc-util/unstable/promise-test.sml?view=markup
and other tests in the misc-util lib).

The design of the extended basis library is open for improvements.  Don't
hesitate to communicate about things that you don't like/understand in it.

-Vesa Karvonen

Quoting Geoffrey Alan Washburn <geoffw at cis.upenn.edu>:
> Vesa Karvonen wrote:
> > Some specific questions:
> > - Did you have trouble understanding the library or how to use it?
> > - Do you think that the library is/will be useful?
> 
> 	I hope so.
> 
> > - Did you try to compile your project with the library?  Any problems?
> 
> 	Hi, I just gave it a quick try with my project built around SML/NJ and 
> the extended basis seems to compile okay, but it introduces a number of 
> conflicts with respect to smlnj-lib, as compiled by SML/NJ.  For 
> example, both provide IntInf.  Even if I comment that out, some 
> additional problems arise because the precompiled smlnj-lib still refers 
> to the original implementations.  However, if I made some changes to 
> smlnj-lib and rebuilt it separately that would probably resolve the 
> problem.
> 
> 	Still, I would prefer to minimize local changes to the extended basis 
> or smlnj-lib that I would have to maintain.  Do you have any experience 
> as how to best go about making SML/NJ, the extended basis, and smlnj-lib 
> to work together with minimal changes?  I am already maintaining my own 
> local SML/NJ branch, so if you can recommend a way to integrate the 
> extended basis into its bootstrap process I could give that a try.
> 
> > - Would you like contribute something to the library?
> 
> 	Perhaps.  I have a number of smallish things I've been accumulating 
> myself that may be worth including once I do a more detailed study of 
> what the extended basis provides over the standard basis.