| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
---------------------------------------
Add rebindable syntax for do-notation
(this time, on the HEAD)
---------------------------------------
Make do-notation use rebindable syntax, so that -fno-implicit-prelude
makes do-notation use whatever (>>=), (>>), return, fail are in scope,
rather than the Prelude versions.
On the way, combine HsDo and HsDoOut into one constructor in HsSyn,
and tidy up type checking of HsDo.
|
| |
|
|
| |
Add comment
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make negative literals work in patterns
The issue here is that
f (-1) = True
f x = False
should generate
f x = x == negate (fromInteger 1)
rather than
f x = x == fromInteger (-1)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow infix type constructors
This commit adds infix type constructors (but not yet class constructors).
The documentation describes what should be the case. Lots of tiresome
changes, but nothing exciting.
Allows infix type constructors everwhere a type can occur, and in a data
or type synonym decl. E.g.
data a :*: b = ....
You can give fixity decls for type constructors, but the fixity decl
applies both to the tycon and the corresponding data con.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FastString cleanup, stage 1.
The FastString type is no longer a mixture of hashed strings and
literal strings, it contains hashed strings only with O(1) comparison
(except for UnicodeStr, but that will also go away in due course). To
create a literal instance of FastString, use FSLIT("..").
By far the most common use of the old literal version of FastString
was in the pattern
ptext SLIT("...")
this combination still works, although it doesn't go via FastString
any more. The next stage will be to remove the need to use this
special combination at all, using a RULE.
To convert a FastString into an SDoc, now use 'ftext' instead of
'ptext'.
I've also removed all the FAST_STRING related macros from HsVersions.h
except for SLIT and FSLIT, just use the relevant functions from
FastString instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-------------------
Mainly derived Read
-------------------
This commit is a tangle of several things that somehow got wound up
together, I'm afraid.
The main course
~~~~~~~~~~~~~~~
Replace the derived-Read machinery with Koen's cunning new parser
combinator library. The result should be
* much smaller code sizes from derived Read
* faster execution of derived Read
WARNING: I have not thoroughly tested this stuff; I'd be glad if you did!
All the hard work is done, but there may be a few nits.
The Read class gets two new methods, not exposed
in the H98 inteface of course:
class Read a where
readsPrec :: Int -> ReadS a
readList :: ReadS [a]
readPrec :: ReadPrec a -- NEW
readListPrec :: ReadPrec [a] -- NEW
There are the following new libraries:
Text.ParserCombinators.ReadP Koens combinator parser
Text.ParserCombinators.ReadPrec Ditto, but with precedences
Text.Read.Lex An emasculated lexical analyser
that provides the functionality
of H98 'lex'
TcGenDeriv is changed to generate code that uses the new libraries.
The built-in instances of Read (List, Maybe, tuples, etc) use the new
libraries.
Other stuff
~~~~~~~~~~~
1. Some fixes the the plumbing of external-core generation. Sigbjorn
did most of the work earlier, but this commit completes the renaming and
typechecking plumbing.
2. Runtime error-generation functions, such as GHC.Err.recSelErr,
GHC.Err.recUpdErr, etc, now take an Addr#, pointing to a UTF8-encoded
C string, instead of a Haskell string. This makes the *calls* to these
functions easier to generate, and smaller too, which is a good thing.
In particular, it means that MkId.mkRecordSelectorId doesn't need to
be passed "unpackCStringId", which was GRUESOME; and that in turn means
that tcTypeAndClassDecls doesn't need to be passed unf_env, which is
a very worthwhile cleanup. Win/win situation.
3. GHC now faithfully translates do-notation using ">>" for statements
with no binding, just as the report says. While I was there I tidied
up HsDo to take a list of Ids instead of 3 (but now 4) separate Ids.
Saves a bit of code here and there. Also introduced Inst.newMethodFromName
to package a common idiom.
|
| |
|
|
|
|
|
|
| |
Allow the use of 'let' for implcit bindings.
Support for 'with' is left in place for the time being, but on seeing
a 'with' we emit a non-suppressible warning about 'with' being
deprecated in favour of 'let'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------------
Change the treatment of the stupid
context on data constructors
-----------------------------------
Data types can have a context:
data (Eq a, Ord b) => T a b = T1 a b | T2 a
and that makes the constructors have a context too
(notice that T2's context is "thinned"):
T1 :: (Eq a, Ord b) => a -> b -> T a b
T2 :: (Eq a) => a -> T a b
Furthermore, this context pops up when pattern matching
(though GHC hasn't implemented this, but it is in H98, and
I've fixed GHC so that it now does):
f (T2 x) = x
gets inferred type
f :: Eq a => T a b -> a
I say the context is "stupid" because the dictionaries passed
are immediately discarded -- they do nothing and have no benefit.
It's a flaw in the language.
Up to now I have put this stupid context into the type of
the "wrapper" constructors functions, T1 and T2, but that turned
out to be jolly inconvenient for generics, and record update, and
other functions that build values of type T (because they don't
have suitable dictionaries available).
So now I've taken the stupid context out. I simply deal with
it separately in the type checker on occurrences of a constructor,
either in an expression or in a pattern.
To this end
* Lots of changes in DataCon, MkId
* New function Inst.tcInstDataCon to instantiate a data constructor
I also took the opportunity to
* Rename
dataConId --> dataConWorkId
for consistency.
* Tidied up MkId.rebuildConArgs quite a bit, and renamed it
mkReboxingAlt
* Add function DataCon.dataConExistentialTyVars, with the obvious meaning
|
| |
|
|
|
|
|
|
|
| |
Front end for External Core.
Initial go at implementing a Core front end
(enabled via -fcore); work in progress (renamer
is currently not willing to slurp in & resolve
imports.)
|
| |
|
|
|
| |
Misc cleanup: remove the iface pretty-printing style, and clean up
bits of StringBuffer that aren't required any more.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the interface file parser, and move .hi-boot parsing into the
main parser. The syntax of .hi-boot files is now greatly improved in
terms of readability; here's an example:
module M where
data T
f :: T -> GHC.Base.Int
note that
(a) layout can be used
(b) there's no explcit export list; everything declared
is implicitly exported
(c) Z-encoding of names is no longer required
(d) Any identifier not declared in the current module must
still be quailified with the module which originally
defined it (eg. GHC.Base.Int above).
We'd like to relax (d), but that will come later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------
Change
GlobalName --> ExternalName
LocalName -> InternalName
------------------------
For a long time there's been terminological confusion between
GlobalName vs LocalName (property of a Name)
GlobalId vs LocalId (property of an Id)
I've now changed the terminology for Name to be
ExternalName vs InternalName
I've also added quite a bit of documentation in the Commentary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
----------------------------------
Do the Right Thing for TyCons where we
can't see all their constructors.
----------------------------------
Inside a TyCon, three things can happen
1. GHC knows all the constructors, and has them to hand.
(Nowadays, there may be zero constructors.)
2. GHC knows all the constructors, but has declined to slurp
them all in, to avoid sucking in more declarations than
necessary. All we remember is the number of constructors,
so we can get the return convention right.
3. GHC doesn't know anything. This happens *only* for decls
coming from .hi-boot files, where the programmer declines to
supply a representation.
Until now, these three cases have been conflated together. Matters
are worse now that a TyCon really can have zero constructors. In
fact, by confusing (3) with (1) we can actually generate bogus code.
With this commit, the dataCons field of a TyCon is of type:
data DataConDetails datacon
= DataCons [datacon] -- Its data constructors, with fully polymorphic types
-- A type can have zero constructors
| Unknown -- We're importing this data type from an hi-boot file
-- and we don't know what its constructors are
| HasCons Int -- In a quest for compilation speed we have imported
-- only the number of constructors (to get return
-- conventions right) but not the constructors themselves
This says exactly what is going on. There are lots of consequential small
changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Switch over to the new hierarchical libraries
---------------------------------------------
This commit reorganises our libraries to use the new hierarchical
module namespace extension.
The basic story is this:
- fptools/libraries contains the new hierarchical libraries.
Everything in here is "clean", i.e. most deprecated stuff has
been removed.
- fptools/libraries/base is the new base package
(replacing "std") and contains roughly what was previously
in std, lang, and concurrent, minus deprecated stuff.
Things that are *not allowed* in libraries/base include:
Addr, ForeignObj, ByteArray, MutableByteArray,
_casm_, _ccall_, ``'', PrimIO
For ByteArrays and MutableByteArrays we use UArray and
STUArray/IOUArray respectively now.
Modules previously called PrelFoo are now under
fptools/libraries/GHC. eg. PrelBase is now GHC.Base.
- fptools/libraries/haskell98 provides the Haskell 98 std.
libraries (Char, IO, Numeric etc.) as a package. This
package is enabled by default.
- fptools/libraries/network is a rearranged version of
the existing net package (the old package net is still
available; see below).
- Other packages will migrate to fptools/libraries in
due course.
NB. you need to checkout fptools/libraries as well as
fptools/hslibs now. The nightly build scripts will need to be
tweaked.
- fptools/hslibs still contains (almost) the same stuff as before.
Where libraries have moved into the new hierarchy, the hslibs
version contains a "stub" that just re-exports the new version.
The idea is that code will gradually migrate from fptools/hslibs
into fptools/libraries as it gets cleaned up, and in a version or
two we can remove the old packages altogether.
- I've taken the opportunity to make some changes to the build
system, ripping out the old hslibs Makefile stuff from
mk/target.mk; the new package building Makefile code is in
mk/package.mk (auto-included from mk/target.mk).
The main improvement is that packages now register themselves at
make boot time using ghc-pkg, and the monolithic package.conf
in ghc/driver is gone.
I've updated the standard packages but haven't tested win32,
graphics, xlib, object-io, or OpenGL yet. The Makefiles in
these packages may need some further tweaks, and they'll need
pkg.conf.in files added.
- Unfortunately all this rearrangement meant I had to bump the
interface-file version and create a bunch of .hi-boot-6 files :-(
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
----------------------------------
Implement kinded type declarations
----------------------------------
This commit allows the programmer to supply kinds in
* data decls
* type decls
* class decls
* 'forall's in types
e.g. data T (x :: *->*) = MkT
type Composer c = forall (x :: * -> *) (y :: * -> *) (z :: * -> *).
(c y z) -> (c x y) -> (c x z);
This is occasionally useful.
It turned out to be convenient to add the form
(type :: kind)
to the syntax of types too, so you can put kind signatures in types as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*******************************
* Merging from ghc-ndp-branch *
*******************************
This commit merges the current state of the "parallel array extension" and
includes the following:
* (Almost) completed Milestone 1:
- The option `-fparr' activates the H98 extension for parallel arrays.
- These changes have a high likelihood of conflicting (in the CVS sense)
with other changes to GHC and are the reason for merging now.
- ToDo: There are still some (less often used) functions not implemented in
`PrelPArr' and a mechanism is needed to automatically import
`PrelPArr' iff `-fparr' is given. Documentation that should go into
the Commentary is currently in `ghc/compiler/ndpFlatten/TODO'.
* Partial Milestone 2:
- The option `-fflatten' activates the flattening transformation and `-ndp'
selects the "ndp" way (where all libraries have to be compiled with
flattening). The way option `-ndp' automagically turns on `-fparr' and
`-fflatten'.
- Almost all changes are in the new directory `ndpFlatten' and shouldn't
affect the rest of the compiler. The only exception are the options and
the points in `HscMain' where the flattening phase is called when
`-fflatten' is given.
- This isn't usable yet, but already implements function lifting,
vectorisation, and a new analysis that determines which parts of a module
have to undergo the flattening transformation. Missing are data structure
and function specialisation, the unboxed array library (including fusion
rules), and lots of testing.
I have just run the regression tests on the thing without any problems. So,
it seems, as if we haven't broken anything crucial.
|
| |
|
|
|
|
|
|
|
| |
Eliminate all vestiages of UsageTy, in preparation for
Keith's new version. Hurrah!
Keith: LBVarInfo and usOnce,usMany are still there,
because I know you have eliminated LBVarInfo, and I didn't
want to cause unnecessary conflicts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Foreign import/export declarations now conform to FFI Addendum Version 1.0
* The old form of foreign declarations is still supported, but generates
deprecation warnings.
* There are some rather exotic old-style declarations which have become
invalid as they are interpreted differently under the new scheme and there
is no (easy) way to determine which style the programmer had in mind (eg,
importing a C function with the name `wrapper' where the external name is
explicitly given will not work in some situations - depends on whether an
`unsafe' was specified and similar things).
* Some "new" old-style forms have been introduced to make parsing a little bit
easier (ie, avoid shift/reduce conflicts between new-style and old-style
grammar rules), but they are few, arcane, and don't really hurt (and I won't
tell what they are, you need to find that out by yourself ;-)
* The FFI Addendum doesn't specify whether a header file that is requested for
inclusion by multiple foreign declarations should be included only once or
multiple times. GHC at the moment includes an header as often as it appears
in a foreign declaration. For properly written headers, it doesn't make a
difference anyway...
* Library object specifications are currently silently ignored. The feature
was mainly requested for external calls in .NET (ie, calls which invoke C
routines when Haskell is compiled to ILX), but those don't seem to be
supported yet.
* Foreign label declarations are currently broken, but they were already
broken before I started messing with the stuff.
The code is moderately tested. All modules in lib/std/ and hslibs/lang/
(using old-style declarations) still compile fine and I have run a couple of
tests on the different forms of new-style declarations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-----------------------------
Tidy up the top level of TcModule
-----------------------------
This commit started life as sorting out the TcInstDcls thing that
we got wrong a few weeks back, but it spiraled out of control.
However, the result is a nice tidy up of TcModule.
typecheckModule/tcModule compiles a module from source code
typecheckIface/tcIface compiles a module from its interface file
typecheckStmt compiles a Stmt
typecheckExpr compiles a Expr
tcExtraDecls is used by typecheckStmt/typecheckExpr
to compile interface-file decls.
It is just a wrapper for:
tcIfaceImports, which is used by tcExtraDecls and tcIface
to compile interface file-file decls.
tcImports, is similar to tcIfaceImports, but is used only by tcModule
tcIfaceImports is used when compiling an interface, and can
therefore be quite a bit simpler
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------
Rule phasing
------------
This commit adds a little more control to when rules are enabled.
{-# RULES
"foo" [2] forall ...
"baz" [~2] forall ...
#-}
Rule "foo" is active in phase 2 and later. The new thing is that the
"~2" means that Rule "baz" is active in phase 3 and earlier.
(Remember tha phases decrease towards zero.)
All the machinery was there to implement this, it just needed the syntax.
Why do this? Peter Gammie (at UNSW) found that rules weren't firing
because of bindings of the form
M.f = f
f = ....
where the rules where on the M.f binding. It turned out that an old
hack (which have for some time elicited the harmless "shortMeOut" debug
warnings) prevented this trivial construction from being correctly
simplified. The hack in turn derived from a trick in the way the
foldr/build rule was implemented....and that hack is no longer necessary
now we can switch rules *off* as well as *on*.
There are consequential changes in the Prelude foldr/build RULE stuff.
It's a clean-up.... Instead of strange definitions like
map = mapList
which we had before, we have an ordinary recursive defn of map, together
with rules to convert first to foldr/build form, and then (if nothing
happens) back again.
There's a fairly long comment about the general plan of attack in
PrelBase, near the defn of map.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
---------------------------------------------
More type system extensions (for John Hughes)
---------------------------------------------
1. Added a brand-new extension that lets you derive ARBITRARY CLASSES
for newtypes. Thus
newtype Age = Age Int deriving( Eq, Ord, Shape, Ix )
The idea is that the dictionary for the user-defined class Shape Age
is *identical* to that for Shape Int, so there is really no deriving
work to do. This saves you writing the very tiresome instance decl:
instance Shape Age where
shape_op1 (Age x) = shape_op1 x
shape_op2 (Age x1) (Age x2) = shape_op2 x1 x2
...etc...
It's more efficient, too, becuase the Shape Age dictionary really
will be identical to the Shape Int dictionary.
There's an exception for Read and Show, because the derived instance
*isn't* the same.
There is a complication where higher order stuff is involved. Here is
the example John gave:
class StateMonad s m | m -> s where ...
newtype Parser tok m a = Parser (State [tok] (Failure m) a)
deriving( Monad, StateMonad )
Then we want the derived instance decls to be
instance Monad (State [tok] (Failure m)) => Monad (Parser tok m)
instance StateMonad [tok] (State [tok] (Failure m))
=> StateMonad [tok] (Parser tok m)
John is writing up manual entry for all of this, but this commit
implements it. I think.
2. Added -fallow-incoherent-instances, and documented it. The idea
is that sometimes GHC is over-protective about not committing to a
particular instance, and the programmer may want to say "commit anyway".
Here's the example:
class Sat a where
dict :: a
data EqD a = EqD {eq :: a->a->Bool}
instance Sat (EqD a) => Eq a where
(==) = eq dict
instance Sat (EqD Integer) where
dict = EqD{eq=(==)}
instance Eq a => Sat (EqD a) where
dict = EqD{eq=(==)}
class Collection c cxt | c -> cxt where
empty :: Sat (cxt a) => c a
single :: Sat (cxt a) => a -> c a
union :: Sat (cxt a) => c a -> c a -> c a
member :: Sat (cxt a) => a -> c a -> Bool
instance Collection [] EqD where
empty = []
single x = [x]
union = (++)
member = elem
It's an updated attempt to model "Restricted Data Types", if you
remember my Haskell workshop paper. In the end, though, GHC rejects
the program (even with fallow-overlapping-instances and
fallow-undecideable-instances), because there's more than one way to
construct the Eq instance needed by elem.
Yet all the ways are equivalent! So GHC is being a bit over-protective
of me, really: I know what I'm doing and I would LIKE it to pick an
arbitrary one. Maybe a flag fallow-incoherent-instances would be a
useful thing to add?
|
| |
|
|
|
|
|
|
|
|
| |
Strange: Removing getName (which should be accessible via NamedThing(..),
anyway) from the import list is necessary to make this module compile.
Otherwise we get:
hsSyn/HsCore.lhs:197: Variable not in scope: `getOccName'
Perhaps somebody could enlighten me what's going on here... %-]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--------------------------
Fix the instance-decl wart
--------------------------
This commit implements the (proposed) H98 rule for
resolving the class-method name in an instance decl.
module M( C( op1, op2 ) ) where
-- NB: op3 not exported
class C a where
op1, op2, op3 :: a -> a
module N where
import qualified M as P( C )
import qualified M as Q hiding( op2 )
instance P.C Int where
op1 x = x
-- op2, op3 both illegal here
The point is that
a) only methods that can be named are legal
in the instance decl
(so op2, op3 are not legal)
b) but it doesn't matter *how* they can be named
(in this case Q.op1 is in scope, though
the class is called P.C)
The AvailEnv carries the information about what's in scope,
so we now have to carry it around in the monad, so that
instance decl bindings can see it. Quite simple really.
Same deal for export lists. E.g.
module N( P.C( op1 ) ) where
import qualified M as P( C )
import qualified M as Q hiding( op2 )
Actually this is what GHC has always implemented!
|
| |
|
|
| |
Comments only
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------
Add linear implicit parameters
------------------------------
Linear implicit parameters are an idea developed by Koen Claessen,
Mark Shields, and Simon PJ, last week. They address the long-standing
problem that monads seem over-kill for certain sorts of problem, notably:
* distributing a supply of unique names
* distributing a suppply of random numbers
* distributing an oracle (as in QuickCheck)
Linear implicit parameters are just like ordinary implicit parameters,
except that they are "linear" -- that is, they cannot be copied, and
must be explicitly "split" instead. Linear implicit parameters are
written '%x' instead of '?x'. (The '/' in the '%' suggests the
split!)
For example:
data NameSupply = ...
splitNS :: NameSupply -> (NameSupply, NameSupply)
newName :: NameSupply -> Name
instance PrelSplit.Splittable NameSupply where
split = splitNS
f :: (%ns :: NameSupply) => Env -> Expr -> Expr
f env (Lam x e) = Lam x' (f env e)
where
x' = newName %ns
env' = extend env x x'
...more equations for f...
Notice that the implicit parameter %ns is consumed
once by the call to newName
once by the recursive call to f
So the translation done by the type checker makes
the parameter explicit:
f :: NameSupply -> Env -> Expr -> Expr
f ns env (Lam x e) = Lam x' (f ns1 env e)
where
(ns1,ns2) = splitNS ns
x' = newName ns2
env = extend env x x'
Notice the call to 'split' introduced by the type checker.
How did it know to use 'splitNS'? Because what it really did
was to introduce a call to the overloaded function 'split',
ndefined by
class Splittable a where
split :: a -> (a,a)
The instance for Splittable NameSupply tells GHC how to implement
split for name supplies. But we can simply write
g x = (x, %ns, %ns)
and GHC will infer
g :: (Splittable a, %ns :: a) => b -> (b,a,a)
The Splittable class is built into GHC. It's defined in PrelSplit,
and exported by GlaExts.
Other points:
* '?x' and '%x' are entirely distinct implicit parameters: you
can use them together and they won't intefere with each other.
* You can bind linear implicit parameters in 'with' clauses.
* You cannot have implicit parameters (whether linear or not)
in the context of a class or instance declaration.
Warnings
~~~~~~~~
The monomorphism restriction is even more important than usual.
Consider the example above:
f :: (%ns :: NameSupply) => Env -> Expr -> Expr
f env (Lam x e) = Lam x' (f env e)
where
x' = newName %ns
env' = extend env x x'
If we replaced the two occurrences of x' by (newName %ns), which is
usually a harmless thing to do, we get:
f :: (%ns :: NameSupply) => Env -> Expr -> Expr
f env (Lam x e) = Lam (newName %ns) (f env e)
where
env' = extend env x (newName %ns)
But now the name supply is consumed in *three* places
(the two calls to newName,and the recursive call to f), so
the result is utterly different. Urk! We don't even have
the beta rule.
Well, this is an experimental change. With implicit
parameters we have already lost beta reduction anyway, and
(as John Launchbury puts it) we can't sensibly reason about
Haskell programs without knowing their typing.
Of course, none of this is throughly tested, either.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--------------------------------------
Finally get rid of tcAddImportedIdInfo
--------------------------------------
TcEnv.tcAddImportedIdInfo is a notorious source of space leaks.
Simon M got rid of the need for it on default methods.
This commit gets rid of the need for it for dictionary function Ids,
and finally nukes the beast altogether. Hurrah!
The change really involves putting tcInterfaceSigs *before*
tcInstDecls1, so that any imported DFunIds are in the typechecker's
environment before we get to tcInstDecls.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
----------------------
Implement Rank-N types
----------------------
This commit implements the full glory of Rank-N types, using
the Odersky/Laufer approach described in their paper
"Putting type annotations to work"
In fact, I've had to adapt their approach to deal with the
full glory of Haskell (including pattern matching, and the
scoped-type-variable extension). However, the result is:
* There is no restriction to rank-2 types. You can nest forall's
as deep as you like in a type. For example, you can write a type
like
p :: ((forall a. Eq a => a->a) -> Int) -> Int
This is a rank-3 type, illegal in GHC 5.02
* When matching types, GHC uses the cunning Odersky/Laufer coercion
rules. For example, suppose we have
q :: (forall c. Ord c => c->c) -> Int
Then, is this well typed?
x :: Int
x = p q
Yes, it is, but GHC has to generate the right coercion. Here's
what it looks like with all the big lambdas and dictionaries put in:
x = p (\ f :: (forall a. Eq a => a->a) ->
q (/\c \d::Ord c -> f c (eqFromOrd d)))
where eqFromOrd selects the Eq superclass dictionary from the Ord
dicationary: eqFromOrd :: Ord a -> Eq a
* You can use polymorphic types in pattern type signatures. For
example:
f (g :: forall a. a->a) = (g 'c', g True)
(Previously, pattern type signatures had to be monotypes.)
* The basic rule for using rank-N types is that you must specify
a type signature for every binder that you want to have a type
scheme (as opposed to a plain monotype) as its type.
However, you don't need to give the type signature on the
binder (as I did above in the defn for f). You can give it
in a separate type signature, thus:
f :: (forall a. a->a) -> (Char,Bool)
f g = (g 'c', g True)
GHC will push the external type signature inwards, and use
that information to decorate the binders as it comes across them.
I don't have a *precise* specification of this process, but I
think it is obvious enough in practice.
* In a type synonym you can use rank-N types too. For example,
you can write
type IdFun = forall a. a->a
f :: IdFun -> (Char,Bool)
f g = (g 'c', g True)
As always, type synonyms must always occur saturated; GHC
expands them before it does anything else. (Still, GHC goes
to some trouble to keep them unexpanded in error message.)
The main plan is as before. The main typechecker for expressions,
tcExpr, takes an "expected type" as its argument. This greatly
improves error messages. The new feature is that when this
"expected type" (going down) meets an "actual type" (coming up)
we use the new subsumption function
TcUnify.tcSub
which checks that the actual type can be coerced into the
expected type (and produces a coercion function to demonstrate).
The main new chunk of code is TcUnify.tcSub. The unifier itself
is unchanged, but it has moved from TcMType into TcUnify. Also
checkSigTyVars has moved from TcMonoType into TcUnify.
Result: the new module, TcUnify, contains all stuff relevant
to subsumption and unification.
Unfortunately, there is now an inevitable loop between TcUnify
and TcSimplify, but that's just too bad (a simple TcUnify.hi-boot
file).
All of this doesn't come entirely for free. Here's the typechecker
line count (INCLUDING comments)
Before 16,551
After 17,116
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------------------
Improved handling of scoped type variables
------------------------------------------
The main effect of this commit is to allow scoped type variables
in pattern bindings, thus
(x::a, y::b) = e
This was illegal, but now it's ok. a and b have the same scope
as x and y.
On the way I beefed up the info inside a type variable
(TcType.TyVarDetails; c.f. IdInfo.GlobalIdDetails) which
helps to improve error messages. Hence the wide ranging changes.
Pity about the extra loop from Var to TcType, but can't be helped.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Pet peeve removal / code tidyup, replaced various sub-optimal
uses of 'length' with something a bit better, i.e., replaced
the following patterns
* length as `cmpOp` length bs
* length as `cmpOp` val -- incl. uses where val == 1 and val == 0
* {take,drop,splitAt} (length as) bs
* length [ () | pat <- as ]
with uses of misc Util functions.
I'd be surprised if there's a noticeable reduction in running
times as a result of these changes, but every little bit helps.
[ The changes have been tested wrt testsuite/ - I'm seeing a couple
of unexpected breakages coming from CorePrep, but I'm currently
assuming that these are due to other recent changes. ]
- compMan/CompManager.lhs: restored 4.08 compilability + some code
cleanup.
None of these changes are HEADworthy.
|
| |
|
|
| |
Rename ifaceTyCls to ifaceTyThing (more consistent)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------
Simon's big commit
------------------
[ These files seem to have been left out for some reason ]
This commit, which I don't think I can sensibly do piecemeal, consists
of the things I've been doing recently, mainly directed at making
Manuel, George, and Marcin happier with RULES.
Reogranise the simplifier
~~~~~~~~~~~~~~~~~~~~~~~~~
1. The simplifier's environment is now an explicit parameter. This
makes it a bit easier to figure out where it is going.
2. Constructor arguments can now be arbitrary expressions, except
when the application is the RHS of a let(rec). This makes it much
easier to match rules like
RULES
"foo" f (h x, g y) = f' x y
In the simplifier, it's Simplify.mkAtomicArgs that ANF-ises a
constructor application where necessary. In the occurrence analyser,
there's a new piece of context info (OccEncl) to say whether a
constructor app is in a place where it should be in ANF. (Unless
it knows this it'll give occurrence info which will inline the
argument back into the constructor app.)
3. I'm experimenting with doing the "float-past big lambda" transformation
in the full laziness pass, rather than mixed in with the simplifier (was
tryRhsTyLam).
4. Arrange that
case (coerce (S,T) (x,y)) of ...
will simplify. Previous it didn't.
A local change to CoreUtils.exprIsConApp_maybe.
5. Do a better job in CoreUtils.exprEtaExpandArity when there's an
error function in one branch.
Phase numbers, RULES, and INLINE pragmas
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Phase numbers decrease from N towards zero (instead of increasing).
This makes it easier to add new earlier phases, which is what users want
to do.
2. RULES get their own phase number, N, and are disabled in phases before N.
e.g. {-# RULES "foo" [2] forall x y. f (x,y) = f' x y #-}
Note the [2], which says "only active in phase 2 and later".
3. INLINE and NOINLINE pragmas have a phase number to. This is now treated
in just the same way as the phase number on RULE; that is, the Id is not inlined
in phases earlier than N. In phase N and later the Id *may* be inlined, and
here is where INLINE and NOINLINE differ: INLNE makes the RHS look small, so
as soon as it *may* be inlined it probably *will* be inlined.
The syntax of the phase number on an INLINE/NOINLINE pragma has changed to be
like the RULES case (i.e. in square brackets). This should also make sure
you examine all such phase numbers; many will need to change now the numbering
is reversed.
Inlining Ids is no longer affected at all by whether the Id appears on the
LHS of a rule. Now it's up to the programmer to put a suitable INLINE/NOINLINE
pragma to stop it being inlined too early.
Implementation notes:
* A new data type, BasicTypes.Activation says when a rule or inline pragma
is active. Functions isAlwaysActive, isNeverActive, isActive, do the
obvious thing (all in BasicTypes).
* Slight change in the SimplifierSwitch data type, which led to a lot of
simplifier-specific code moving from CmdLineOpts to SimplMonad; a Good Thing.
* The InlinePragma in the IdInfo of an Id is now simply an Activation saying
when the Id can be inlined. (It used to be a rather bizarre pair of a
Bool and a (Maybe Phase), so this is much much easier to understand.)
* The simplifier has a "mode" environment switch, replacing the old
black list. Unfortunately the data type decl has to be in
CmdLineOpts, because it's an argument to the CoreDoSimplify switch
data SimplifierMode = SimplGently | SimplPhase Int
Here "gently" means "no rules, no inlining". All the crucial
inlining decisions are now collected together in SimplMonad
(preInlineUnconditionally, postInlineUnconditionally, activeInline,
activeRule).
Specialisation
~~~~~~~~~~~~~~
1. Only dictionary *functions* are made INLINE, not dictionaries that
have no parameters. (This inline-dictionary-function thing is Marcin's
idea and I'm still not sure whether it's a good idea. But it's definitely
a Bad Idea when there are no arguments.)
2. Be prepared to specialise an INLINE function: an easy fix in
Specialise.lhs
But there is still a problem, which is that the INLINE wins
at the call site, so we don't use the specialised version anyway.
I'm still unsure whether it makes sense to SPECIALISE something
you want to INLINE.
Random smaller things
~~~~~~~~~~~~~~~~~~~~~~
* builtinRules (there was only one, but may be more) in PrelRules are now
incorporated. They were being ignored before...
* OrdList.foldOL --> OrdList.foldrOL, OrdList.foldlOL
* Some tidying up of the tidyOpenTyVar, tidyTyVar functions. I've
forgotten exactly what!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------
Simon's big commit
------------------
This commit, which I don't think I can sensibly do piecemeal, consists
of the things I've been doing recently, mainly directed at making
Manuel, George, and Marcin happier with RULES.
Reogranise the simplifier
~~~~~~~~~~~~~~~~~~~~~~~~~
1. The simplifier's environment is now an explicit parameter. This
makes it a bit easier to figure out where it is going.
2. Constructor arguments can now be arbitrary expressions, except
when the application is the RHS of a let(rec). This makes it much
easier to match rules like
RULES
"foo" f (h x, g y) = f' x y
In the simplifier, it's Simplify.mkAtomicArgs that ANF-ises a
constructor application where necessary. In the occurrence analyser,
there's a new piece of context info (OccEncl) to say whether a
constructor app is in a place where it should be in ANF. (Unless
it knows this it'll give occurrence info which will inline the
argument back into the constructor app.)
3. I'm experimenting with doing the "float-past big lambda" transformation
in the full laziness pass, rather than mixed in with the simplifier (was
tryRhsTyLam).
4. Arrange that
case (coerce (S,T) (x,y)) of ...
will simplify. Previous it didn't.
A local change to CoreUtils.exprIsConApp_maybe.
5. Do a better job in CoreUtils.exprEtaExpandArity when there's an
error function in one branch.
Phase numbers, RULES, and INLINE pragmas
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Phase numbers decrease from N towards zero (instead of increasing).
This makes it easier to add new earlier phases, which is what users want
to do.
2. RULES get their own phase number, N, and are disabled in phases before N.
e.g. {-# RULES "foo" [2] forall x y. f (x,y) = f' x y #-}
Note the [2], which says "only active in phase 2 and later".
3. INLINE and NOINLINE pragmas have a phase number to. This is now treated
in just the same way as the phase number on RULE; that is, the Id is not inlined
in phases earlier than N. In phase N and later the Id *may* be inlined, and
here is where INLINE and NOINLINE differ: INLNE makes the RHS look small, so
as soon as it *may* be inlined it probably *will* be inlined.
The syntax of the phase number on an INLINE/NOINLINE pragma has changed to be
like the RULES case (i.e. in square brackets). This should also make sure
you examine all such phase numbers; many will need to change now the numbering
is reversed.
Inlining Ids is no longer affected at all by whether the Id appears on the
LHS of a rule. Now it's up to the programmer to put a suitable INLINE/NOINLINE
pragma to stop it being inlined too early.
Implementation notes:
* A new data type, BasicTypes.Activation says when a rule or inline pragma
is active. Functions isAlwaysActive, isNeverActive, isActive, do the
obvious thing (all in BasicTypes).
* Slight change in the SimplifierSwitch data type, which led to a lot of
simplifier-specific code moving from CmdLineOpts to SimplMonad; a Good Thing.
* The InlinePragma in the IdInfo of an Id is now simply an Activation saying
when the Id can be inlined. (It used to be a rather bizarre pair of a
Bool and a (Maybe Phase), so this is much much easier to understand.)
* The simplifier has a "mode" environment switch, replacing the old
black list. Unfortunately the data type decl has to be in
CmdLineOpts, because it's an argument to the CoreDoSimplify switch
data SimplifierMode = SimplGently | SimplPhase Int
Here "gently" means "no rules, no inlining". All the crucial
inlining decisions are now collected together in SimplMonad
(preInlineUnconditionally, postInlineUnconditionally, activeInline,
activeRule).
Specialisation
~~~~~~~~~~~~~~
1. Only dictionary *functions* are made INLINE, not dictionaries that
have no parameters. (This inline-dictionary-function thing is Marcin's
idea and I'm still not sure whether it's a good idea. But it's definitely
a Bad Idea when there are no arguments.)
2. Be prepared to specialise an INLINE function: an easy fix in
Specialise.lhs
But there is still a problem, which is that the INLINE wins
at the call site, so we don't use the specialised version anyway.
I'm still unsure whether it makes sense to SPECIALISE something
you want to INLINE.
Random smaller things
~~~~~~~~~~~~~~~~~~~~~~
* builtinRules (there was only one, but may be more) in PrelRules are now
incorporated. They were being ignored before...
* OrdList.foldOL --> OrdList.foldrOL, OrdList.foldlOL
* Some tidying up of the tidyOpenTyVar, tidyTyVar functions. I've
forgotten exactly what!
|
| |
|
|
| |
Another case of parenthesising operator names, this time in a ConDecl.
|
| |
|
|
| |
Print implicit-parameter bindings properly
|
| |
|
|
|
|
|
|
|
|
|
| |
Prettier output for GHCi's :info
- put parenthesis around operators in type signatures
(both IfaceSig and ClassOpSig)
- don't use the cryptic '= ::' notation for indicating that a
class op has a default method, instead put the information in a
comment after the type.
|
| |
|
|
|
| |
Slight prettification of class declarations when printed out in
non-interface mode.
|
| |
|
|
| |
Don't print all the fields of a record on the same line
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
---------------------------------
Switch to the new demand analyser
---------------------------------
This commit makes the new demand analyser the main beast,
with the old strictness analyser as a backup. When
DEBUG is on, the old strictness analyser is run too, and the
results compared.
WARNING: this isn't thorougly tested yet, so expect glitches.
Delay updating for a few days if the HEAD is mission critical
for you.
But do try it out. I'm away for 2.5 weeks from Thursday, so
it would be good to shake out any glaring bugs before then.
|
| |
|
|
|
|
|
|
| |
This commit adds the very convenient function
Subst.substTyWith :: [TyVar] -> [Type] -> Type -> Type
and uses it in various places.
|
| |
|
|
| |
Move eqListBy to Util, and use it
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------------
Tidy up the "syntax rebinding" story
------------------------------------
I found a bug in the code that dealt with re-binding implicit
numerical syntax:
literals (fromInteger/fromRational)
negation (negate)
n+k patterns (minus)
This is triggered by the -fno-implicit-prelude flag, and it
used to be handled via the PrelNames.SyntaxMap.
But I found a nicer way to do it that involves much less code,
and doesn't have the bug. The explanation is with
RnEnv.lookupSyntaxName
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--------------------------------------------
Fix another bug in the squash-newtypes story.
--------------------------------------------
[This one was spotted by Marcin, and is now enshrined in test tc130.]
The desugarer straddles the boundary between the type checker and
Core, so it sometimes needs to look through newtypes/implicit parameters
and sometimes not. This is really a bit painful, but I can't think of
a better way to do it.
The only simple way to fix things was to pass a bit more type
information in the HsExpr type, from the type checker to the desugarer.
That led to the non-local changes you can see.
On the way I fixed one other thing. In various HsSyn constructors
there is a Type that is bogus (bottom) before the type checker, and
filled in with a real type by the type checker. In one place it was
a (Maybe Type) which was Nothing before, and (Just ty) afterwards.
I've defined a type synonym HsTypes.PostTcType for this, and a named
bottom value HsTypes.placeHolderType to use when you want the bottom
value.
|
| |
|
|
|
|
|
| |
Fix a missing case in kcHsType.
[Could be merged into 5.00.3, but we probably
aren't going to have such a thind.]
|
| |
|
|
| |
Import wibbles
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
----------------
Squash newtypes
----------------
This commit squashes newtypes and their coerces, from the typechecker
onwards. The original idea was that the coerces would not get in the
way of optimising transformations, but despite much effort they continue
to do so. There's no very good reason to retain newtype information
beyond the typechecker, so now we don't.
Main points:
* The post-typechecker suite of Type-manipulating functions is in
types/Type.lhs, as before. But now there's a new suite in types/TcType.lhs.
The difference is that in the former, newtype are transparent, while in
the latter they are opaque. The typechecker should only import TcType,
not Type.
* The operations in TcType are all non-monadic, and most of them start with
"tc" (e.g. tcSplitTyConApp). All the monadic operations (used exclusively
by the typechecker) are in a new module, typecheck/TcMType.lhs
* I've grouped newtypes with predicate types, thus:
data Type = TyVarTy Tyvar | ....
| SourceTy SourceType
data SourceType = NType TyCon [Type]
| ClassP Class [Type]
| IParam Type
[SourceType was called PredType.] This is a little wierd in some ways,
because NTypes can't occur in qualified types. However, the idea is that
a SourceType is a type that is opaque to the type checker, but transparent
to the rest of the compiler, and newtypes fit that as do implicit parameters
and dictionaries.
* Recursive newtypes still retain their coreces, exactly as before. If
they were transparent we'd get a recursive type, and that would make
various bits of the compiler diverge (e.g. things which do type comparison).
* I've removed types/Unify.lhs (non-monadic type unifier and matcher),
merging it into TcType.
Ditto typecheck/TcUnify.lhs (monadic unifier), merging it into TcMType.
|
| |
|
|
| |
Add an ext_name string to foreign dotnet types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--------------------------------------
Tidy up and improve "pattern contexts"
--------------------------------------
In various places (renamer, typechecker, desugarer) we need to know
what the context of a pattern match is (case expression, function defn,
let binding, etc). This commit tidies up the story quite a bit. I
think it represents a net decrease in code, and certainly it improves the
error messages from:
f x x = 3
Prevsiously we got a message like "Conflicting bindings for x in a pattern match",
but not it says "..in a defn of function f".
WARNING: the tidy up had a more global effect than I originally expected,
so it's possible that some other error messages look a bit peculiar. They
should be easy to fix, but tell us!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--------------------------
Allow data type declarations
to have zero constructors
--------------------------
This allows
data T a
as a data type declaration; i.e. allows zero constructors.
If there is an '=' sign there must be at least one constructor.
* Parser.y: parse the declaration
* HsDecls: print out the data type declaration right
* TyCon: don't ASSERT that the constructors are non-empty
|
| |
|
|
| |
Remove unused files.
|
| |
|
|
| |
Wibble for scoped type variables
|
