Degrade abstype to derived form

From Successor ML

Jump to: navigation, search

Contents

Introduction

We propose to degrade the abstype syntax to a derived form, which also resolves some issues in the current definition.

Motivation and Example

Abstype is a leftover from SML's pre-module days and is now fully subsumed by structures and sealing. Besides being redundant, the current specification of abstype is incoherent wrt equality (Defects in the Revised Definition of Standard ML), an issue for which no obvious fix exists.

Although abstype is practically unused in modern code, we cannot remove it without breaking backwards compatibility. We hence propose to turn it into a derived form, thereby simplifying the bare language and simultanously resolving the coherence issues.

Assumptions

None.

Syntax

Effectively unchanged, but specified differently now:

  • In Section 2.8, Figure 4, remove the production for abstype.
  • In Appendix A, Figure 17, add the following rewriting rule before the existing one for abstype:
   +------------------------------+---------------------------+
   | abstype datbind with dec end | local datatype datbind in |
   |                              |       type typbind' ; dec |
   |                              | end                       |
   +------------------------------+---------------------------+
and extend the note to
   (see note in text concerning datbind' and typbind')
  • In Appendix A, the bullet list in the text referring to Figure 17, add the following item:
In the abstype form, typbind' is obtained from datbind by replacing all right-hand sides by the corresponding left-hand side, i.e. tyvarseq tycon = conbind <| datbind> becomes tyvarseq tycon = tyvarseq tycon <| typbind>

Static Semantics

Simplified as follows:

  • In Section 4.9, remove the last paragraph.
  • In Section 4.10, Declarations, remove Rule 19 and the corresponding comments.

Dynamic Semantics

Simplified as follows:

  • In Section 6.7, Declarations, remove Rule 118.

Interactions

None.

Compatibility

This is a conservative change. The new specification is slightly more permissive than the original static semantics of abstype, because the equality attribute of the defined type is no longer hidden. However, this is precisely what is necessary to fix the aforementioned coherence issues.

While the change may marginally affect the abstraction properties of code still using abstype, it can be argued that the obsolete nature of abstype makes this neglectable in practice.

Implementation

The change simplifies implementations, because it enables them to isolate their treatment of abstype in the parser.

Personal tools