patch applied (ghc): Tuples cannot contain unboxed types

Thu May 15 04:53:32 PDT 2008 [EMAIL PROTECTED] * Tuples cannot contain unboxed types This bug allowed, for example f = let x = ( 1#, 'x' ) in x which is ill-typed because you can't put an unboxed value in a tuple. Core Lint fails on this program. The

patch applied (ghc): Improve the unboxed types documentation

Wed Apr 30 08:25:08 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Improve the unboxed types documentation Mainly adding descriptions of unboxed literals, M ./docs/users_guide/glasgow_exts.xml -2 +16 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080430152508

Re: unboxed types

ed hackery in GHC's sources; I think it sends a bad message: that this sort of thing is necessary to get good performance. It's true that unboxed types aren't necessary to get good performance. However, much as I hate to say it, they're necessary to *reliably* get good perfor

Re: unboxed types

27;s sources; I think it sends a bad message: that this sort of thing is necessary to get good performance. It's true that unboxed types aren't necessary to get good performance. However, much as I hate to say it, they're necessary to *reliably* get good performance. When I write c

Re: unboxed types

On Mon, Dec 31, 2007 at 09:14:04AM -0500, Isaac Dupree wrote: > I guess boxed types are too risky for efficiency reasons in some parts > of the code Again, I'd hope that that isn't true for modern GHC, and I personally would love to see less unboxed hackery in GHC's sources; I think it sends a ba

Re: unboxed types

Isaac Dupree <[EMAIL PROTECTED]> wrote: ... lots of questions about the nhc98 .hi file format. I think the easiest way to answer is just "have a look at an example file". There are plenty supplied with the source distribution of nhc98: you don't even need to build it. Look in the include/ direc

Re: unboxed types

Malcolm Wallace wrote: It simply contains type signatures for exported functions, together with datatype, class, and instance decls. A signature for function 'foo' is preceded by a {-# NEED foo #-} pragma; a datatype or class decl is preceded by a similar pragma listing precisely the exported co

Re: unboxed types

> > Module cycles have supported in nhc98 since forever, by simply > > providing a bootstrapping .hi file. > > yay! Is the format of this .hi file documented somewhere? It simply contains type signatures for exported functions, together with datatype, class, and instance decls. A signature for f

Re: unboxed types

Malcolm Wallace wrote: Module cycles have supported in nhc98 since forever, by simply providing a bootstrapping .hi file. (Probably best stored in a different directory, referenced by a -Pdir flag, to avoid it being overwritten by the real generated .hi file.) yay! Is the format of this .hi fi

Re: unboxed types

Isaac Dupree <[EMAIL PROTECTED]> wrote: > extension matrix, am I right? (did the tabs work to format it?) The tabs worked, but the extension matrix is not exactly right. > [1] supported in darcs but not a released version? or was there a > recent nhc release supporting pattern-guards? Patt

Re: unboxed types

Simon Marlow wrote: Agreed. It's very difficult to test whether a particular change degrades performance, as it might only do so on certain examples. well, my other plan was to see if I could get -ddump-simpl to come out about the same... but looking at that is a little tricky with GHC's bui

Re: unboxed types

vious what to do with. utf8DecodeChar# in utils/Encoding (defined) and utils/StringBuffer (used) has unboxed tuple that contains FastTypes (well, unboxed types, but I think I'm going to make a FastChar and FastPtr to allow conversion of this kind of code) The comments make clear that som

Re: unboxed types

# in a CPP macro may confuse various CPP stuff in GHC. added! I'd also be shocked if it turns out that unboxed types make that much of a difference. They will make a difference in library functions (called a lot), or hot-spots, but in general they only add a constant improvement. Of c

Re: unboxed types

Neil Mitchell wrote: Hi Isaac, Or will I have to #define UTopen (# #defined UTclose #) and (UTopen x, y UTclose) Yuk! There is a ticket on adding a prefix form of (#,#), which is currently lacking. Perhaps adding that first, then moving to the unboxed thingy would be best. that sounds like

Re: unboxed types

ich it could be otherwise; data TUPLE3 a b c = TUPLE3 a b c I'd also be shocked if it turns out that unboxed types make that much of a difference. They will make a difference in library functions (called a lot), or hot-spots, but in general they only add a constant improvement. Of course

Re: unboxed types

in a CPP macro may confuse various CPP stuff in GHC. I'd also be shocked if it turns out that unboxed types make that much of a difference. They will make a difference in library functions (called a lot), or hot-spots, but in general they only add a constant improvement. Of course, num

unboxed types

I guess boxed types are too risky for efficiency reasons in some parts of the code (close examination of -ddump-simpl would be needed I guess), so I'll expand utils/FastTypes and put all the #ifdefs in there. Unboxed tuples that are used in little areas of GHC code solely for the efficiency of

patch applied (ghc): Breakpoints: don' t attempt to bind variables with unboxed types

Fri Apr 27 07:20:36 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * Breakpoints: don't attempt to bind variables with unboxed types M ./compiler/main/GHC.hs -15 +20 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailm