UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)`

GHCi, version 8.1.20160920: http://www.haskell.org/ghc/  :? for help
Prelude> let (#) = (+)
Prelude> :set -XUnboxedSums 
Prelude> let (#) = (+)

<interactive>:3:7: error: parse error on input ‘)’

I first noticed this in an import statement:

import Data.Functor.Utils (Max(..), Min(..), (#.))

Trac metadata

Trac field	Value
Version	8.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

Well, UnboxedTuples does the same.

Oh I see you're right, and maybe this is a dup of #12459 (closed)

However even if that's expected under UnboxedTuples, this seems to be a worse situation under UnboxedSums.

I'm looking at https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes under "Unpacking ... This part is not yet implemented..." it seems to me the intention is to allow UnboxedSums to automatically optimize (has this been implemented in HEAD yet btw?):

data T1 a = Some a | None
data T2 a = C {-# UNPACK #-} !(T1 a)

So a user might like to enable on a source tree for purposes of optimization; they don't need or want access to any new syntax.

Let me know if I should open any new tickets. Feel free to do whatever you think with this one.

closed

Presumably you won't need to enable any language extensions in order to take advantage of optimizations that use unboxed sums. There are already important optimizations that introduce unboxed tuples, and they don't require a language extension. These language extensions just allow you to write unboxed sums/tuples in the surface syntax.

I guess I'll close this ticket since I don't think we should do anything here, though I don't feel too strongly about it.

By the way, the workaround for the original issue is to add a space before #..

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

added Pnormal label