Re: scope invariants in core

Hi Simon -- Terrific, this seems to be the ticket...! Thanks a bunch! Ranjit. On Mon, Mar 18, 2013 at 1:34 PM, Simon Peyton-Jones wrote:

That does seem odd.

Use -dppr-debug so you can see the actual unique on each Id, just to make sure the print-name isn't different from the underlying unique.

In an older version of GHC (before March 2012; patch below) variables could not be bound to unboxed tuples, so if your fork is based on a sufficiently old version that might be a problem.

Aha. Before the patch below, I see this code in Core Lint

-- If the binder is an unboxed tuple type, don't put it in scope ; let scope = if (isUnboxedTupleType (idType var)) then pass_var else lintAndScopeId var

and indeed the patch below removes those lines. So that's it. You need to update. Whether you can do so for just this one patch is more than I can say!

Simon

commit 09987de4ece1fc634af6b2b37173b12ed46fdf3e Author: Max Bolingbroke Date: Sun Mar 18 00:00:38 2012 +0000

Support code generation for unboxed-tuple function arguments

This is done by a 'unarisation' pre-pass at the STG level which translates away all (live) binders binding something of unboxed tuple type.

This has the following knock-on effects: * The subkind hierarchy is vastly simplified (no UbxTupleKind or ArgKind) * Various relaxed type checks in typechecker, 'foreign import prim' etc * All case binders may be live at the Core level

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org | [mailto:glasgow-haskell-users- bounces@haskell.org] On Behalf Of | Ranjit Jhala | Sent: 18 March 2013 18:06 | To: glasgow-haskell-users@haskell.org | Subject: scope invariants in core | | Hi all, | | I have been manipulating CoreExpr to convert it to A-Normal Form. | Mostly, things have been working fine, but I hit an error this | morning of the form: | | lq_anf__d11u is out of scope | | where lq_anf__d11u is a binder I have introduced in the transformed | expression | | Data.ByteString.Internal.c_strlen = | (\ (ds_d11l :: GHC.Ptr.Ptr Foreign.C.Types.CChar) -> | case ds_d11l of lq_anf__d11t { GHC.Ptr.Ptr ds_d11n -> | let { | lq_anf__d11x | :: GHC.Prim.State# GHC.Prim.RealWorld | -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Word.Word32 #) | [LclId] | lq_anf__d11x = | \ (ds_d11q :: GHC.Prim.State# GHC.Prim.RealWorld) -> | case {__pkg_ccall main strlen GHC.Prim.Addr# | -> GHC.Prim.State# GHC.Prim.RealWorld | -> (# GHC.Prim.State# GHC.Prim.RealWorld, | GHC.Prim.Word# #)} | ds_d11n ds_d11q | of lq_anf__d11u { __DEFAULT -> | case lq_anf__d11u of lq_anf__d11v { (# ds_d11p, ds_d11o #) -> | let { | lq_anf__d11w :: GHC.Word.Word32 | [LclId] | lq_anf__d11w = GHC.Word.W32# ds_d11o } in | (# ds_d11p, lq_anf__d11w #) | } | } } in | GHC.Types.IO @ GHC.Word.Word32 lq_anf__d11x | }) | | | It would appear, that the variable IS in scope (as it is bound by | the case-expression just before it is used, but perhaps the binder is | not added to the environment because of its type (# ... , ... #)? | Or is there some other invariant I am breaking? | | Can anyone familiar with the scoping invariants of CoreExpr/CoreSyn | give me a hint as to what might be happening? | | Many thanks in advance! | | Ranjit. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users