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
|
