Discussion of proposal guidelines and processes

[JohnReppy]

This issue is for discussion of the draft guidelines for SML Basis Library proposals that have been posted to the wiki.

This issue is also intended as a forum for discussing the processes needed to submit, discuss, approve, and release changes to the Basis Library.

[MatthewFluet]

I think that the guidelines look good.

For sub-pages, perhaps use the naming scheme YYYY-DDDA-NAME.ZZZ, where A is the sub-page alpha for the proposal (i.e., "a", "b", "c", ...). Point being that it would be clear from the wiki page name whether it was a sub-page of a proposal or the root page of a proposal.

I don't quite like the fact that the entirety of a proposal is spread across the wiki, the git repository proper (for reference implementation), and GitHub issues, but don't see a better alternative.

[JohnReppy]

I agree about the naming scheme for subpages. I'll update the guidelines.

W.r.t. spreading the content, that is really an artifact of building on github and trying to choose the best tool for each particular part. We could move proposals into the repository, but we would lose the wiki support for organizing them.

[JohnReppy]

I have posted a draft description of the Process document to the wiki. Please discuss.

[RobertHarper]

Looks like a good plan!

[MatthewFluet]

I think that the process document looks fine. Perhaps update the template in Code/examples to include a Managing Editor field in the header.

[JohnReppy]

I've added a "Managing editor" field to the example.

[RobertHarper]

This is to record that I despise camel case and wish that we would change that. It's not ML, it smacks of Smalltalk. Ugh.

[MatthewFluet]

@RobertHarper Was snake_case the traditional ML convention? Thinking of modern, module-rich MLs, I wondered if sufficient use of modules would obviate the need for complex identifiers (e.g., TextIO.In.open, rather than TextIO.openIn).

[RobertHarper]

yes, snake_case was the convention. it’s true that proper use of modules avoids the need for openIn, etc.

bob

On Sep 30, 2015, at 14:59, Matthew Fluet [email protected] wrote:

@RobertHarper https://github.com/RobertHarper Was snake_case the traditional ML convention? Thinking of modern, module-rich MLs, I wondered if sufficient use of modules would obviate the need for complex identifiers (e.g., TextIO.In.open, rather than TextIO.openIn).

—
Reply to this email directly or view it on GitHub #11 (comment).

[JohnReppy]

snake_case was the standard for SML'90 (and before), but that changed for SML'97.

[RobertHarper]

not to my knowledge

On Sep 30, 2015, at 15:26, John Reppy [email protected] wrote:

snake_case was the standard for SML'90 (and before), but that changed for SML'97.

—
Reply to this email directly or view it on GitHub #11 (comment).

[JohnReppy]

It did change, because we decided on a different standard for the Basis Library (Section 1.1.1 in the book).

[RobertHarper]

well, i don’t remember agreeing to that. in any case my proposal for successor ml is to undo this.

bob

On Sep 30, 2015, at 15:51, John Reppy [email protected] wrote:

It did change, because we decided on a different standard for the Basis Library (Section 1.1.1 in the book).

—
Reply to this email directly or view it on GitHub #11 (comment).

[JohnReppy]

I think that it depends on how much backward compatibility we want to preserve, but this discussion should probably be moved to a Successor ML issue, since this issue if to discussing the process for evolving the Standard ML Basis Library