[MLton] bug in MLton and bug in basis

[Wesley W. Terpstra]

On Aug 19, 2005, at 5:38 PM, Stephen Weeks wrote:
>>> -      val getERROR = getSockOptBool (Prim.Ctl.SOCKET,  
>>> Prim.Ctl.ERROR)
>>> +      fun getERROR s =
>>> +         getSockOptInt (Prim.Ctl.SOCKET, Prim.Ctl.ERROR) s
>>> +         handle Error.SysErr (_, e) =>
>>> +            case e of
>>> +               NONE => raise Fail "Socket.Ctl.getERROR"
>>> +             | SOME s => s
>>>
>>
>> ... won't work. SysErr ("Connection Refused", NONE) for example.
>>
>> You should do like I said earlier: return SysErr option...
>>
>> fun getERROR s =
>>      case getSockOptInt (Prim.Ctl.SOCKET, Prim.Ctl.ERROR) s of
>>          0 => NONE
>>      |   x => SOME (MakeASysErrUsingStrerror x)
>>       handle ex => SOME ex
>
> I'm a bit confused what you mean by "SysErr" as a type.  I think that
> returning "exn option", as your code suggests, is not as precise as it
> could be.

I meant this: http://mlton.org/basis/os.html#SIG:OS.SysErr:EXN
But, I forgot that an exception, unlike a datatype, is of one common  
type.
My newness to SML shining through again. ;-)

My C++ background makes me very suspicious of exceptions, and
I have avoided using them in all the stuff I've written so far.

> However, your point that one might see Error.SysErr (...,
> NONE) argues that returning "Posix.Error.syserror option" is not right
> either.

I did not mean to propose this.

>   I guess that returning an option of the argument type of the
> SysErr exception is the right thing.  That is,
>
>   (string * Posix.Error.syserror option) option

That seems best.

It's more or less what I meant, I just thought (wrongly) that SysErr the
constructor could somehow be used as a type. I was confused.

> Here's a patch that does this.

Looks fine to me.
Thanks!