[MLton] Error Messages for Missing Sharing/Where Type

[Steven Melendez]

------=_Part_32256_13736008.1151694193780
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

As Matthew Fluet mentioned in introducing me to the list, I'm an
undergraduate student looking at improving error messages for MLton.
Specifically, I was hoping to give "suggestions" for missing sharing
constraints or "where type.." declarations. To do this, it seems like it
would be necessary to know either in TypeEnv.Type.conAnd or at the time of
the various calls to unify in elaborate-core.fun whether particular type
constructors are flexible or rigid.

Unfortunately, it doesn't seem there's any way to determine this at
unification time without making some changes to propagate this information
through the "elaborate" system. So, I'm wondering whether there's a way to
get at this information that I'm missing and, if not, whether there's a
particularly MLtonian way to propagate this flexible/rigid information to
the right place and, of course, whether people think the benefit of these
suggestion error messages would justify the cost of making the changes.

Thank you very much for your help,

Steven Melendez

------=_Part_32256_13736008.1151694193780
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,<br>
<br>
As Matthew Fluet mentioned in introducing me to the list, I'm an
undergraduate student looking at improving error messages for MLton.
Specifically, I was hoping to give &quot;suggestions&quot; for missing sharing
constraints or &quot;where type..&quot; declarations. To do this, it seems like
it would be necessary to know either in TypeEnv.Type.conAnd or at the
time of the various calls to unify in elaborate-core.fun whether
particular type constructors are flexible or rigid.<br>
<br>
Unfortunately, it doesn't seem there's any way to determine this at
unification time without making some changes to propagate this
information through the &quot;elaborate&quot; system. So, I'm wondering whether
there's a way to get at this information that I'm missing and, if not,
whether there's a particularly MLtonian way to propagate this
flexible/rigid information to the right place and, of course, whether
people think the benefit of these suggestion error messages would
justify the cost of making the changes.<br>
<br>
Thank you very much for your help,<br>
<br>
Steven Melendez<br>

------=_Part_32256_13736008.1151694193780--