delete dead code, fix typos in comments (#1923)

This commit is contained in:
Gary Verhaegen 2019-06-28 07:14:52 +01:00 committed by Neil Mitchell
parent e75d2b465e
commit 6320954893
3 changed files with 3 additions and 13 deletions

View File

@ -393,7 +393,7 @@ data Expr
, letBody :: !Expr
-- ^ Expression to bind variable in.
}
-- | Concstruct empty list.
-- | Construct empty list.
| ENil
-- TODO(MH): When we move 'ECons' to 'BuiltinExpr' or remove it entirely,
-- do the same to 'ENil'.

View File

@ -83,16 +83,6 @@ introTypeVar v k act = do
whenM (views tvars (HMS.member v)) $ throwWithContext (EShadowingTypeVar v)
local (tvars . at v ?~ k) act
-- -- | Introduce a fresh type variable to the environment. Uses the given name as
-- -- starting point for searching a fresh name. The fresh name finally found will
-- -- then be put in the enviroment and passed to the continuation.
-- introFreshTypeVar :: MonadGamma m => TypeVarName -> (TypeVarName -> m a) -> m a
-- introFreshTypeVar v act = do
-- let vs = v : map (\n -> fmap (<> T.pack (show n)) v) [1::Int ..]
-- -- NOTE(MH): This 'findM' cannot fail since @tvars@ is finite.
-- v' <- fromJust <$> findM (\v' -> not <$> view (tvars . contains v')) vs
-- introTypeVar v' (act v')
-- | Run a computation in the current enviroment extended by a new term
-- variable/type binding. Does not fail on shadowing.
introExprVar :: MonadGamma m => ExprVarName -> Type -> m a -> m a

View File

@ -25,7 +25,7 @@
-- DICTIONARY SANITIZATION
--
-- GHC's desugaring for default methods relies on the the fact that Haskell is
-- lazy. In contract, DAML-LF is strict. This mismatch causes a few problems.
-- lazy. In contrast, DAML-LF is strict. This mismatch causes a few problems.
-- For instance, GHC desugars:
--
-- > class Foo a where
@ -66,7 +66,7 @@
--
--
--
-- GHC produces a @newtype@ rather than a @data@ type for dictionar types of
-- GHC produces a @newtype@ rather than a @data@ type for dictionary types of
-- type classes with a single method and no super classes. Since DAML-LF does
-- not support @newtype@, we could either treat them as some sort of type
-- synonym or translate them to a record type with a single field. We have