Opened 2 years ago

Closed 2 years ago

#7627 closed bug (fixed)

Space in nullary unboxed tuples

Reported by: monoidal Owned by: igloo
Priority: normal Milestone: 7.8.1
Component: Compiler (Parser) Version: 7.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: T7627 T7627b
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

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

should be

(# #) :: (# #)
  • the syntax requires a space. I apologise for raising such a trivial matter.

Change History (8)

comment:1 Changed 2 years ago by 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)

comment:2 Changed 2 years ago by monoidal

  • Status changed from new to patch

The patch by parcs seems to fix the issue.

comment:3 follow-up: Changed 2 years ago by simonpj

  • difficulty set to Unknown

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

comment:4 in reply to: ↑ 3 Changed 2 years ago by simonmar

  • Milestone set to 7.8.1

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.

comment:5 Changed 2 years ago by 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'

comment:6 Changed 2 years ago by simonpj

  • Owner set to igloo

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

comment:7 Changed 2 years ago by ian@…

commit 20b98f350d7b30118ca311117903fc039f6b85ce

Author: Ian Lynagh <[email protected]>
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(-)

comment:8 Changed 2 years ago by igloo

  • Component changed from Compiler to Compiler (Parser)
  • Resolution set to fixed
  • Status changed from patch to closed
  • Test Case set to T7627 T7627b

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 (#   #)
(#   #) :: (# #)
Note: See TracTickets for help on using tickets.