[GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request

[GHC]

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature
request
-----------------------------+----------------------------------------------
    Reporter:  Isaac Dupree  |        Owner:         
        Type:  bug           |       Status:  new    
    Priority:  normal        |    Milestone:         
   Component:  Compiler      |      Version:  6.6.1  
    Severity:  normal        |   Resolution:         
    Keywords:                |   Difficulty:  Unknown
          Os:  Unknown       |     Testcase:         
Architecture:  Unknown       |  
-----------------------------+----------------------------------------------
Comment (by Isaac Dupree):

 I'm not seeing a way it would actually be useful for GADTs either, since
 you can't do anything with a general value of kind '#'.

 It would be nice to be able to do enumerations more cleanly than that
 numerical way, but... As far as I have been able to figure out, the
 advantage of using unboxed values is that the compiler enforces that you
 can't use them in a non-strict way, potentially making code more efficient
 (versus the compiler guessing what places to unbox data implicitly) (and
 having less strictness annotations in the source code, even where it is
 effectively strict [function arguments, data members, let-bound
 variables], which has its pros and cons).  The trouble with enumeration
 types is that they are boxed normally: a function can take a Bool thunk
 that, iff the function decides to evaluate it, will raise an exception.

 Being able to newtype for FastInt makes sense, though, for the same
 abstraction reason of all newtypes - of course with the odd property of it
 being unlifted and not type-equal to any of the standard unlifted types.

 (what if we could declare {{{data ( FastBool :: # ) = FastTrue |
 FastFalse}}}, or even allow different data sizes and it takes up an amount
 of space equal to any necessary tag plus the maximum member: {{{data (
 FastEither a b :: # ) = FastLeft a | FastRight !b {-members may or may not
 be strict-} }}}, {{{data ( FastTuple a b :: # ) = FastTuple a b {- would
 this be equivalent to (# #) ? -} }}} ? Probably at least some of that is a
 foolish idea... Let's performance-test GHC with/without using those
 unboxed, maybe)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1311>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
-------------- next part --------------
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs