- Cvs-nhc98 - Haskell.org

Remove bug in type checker and addition of some error mess
by olaf＠sparud.net 20 Feb '03

20 Feb '03

olaf: Thu Feb 20 19:23:29 CET 2003 Update of /usr/src/master/nhc/src/compiler98 In directory hinken:/tmp/cvs-serv12039/src/compiler98 Modified Files: Derive.hs RenameLib.hs Type.hs TypeCtx.hs TypeUnify.hs Log Message: Remove bug in type checker and addition of some error messages. Type unification in TypeUnify was wrong! Given two types c t1 ... tn and c s1 ... sn unification would just unify the two list of arguments. However, if c is a type synonym, this is wrong! A type synonym always has to be expanded. Example: type T a = Int Then unifying T Bool and T Int should not force unification of Bool and Int! With the removal of this bug the Hat transformed Prelude type checks again in nhc98 (instead of producing obscure error "The class Main.Integral has no instance for the type Hat.Hat.List.") Also extended error message "The class ... has no instance for the type ..." so that it gives additional position information. Furthermore the renamer (defineDefaultMethod) did fall over if a method was also declared outside of the class. Now an appropriate error message is produced.

1 0

Remove bug in type checker and addition of some error mess
by olaf＠sparud.net 20 Feb '03

20 Feb '03

olaf: Thu Feb 20 19:23:30 CET 2003 Update of /usr/src/master/nhc/src/hat/lib In directory hinken:/tmp/cvs-serv12039/src/hat/lib Modified Files: PreludeBasic.hs Log Message: Remove bug in type checker and addition of some error messages. Type unification in TypeUnify was wrong! Given two types c t1 ... tn and c s1 ... sn unification would just unify the two list of arguments. However, if c is a type synonym, this is wrong! A type synonym always has to be expanded. Example: type T a = Int Then unifying T Bool and T Int should not force unification of Bool and Int! With the removal of this bug the Hat transformed Prelude type checks again in nhc98 (instead of producing obscure error "The class Main.Integral has no instance for the type Hat.Hat.List.") Also extended error message "The class ... has no instance for the type ..." so that it gives additional position information. Furthermore the renamer (defineDefaultMethod) did fall over if a method was also declared outside of the class. Now an appropriate error message is produced.

1 0

Update `harch` for newer Linux versions which can report '
by malcolm＠sparud.net 13 Feb '03

13 Feb '03

malcolm: Thu Feb 13 19:08:43 CET 2003 Update of /usr/src/master/nhc/script In directory hinken:/tmp/cvs-serv6427 Modified Files: harch Log Message: Update `harch` for newer Linux versions which can report 'athlon' instead of 'i686'.

1 0

Obtain also type signature for worker from type signature
by olaf＠sparud.net 13 Feb '03

13 Feb '03

olaf: Thu Feb 13 18:05:55 CET 2003 Update of /usr/src/master/nhc/src/hat/trans In directory hinken:/tmp/cvs-serv5827/src/hat/trans Modified Files: AuxFile.hs AuxLabelAST.hs AuxTypes.hs TraceId.hs TraceTrans.hs Log Message: Obtain also type signature for worker from type signature for a function. Type signatures for workers are needed after introduction of the known-arity optimisation. The known-arity optimisation requires that workers of functions with known arity are defined on the same level as their wrapper, not local to them. If the original function was recursive, the worker will be recursive instead of calling the wrapper (as without known-arity opt.). Hence if the original definition had a type signature, then the worker needs a type signature as well (the wrapper gets one anyway), because otherwise its inferred type might not be general enough (polymorphic recursion) or too general (type class ambiguities, problems with existential types). Transformation of the original type signature into the worker type signature is not uniform: function types are handled specially. So if the type includes a type synonym it may not be possible to use the transformed type synonym, but the original one has to be expanded and transformed in this non-uniform way. However, in general a type synonym cannot be expanded, because the rhs might not be in scope at the synonym use site. Hence a type synonym is split into an outer part consisting of function types,type applications and type variables, which can and may need to be expanded, and several inner type parts, for which new helper type synonyms are defined. These are always ex- and imported with the type synonym itself. A lot of effort, but it does work in the end.

1 0

Obtain also type signature for worker from type signature
by olaf＠sparud.net 13 Feb '03

13 Feb '03

olaf: Thu Feb 13 18:05:53 CET 2003 Update of /usr/src/master/nhc/src/hat/lib In directory hinken:/tmp/cvs-serv5827/src/hat/lib Modified Files: Makefile Log Message: Obtain also type signature for worker from type signature for a function. Type signatures for workers are needed after introduction of the known-arity optimisation. The known-arity optimisation requires that workers of functions with known arity are defined on the same level as their wrapper, not local to them. If the original function was recursive, the worker will be recursive instead of calling the wrapper (as without known-arity opt.). Hence if the original definition had a type signature, then the worker needs a type signature as well (the wrapper gets one anyway), because otherwise its inferred type might not be general enough (polymorphic recursion) or too general (type class ambiguities, problems with existential types). Transformation of the original type signature into the worker type signature is not uniform: function types are handled specially. So if the type includes a type synonym it may not be possible to use the transformed type synonym, but the original one has to be expanded and transformed in this non-uniform way. However, in general a type synonym cannot be expanded, because the rhs might not be in scope at the synonym use site. Hence a type synonym is split into an outer part consisting of function types,type applications and type variables, which can and may need to be expanded, and several inner type parts, for which new helper type synonyms are defined. These are always ex- and imported with the type synonym itself. A lot of effort, but it does work in the end.

1 0

Import error in the non-readline version.
by malcolm＠sparud.net 12 Feb '03

12 Feb '03

malcolm: Wed Feb 12 11:01:28 CET 2003 Update of /usr/src/master/nhc/src/hat/tools In directory hinken:/tmp/cvs-serv14805 Modified Files: CmdLine.hs Log Message: Import error in the non-readline version.

1 0

Fix a bug in counting applications of a constructor with f
by malcolm＠sparud.net 11 Feb '03

11 Feb '03

malcolm: Tue Feb 11 20:02:01 CET 2003 Update of /usr/src/master/nhc/src/hat/tools In directory hinken:/tmp/cvs-serv3994 Modified Files: hat-names.c observeutils.c Log Message: Fix a bug in counting applications of a constructor with fields. (The constructor's arity was being stored wrongly as 0.)

1 0

Make string truncation in a browser "blue", by representin
by malcolm＠sparud.net 11 Feb '03

11 Feb '03

malcolm: Tue Feb 11 20:00:43 CET 2003 Update of /usr/src/master/nhc/src/hat/tools In directory hinken:/tmp/cvs-serv3941 Modified Files: Pattern.hs TExp.hs SExp.hs Log Message: Make string truncation in a browser "blue", by representing the ellipsis explicitly as a boolean field of SString, rather than implicitly within the string itself.

1 0

Add readline functionality to hat-observe commandlines, if
by malcolm＠sparud.net 11 Feb '03

11 Feb '03

malcolm: Tue Feb 11 14:54:19 CET 2003 Update of /usr/src/master/nhc/src/hat/tools In directory hinken:/tmp/cvs-serv776 Modified Files: HatObserve.hs Makefile Added Files: CmdLine.hs Log Message: Add readline functionality to hat-observe commandlines, if readline is available (i.e. currently only with ghc).

1 0

Remove the space between a constructor/variable and any na
by malcolm＠sparud.net 11 Feb '03

11 Feb '03

malcolm: Tue Feb 11 13:07:46 CET 2003 Update of /usr/src/master/nhc/src/hat/tools In directory hinken:/tmp/cvs-serv29157 Modified Files: SExp.hs Log Message: Remove the space between a constructor/variable and any named fields that follow it, for human-parsability. Some people find an expression like f V {num=1} W {val=2} slightly confusing, where f V{num=1} W{val=2} would be clearer. (Named field syntax binds more tightly than application by juxtaposition.)

1 0