Space in nullary unboxed tuples

[monoidal]

Prelude> :t (# #)
(# #) :: (##)

should be

(# #) :: (# #)

- the syntax requires a space. I apologise for raising such a trivial matter.

[parcs]

What are the consequences of changing the OccName? of the unit unboxed tuple from (##) to (# #) ? e.g.

diff --git a/compiler/basicTypes/OccName.lhs b/compiler/basicTypes/OccName.lhs
index afdde7c..dc7bf0a 100644
--- a/compiler/basicTypes/OccName.lhs
+++ b/compiler/basicTypes/OccName.lhs
@@ -821,7 +821,7 @@ mkTupleOcc ns sort ar = OccName ns (mkFastString str)
        -- no need to cache these, the caching is done in the caller
        -- (TysWiredIn.mk_tuple)
     str = case sort of
-               UnboxedTuple    -> '(' : '#' : commas ++ "#)"
+               UnboxedTuple    -> "(#" ++ (if null commas then " " else commas) ++ "#)"
                BoxedTuple      -> '(' : commas ++ ")"
                 ConstraintTuple -> '(' : commas ++ ")"
                   -- Cute hack: reuse the standard tuple OccNames (and hence code)

[monoidal]

The patch by parcs seems to fix the issue.

[simonpj]

I agree that this is a tiresome issue, but I'm not convinced that adding spaces is the right way to go. What is the name of the type constructor? Presumably "(##)". We don't have ANY type constructors that have spaces in the middle of their names.

An alternative is to permit "(##)" to parse as a type and a term, just as () does. The only reason it does not at the moment is becuase if you had an operator "##", then "(##)" would usually be the parenthesised version of it. The lexer has a special check:

<0> {
  "(#" / { ifExtension unboxedTuplesEnabled `alexAndPred` notFollowedBySymbol }
         { token IToubxparen }
  "#)" / { ifExtension unboxedTuplesEnabled }
         { token ITcubxparen }
}

Notice that notFollowedBySymbol thing. That's what stops "(##)" lexing as "(#" followed by "#)". I think.

So we could just back off this and say that if you have -XUboxedTuples then "(##)" means a unit unboxed tuple, not the operator "##". I think that'd be better.

What about "(#-)"? Maybe that should parse as the parenthesised operator "#-". So the lexer would essentialy have to recognise "(##)" and do the right thing (two lexemes).

Simon M, or anyone else, any opinions?

Simon

[simonmar]

Replying to simonpj:

So we could just back off this and say that if you have -XUboxedTuples then "(##)" means a unit unboxed tuple, not the operator "##". I think that'd be better.

Sounds good to me.

[igloo]

Sounds like the right thing to me, too. I'm not sure what the best way to implement it is, though. Perhaps have a single token for (##) and tell the parser what it means?

Incidentally, HEAD seems to have the unwanted space now:

Prelude> :t (#  #)
(#  #) :: (# #)

and :i can't understand the unboxed unit tuple, although it does work for others:

Prelude> :i (##)

Top level: Not in scope: `##'
Prelude> :i (# #)

<interactive>:1:3:
    parse error (possibly incorrect indentation or mismatched brackets)
Prelude> :i (#,#)
data (#,#) a b = (#,#) a b      -- Defined in `GHC.Prim'

[simonpj]

We agreed that we're going to make "(##)" lex as two tokens (# and #). Indeed, to keep it simple, "(#anythingatall" will lex as "(#" followed by anythingatall.

Ian will do this, and document it in the manual.

Simon

[ian@…]

commit 20b98f350d7b30118ca311117903fc039f6b85ce

Author: Ian Lynagh <ian@well-typed.com>
Date:   Mon Feb 25 19:02:57 2013 +0000

    Change how unboxed tuples are lexed; fixes #7627
    
    (# is now always a lexeme, even if followed by a symbol.

 compiler/parser/Lexer.x           |    2 +-
 docs/users_guide/glasgow_exts.xml |    8 ++++++++
 2 files changed, 9 insertions(+), 1 deletions(-)

[igloo]

Fixed. We now get:

Prelude> :i (##)
data (##) = (##)        -- Defined in ‛GHC.Prim’

Prelude> :t (##)
(##) :: (# #)

Prelude> :i (#   #)

<interactive>:1:3:
    parse error (possibly incorrect indentation or mismatched brackets)

Prelude> :t (#   #)
(#   #) :: (# #)