Commit 0b6024c6 authored by Gabor Greif's avatar Gabor Greif 💬
Browse files

Comments and manual only: spelling

parent f897b742
......@@ -152,7 +152,7 @@ pprDwarfInfo haveSrc d
noChildren = pprDwarfInfoOpen haveSrc d
-- | Prints assembler data corresponding to DWARF info records. Note
-- that the binary format of this is paramterized in @abbrevDecls@ and
-- that the binary format of this is parameterized in @abbrevDecls@ and
-- has to be kept in synch.
pprDwarfInfoOpen :: Bool -> DwarfInfo -> SDoc
pprDwarfInfoOpen haveSrc (DwarfCompileUnit _ name producer compDir lowLabel
......
......@@ -1667,7 +1667,7 @@ Note [FunDep and implicit parameter reactions]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Currently, our story of interacting two dictionaries (or a dictionary
and top-level instances) for functional dependencies, and implicit
paramters, is that we simply produce new Derived equalities. So for example
parameters, is that we simply produce new Derived equalities. So for example
class D a b | a -> b where ...
Inert:
......
......@@ -1916,7 +1916,7 @@ Note that
trigger superclass expansion. This was a good part of the loop
in Trac #11523
* Even for Wanted constraints, we say "no" for implicit paramters.
* Even for Wanted constraints, we say "no" for implicit parameters.
we have [W] ?x::ty, expanding superclasses won't help:
- Superclasses can't be implicit parameters
- If we have a [G] ?x:ty2, then we'll have another unsolved
......
......@@ -1851,7 +1851,7 @@ reify_tc_app tc tys
reifyPred :: TyCoRep.PredType -> TcM TH.Pred
reifyPred ty
-- We could reify the invisible paramter as a class but it seems
-- We could reify the invisible parameter as a class but it seems
-- nicer to support them properly...
| isIPPred ty = noTH (sLit "implicit parameters") (ppr ty)
| otherwise = reifyType ty
......
......@@ -3383,7 +3383,7 @@ example), then we apply the function ``f`` directly to it. If a type is
encountered that is not syntactically equivalent to the last type parameter
*but does mention* the last type parameter somewhere in it, then a recursive
call to ``fmap`` is made. If a type is found which doesn't mention the last
type paramter at all, then it is left alone.
type parameter at all, then it is left alone.
The second of those cases, in which a type is unequal to the type parameter but
does contain the type parameter, can be surprisingly tricky. For example, the
......
......@@ -6,7 +6,7 @@ class Foo f a r | f a -> r where
foo::f->a->r
-- These instances are incompatible because we can unify
-- the first two paramters, though it's rather obscure:
-- the first two parameters, though it's rather obscure:
-- p -> (a,b)
-- t -> (,) (a,a)
-- c -> (,) a
......
{-# LANGUAGE ImplicitParams #-}
-- The defn of foo should be rejected; it's monomorphic, but
-- the implicit paramter escapes
-- the implicit parameter escapes
module Foo where
......
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