Re: [Sml-implementers] Portable library descriptions, a proposal

[Matthias B. <bl...@re...>]

Hi Ken,

Ken Friis Larsen wrote:

>   * In general I miss some arguments for the choices made.


I know.  But it would have made the already fairly lengthy writeup
even longer.

>   * Do you think it is impossible to make a human readable/writable
>     format (comment to footnote one on page one).  


No, I don't think it is impossible.  In fact, I implemented one: CM. :)

More seriously:

   - The goal that I set for myself was explicitly _not_ to produce a
     one-size-fits-all UI to everybody's separate compilation system.
   - It is not entirely impossible (just inconvenient) to read and write
     these descriptions if one really, really badly wants to.


>   * The datatype for abstract syntax is ugly, fx why is namespace not
>     an enumeration?


Well, I actually had some reason for this, but after carefully re-thinking
this issue, I now agree with you.  I new version of the proposal is now
online -- with the respective changes.

(Fixing the namespace type to an enumeration would make it difficult if
not impossible to write the "PGOps" module in such a way that it is oblivious
to which namespaces are being used.  Given that SML/NJ does extend the set
of namespaces, I thought that making the set easily extensible would be a good
idea.  However, I now realize that such extensibility is an illusion anyway:
I cannot export a library that uses "funsig" and expect other implementations
to be able to compile it.  Thus, SML/NJ (or rather: CM) should -- and now will --
reject any attempt of generating a "portable" library that uses "funsig".
Thus, the new policy is _non_-extensibilty:  implementations that themselves support
certain extensions to SML should not try to export these extensions into the
library description format that is shared by all implementations.)

>   * Why are the only allowed namespaces STR, SIG, and FCT?  Partly
>     addressed in section 8.


Because some systems (CM in particular) do not support other (non-modular)
exports.  The reason for this is that it greatly reduces the amount of data
that must be processed during dependency analysis.
In any case, I have very good experiences with this rule ("only modular
exports") which CM took from earlier work done at CMU.  I hope that it is not
too controversial.

One alternative approach would be to allow all namespaces ("variable/constructor",
"type", "fixity", "structure", "signature", "functor") and issue a strong informal
warning not to write libraries that export non-modular things.  Implementations
such as CM would then be forced to reject those libraries that don't heed the
warning.
This would probably be fine, but given that I found the "only modular bindings"
restriction to be virtually incontroversial among users of CM (*), I do not think
that being less restrictive is such a big deal.

(*)  The only person I know of who sometimes grumbled about the restriction is I:
      When I taught CM to treat the Basis Library as an ordinary CM library I
      sometimes wished that it would be able to handle types and variable bindings.
      When at one point I made a push for relaxing the restriction within CM at the
      expense of a more complicated dependency analysis, there were people who
      actively persuaded me _not_ to bother.

> Should we try to structure the way feedback is given, or should we
> just do it in an add-hoc fashion?  Also how do we (sml-implementers)
> determine that a proposal is agreed upon?


I don't know. As far as I am concerned, informal feedback is fine.  I have
no idea on what would constitute an official approval by the implementers.

-- 
-Matthias