Commit 61baf710 authored by Simon Peyton Jones's avatar Simon Peyton Jones
Browse files

Comments and white space

parent 24a2e49e
......@@ -180,25 +180,8 @@ These data types are the heart of the compiler
-- /must/ be of lifted type (see "Type#type_classification" for
-- the meaning of /lifted/ vs. /unlifted/).
--
-- #let_app_invariant#
-- The right hand side of of a non-recursive 'Let'
-- _and_ the argument of an 'App',
-- /may/ be of unlifted type, but only if the expression
-- is ok-for-speculation. This means that the let can be floated
-- around without difficulty. For example, this is OK:
--
-- > y::Int# = x +# 1#
--
-- But this is not, as it may affect termination if the
-- expression is floated out:
--
-- > y::Int# = fac 4#
--
-- In this situation you should use @case@ rather than a @let@. The function
-- 'CoreUtils.needsCaseBinding' can help you determine which to generate, or
-- alternatively use 'MkCore.mkCoreLet' rather than this constructor directly,
-- which will generate a @case@ if necessary
--
-- See Note [CoreSyn let/app invariant]
--
-- #type_let#
-- We allow a /non-recursive/ let to bind a type variable, thus:
--
......@@ -359,9 +342,28 @@ See #letrec_invariant#
Note [CoreSyn let/app invariant]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See #let_app_invariant#
The let/app invariant
the right hand side of of a non-recursive 'Let', and
the argument of an 'App',
/may/ be of unlifted type, but only if
the expression is ok-for-speculation.
This means that the let can be floated around
without difficulty. For example, this is OK:
y::Int# = x +# 1#
But this is not, as it may affect termination if the
expression is floated out:
y::Int# = fac 4#
In this situation you should use @case@ rather than a @let@. The function
'CoreUtils.needsCaseBinding' can help you determine which to generate, or
alternatively use 'MkCore.mkCoreLet' rather than this constructor directly,
which will generate a @case@ if necessary
This is intially enforced by DsUtils.mkCoreLet and mkCoreApp
Th let/app invariant is intially enforced by DsUtils.mkCoreLet and mkCoreApp
Note [CoreSyn case invariants]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
......
......@@ -964,7 +964,7 @@ app_ok :: (PrimOp -> Bool) -> Id -> [Expr b] -> Bool
app_ok primop_ok fun args
= case idDetails fun of
DFunId _ new_type -> not new_type
-- DFuns terminate, unless the dict is implemented
-- DFuns terminate, unless the dict is implemented
-- with a newtype in which case they may not
DataConWorkId {} -> True
......@@ -983,14 +983,12 @@ app_ok primop_ok fun args
-> True
| otherwise
-> primop_ok op -- A bit conservative: we don't really need
&& all (expr_ok primop_ok) args
-- to care about lazy arguments, but this is easy
-> primop_ok op -- A bit conservative: we don't really need
&& all (expr_ok primop_ok) args -- to care about lazy arguments, but this is easy
_other -> isUnLiftedType (idType fun) -- c.f. the Var case of exprIsHNF
|| idArity fun > n_val_args -- Partial apps
|| (n_val_args == 0 &&
|| (n_val_args == 0 &&
isEvaldUnfolding (idUnfolding fun)) -- Let-bound values
where
n_val_args = valArgCount args
......
......@@ -330,7 +330,7 @@ We cannot represent this by a newtype, even though it's not
existential, because there are two value fields (the equality
predicate and op. See Trac #2238
Moreover,
Moreover,
class (a ~ F b) => C a b where {}
Here we can't use a newtype either, even though there is only
one field, because equality predicates are unboxed, and classes
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment