[bitc-dev] Tuple => Pair

[Jonathan S. Shapiro]

For several days, Swaroop and I have been looking at the current TUPLE
type thinking that we made a mistake. I have been drafting a spec change
to replace TUPLE with PAIR. The replacement per se is easy enough, but
it raises an interesting question, and I would like some input.

Before this change, the PAIR type was defined in the standard prelude
as:

  (defstruct (pair 'a 'b) :val
    fst:'a  snd:'b)

As I have gone through the rework, I conclude that this definition can
safely remain in the prelude.

However, if we replace the "implicit tupilize in apply" rule with
"implicit pair-cons in apply", we need to add PAIR to the binding
pattern syntax in much the way that TUPLE is currently part of that
syntax. There are two ways to do this:

1. Remove PAIR from the prelude and make it syntax. This is simple, but
it's somehow aesthetically displeasing.

2. Add (id bp bp bp) to the binding pattern syntax, where ID must be a
structure type name (which would include PAIR). This seems aesthetically
more satisfying, but it introduces another problem.

We already have a *value* pattern syntax

  (id vp vp vp)

since all binding patterns are value patterns, changing the syntax or
binding patterns would make the parse conflicts quite hopeless. There
appear to be three feasible resolutions to this:

1. Collapse the bindingPattern and valuePattern productions for purposes
of parsing, and then do a sanity check in the symbol resolver to ensure
that literals do not appear in bindingPatterns and that all binding
patterns of the form

  (id pat pat pat)

satisfy the restriction that ID must be a structure type and the PAT's
must (recursively) be binding patterns.

2. Preserve the current parse, but change the valuePattern case to be

  (id bp bp bp)

The second would mean that a value pattern like

  (cons a (cons b c))

could not be written, which seems undesirable.

3. Allow (PAIR X Y) as a binding pattern as a special case. This is very
easy to do, and it would not preclude generalizing to structure binding
patterns later.


My sense is that generalized structure binding is not very well
motivated in practice, but I would appreciate input on this.

In the short term, I'm going to do option (3) so that we can keep making
progress.


shap