1 \section[0-02-limitations]{Limitations of Glasgow \Haskell{}, release~0.02}
3 [Scribe for the 0.02 notes: Cordy Hall.]
5 These are the current major limitations of release~0.02,
6 and a way to get around each if there is one.
10 {\em Doesn't yet track version~1.1 of the \Haskell{} Report.}
11 If you are lucky, sections might work anyway...
13 {\em No automatic importation of Prelude.} You can add an import of
14 module @MiniPrel@, which is in \tr{lib/prelude/MiniPrel.hi}, and
15 extend your own version of this file as you wish as long as you do not
16 add anything currently built into the compiler. The following are
17 already built in (see \tr{compiler/typecheck/PrelCoreEnv.lhs}):
24 the primitive Haskell types, @Int@, @Char@, @Integer@, @Float@, @Double@
30 tuple type (up to and including 5 tuples)
32 random unboxed types (@IntPrim@, @StringPrim@, etc.)
34 class @Eq@ with all operations, and the following instances:
35 @Integer@, @Int@, @Rational@, @List@, @Char@, 2 tuple
37 class @Ord@ with all operations, and the following instances:
40 class @Num@ with all operations, and the following instances:
41 @Integer@, @Int@, @Rational@
43 class @Fractional@ with all operations, and the following instances:
51 {\em No selective export}
53 {\em No re-export of imported entities}
55 {\em No contexts in data declarations}
57 {\em No ambiguity resolution for numeric types}
59 {\em No overloaded numeric patterns or @n+k@ patterns}
61 {\em No deriving clause on data type declarations.} You can get around this
62 by creating explicit instances for the data type. For example, if you wanted
63 to derive @Eq@ for the data type
66 data T a = D (B a) | C
75 data T a = D (B a) | C
78 instance (Eq a) => Eq (T a) where
79 (D x) == (D y) = x == y
85 instance (Eq b) => Eq (B b) where
87 (Y a) == (Y b) = a == b
93 The reason that @MiniPrel@ is imported is that it provides a type for @not@.
95 {\em No default methods in class declarations}
98 So far, operations on @Int@s will have code generated for them
99 but more work needs to be done to handle other types
100 in the code generator. However, all of the above should be handled by the
106 Error messages need lots of improvement.
108 The generated code is inefficient, and it takes a long time to generate it.
110 Documentation is minimal.
112 The only programs that compile and run are those for which @main@ has
113 type @Int@!!! Examples in \tr{compiler/tests/codeGen}...
116 \section[0-02-new-tools]{New Tools}
118 Programs with type errors can be difficult to correct
119 without some help. Unfortunately, providing this help is a difficult research
120 problem. Wand's recent POPL paper suggests an interesting approach, but it
121 costs overhead even when the code typechecks. Instead, we've taken the
126 People who program in functional languages like interpreters because they
127 can find out how a small function behaves, and then deduce how it will
128 behave in a larger context.
131 Type checking is rather like debugging, so it would be nice to give the user
132 something that would allow probing of function and expression types
133 within the context of the rest of the program.
136 To do this, we allow the user to attach a special type variable as a
137 signature to any function definition or expression of interest. The
138 typechecker can then textually substitute the type of that expression for
139 the signature, and print out the original program.
142 For example, in the following program
145 f x = ((g :: tyreq1) 'a',(g :: tyreq2) True)
150 the type variables @tyreq1@ and @tyreq2@ are seen as special by the compiler.
151 The program printed out is:
154 f x = ((g :: Char -> Char) 'a',(g :: Bool -> Bool) True)
159 If the program was instead
168 then the program printed out would be
171 f x = (g 'a', g True)
177 A note about these `special type variables'---the user must guarantee
178 (at present) that each is unique, and that each
179 begins with the string @tyreq@.
181 At present, the typechecker fails whenever there is a type error. Once
182 it can be made to succeed on errors, handing control to something
183 which can deal with this situation, then it will be easy to get some
184 idea of what the typechecker thought about interesting expressions in
185 the code, even though these types may not yet be fully defined. {\em For
186 now, this tool is really only useful if you have a program that does
187 typecheck (avoiding failure) but you wish to examine some of the types
188 of the program's expressions.}
190 To use this feature, the compiler must be built using the
191 \tr{-DTYPE_ERROR_HELP}
192 flag (change \tr{compiler/Jmakefile} in the appropriate place). When
193 invoking the driver \tr{driver/ghc}, use the \tr{-ddump-type-error}
196 If you do use this and/or have any comments to make, please email to
197 cvh\@dcs.glasgow.ac.uk.
199 \section[0-02-instabilities]{Known instabilities in the compiler internals}
201 Here are some things we know we are going to change in the internals
202 of the compiler. Fellow developers may want to query these if they
203 think that they may be adversely affected.
207 A modest revision to the basic data types for variables, constructors,
208 and type variables (currently in \tr{compiler/names/{Local,Global}.lhs}
209 and in \tr{compiler/absSyntax/UniType.lhs}). See
210 \tr{compiler/names/Id.lhs} for our notes on what to do.
213 A major overhaul of the pretty-printing and error-reporting machinery.
216 A major overhaul of the ``make world'' machinery. Ideas welcome.
219 A fairly significant module-renaming exercise. A proposal, not yet
220 agreed, is in \tr{docs/FILE-RENAMING}.
223 \section[0-02-other-problems]{Other known problems in the distribution}
225 The GNU Info-file reader (\tr{literate/info-utils/info.c}) is an
226 unusually buggy version, for some reason.
228 The tests files have been stripped out of this release, merely to
229 reduce the sheer volume of the distribution. Let us know if you want