diff options
| -rw-r--r-- | compiler/coreSyn/CorePrep.hs | 2 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreUtils.hs | 4 | ||||
| -rw-r--r-- | docs/users_guide/glasgow_exts.rst | 2 | ||||
| -rw-r--r-- | utils/gen-dll/Main.hs | 2 |
4 files changed, 5 insertions, 5 deletions
diff --git a/compiler/coreSyn/CorePrep.hs b/compiler/coreSyn/CorePrep.hs index 16f69cc6a7..2bfb558526 100644 --- a/compiler/coreSyn/CorePrep.hs +++ b/compiler/coreSyn/CorePrep.hs @@ -1085,7 +1085,7 @@ How might it not be evaluated? Well, we might have floated it out of the scope of a `seq`, or dropped the `seq` altogether. We only do this if 'e' is not a WHNF. But if it's a simple -variable (common case) we need to know it's evaluated-ness flag. +variable (common case) we need to know its evaluated-ness flag. Example: data T = MkT !Bool f v = case v of diff --git a/compiler/coreSyn/CoreUtils.hs b/compiler/coreSyn/CoreUtils.hs index d35ae235af..fbe7ebd9a6 100644 --- a/compiler/coreSyn/CoreUtils.hs +++ b/compiler/coreSyn/CoreUtils.hs @@ -1500,7 +1500,7 @@ But we restrict it sharply: _ -> ...v...v.... Should v be considered ok-for-speculation? Its scrutinee may be evaluated, but the alternatives are incomplete so we should not - evalutate it strictly. + evaluate it strictly. Now, all this is for lifted types, but it'd be the same for any finite unlifted type. We don't have many of them, but we might @@ -1538,7 +1538,7 @@ evaluate them. Indeed, in general primops are, well, primitive and do not perform evaluation. There is one primop, dataToTag#, which does /require/ a lifted -argument to be evaluted. To ensure this, CorePrep adds an +argument to be evaluated. To ensure this, CorePrep adds an eval if it can't see the argument is definitely evaluated (see [dataToTag magic] in CorePrep). diff --git a/docs/users_guide/glasgow_exts.rst b/docs/users_guide/glasgow_exts.rst index 6704b87250..34efbfd3e2 100644 --- a/docs/users_guide/glasgow_exts.rst +++ b/docs/users_guide/glasgow_exts.rst @@ -12404,7 +12404,7 @@ Bang patterns and Strict Haskell In high-performance Haskell code (e.g. numeric code) eliminating thunks from an inner loop can be a huge win. GHC supports three extensions to allow the programmer to specify -use of strict (call-by-value) evalution rather than lazy (call-by-need) +use of strict (call-by-value) evaluation rather than lazy (call-by-need) evaluation. - Bang patterns (:extension:`BangPatterns`) makes pattern matching and diff --git a/utils/gen-dll/Main.hs b/utils/gen-dll/Main.hs index 0383b8e322..7cc965bd7d 100644 --- a/utils/gen-dll/Main.hs +++ b/utils/gen-dll/Main.hs @@ -85,7 +85,7 @@ In the end we end up with libfoo-pt1.dll, libfoo-pt2.dll and libfoo-pt3.dll along with libfoo.dll.a. To the rest of the pipeline the split is - completely transparant as -lfoo will just continue to work, and the linker + completely transparent as -lfoo will just continue to work, and the linker is responsible for populating the IAT (Import Address Table) with the actual dlls we need. |