[MLton-user] Re: MLton-user Digest, Vol 7, Issue 2

[John Reppy]

This problem is an artifact of the old days when SML/NJ did have
IntInf in its Basis implementation.  I was surprised to see that
it was still in the SML/NJ library and we'll remove it for the
next release (110.63).

	- John

On Feb 15, 2007, at 2:00 PM, mlton-user-request at mlton.org wrote:

> Send MLton-user mailing list submissions to
> 	mlton-user at mlton.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mlton.org/mailman/listinfo/mlton-user
> or, via email, send a message with subject or body 'help' to
> 	mlton-user-request at mlton.org
>
> You can reach the person managing the list at
> 	mlton-user-owner at mlton.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MLton-user digest..."
>
>
> Today's Topics:
>
>    1. Re: RFC: Extended Basis Library (Vesa Karvonen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 15 Feb 2007 17:48:12 +0200
> From: Vesa Karvonen <vesa.karvonen at cs.helsinki.fi>
> Subject: [MLton-user] Re: RFC: Extended Basis Library
> To: Geoffrey Alan Washburn <geoffw at cis.upenn.edu>
> Cc: mlton-user at mlton.org
> Message-ID: <1171554492.45d480bc2e7b1 at www3.helsinki.fi>
> Content-Type: text/plain; charset=us-ascii
>
> 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.
>
>
>
> ------------------------------
>
> _______________________________________________
> MLton-user mailing list
> MLton-user at mlton.org
> http://mlton.org/mailman/listinfo/mlton-user
>
> End of MLton-user Digest, Vol 7, Issue 2
> ****************************************
>