ghc/docs/release_notes/0-02-notes.lit

   1 \section[0-02-limitations]{Limitations of Glasgow \Haskell{}, release~0.02}
   2
   3 [Scribe for the 0.02 notes: Cordy Hall.]
   4
   5 These are the current major limitations of release~0.02,
   6 and a way to get around each if there is one.
   7
   8 \begin{enumerate}
   9 \item
  10 {\em Doesn't yet track version~1.1 of the \Haskell{} Report.}
  11 If you are lucky, sections might work anyway...
  12 \item
  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}):
  18 \begin{itemize}
  19 \item
  20 the boolean data type
  21 \item
  22 the string data type
  23 \item
  24 the primitive Haskell types, @Int@, @Char@, @Integer@, @Float@, @Double@
  25 \item
  26 function type
  27 \item
  28 list type
  29 \item
  30 tuple type (up to and including 5 tuples)
  31 \item
  32 random unboxed types (@IntPrim@, @StringPrim@, etc.)
  33 \item
  34 class @Eq@ with all operations, and the following instances:
  35 @Integer@, @Int@, @Rational@, @List@, @Char@, 2 tuple
  36 \item
  37 class @Ord@ with all operations, and the following instances:
  38 @Integer@, @Int@
  39 \item
  40 class @Num@ with all operations, and the following instances:
  41 @Integer@, @Int@, @Rational@
  42 \item
  43 class @Fractional@ with all operations, and the following instances:
  44 @Integer@, @Rational@
  45 \item
  46 cons @(:)@ and @[]@
  47 \end{itemize}
  48 \item
  49 {\em No renaming}
  50 \item
  51 {\em No selective export}
  52 \item
  53 {\em No re-export of imported entities}
  54 \item
  55 {\em No contexts in data declarations}
  56 \item
  57 {\em No ambiguity resolution for numeric types}
  58 \item
  59 {\em No overloaded numeric patterns or @n+k@ patterns}
  60 \item
  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
  64
  65 \begin{verbatim}
  66 data T a = D (B a) | C
  67 data B b = X | Y b
  68 \end{verbatim}
  69
  70 then you would write
  71
  72 \begin{verbatim}
  73 import MiniPrel
  74
  75 data T a = D (B a) | C
  76 data B b = X | Y b
  77
  78 instance (Eq a) => Eq (T a) where
  79  (D x) == (D y) = x == y
  80  C == C = True
  81  a == b = False
  82
  83  a /= b = not (a == b)
  84
  85 instance (Eq b) => Eq (B b) where
  86  X == X = True
  87  (Y a) == (Y b) = a == b
  88  a == b = False
  89
  90  a /= b = not (a == b)
  91 \end{verbatim}
  92
  93 The reason that @MiniPrel@ is imported is that it provides a type for @not@.
  94 \item
  95 {\em No default methods in class declarations}
  96 \end{enumerate}
  97
  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
 101 typechecker.
 102
 103 Other limitations:
 104 \begin{itemize}
 105 \item
 106 Error messages need lots of improvement.
 107 \item
 108 The generated code is inefficient, and it takes a long time to generate it.
 109 \item
 110 Documentation is minimal.
 111 \item
 112 The only programs that compile and run are those for which @main@ has
 113 type @Int@!!!  Examples in \tr{compiler/tests/codeGen}...
 114 \end{itemize}
 115
 116 \section[0-02-new-tools]{New Tools}
 117
 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
 122 following approach:
 123
 124 \begin{enumerate}
 125 \item
 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.
 129
 130 \item
 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.
 134
 135 \item
 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.
 140 \end{enumerate}
 141
 142 For example, in the following program
 143
 144 \begin{verbatim}
 145 f x = ((g :: tyreq1) 'a',(g :: tyreq2) True)
 146       where
 147       g x = x
 148 \end{verbatim}
 149
 150 the type variables @tyreq1@ and @tyreq2@ are seen as special by the compiler.
 151 The program printed out is:
 152
 153 \begin{verbatim}
 154 f x = ((g :: Char -> Char) 'a',(g :: Bool -> Bool) True)
 155       where
 156       g x = x
 157 \end{verbatim}
 158
 159 If the program was instead
 160
 161 \begin{verbatim}
 162 f x = (g 'a', True)
 163       where
 164       g :: tyreq1
 165       g x = x
 166 \end{verbatim}
 167
 168 then the program printed out would be
 169
 170 \begin{verbatim}
 171 f x = (g 'a', g True)
 172       where
 173       g :: a -> a
 174       g x = x
 175 \end{verbatim}
 176
 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@.
 180
 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.}
 189
 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}
 194 flag.
 195
 196 If you do use this and/or have any comments to make, please email to
 197 cvh\@dcs.glasgow.ac.uk.
 198
 199 \section[0-02-instabilities]{Known instabilities in the compiler internals}
 200
 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.
 204
 205 \begin{enumerate}
 206 \item
 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.
 211
 212 \item
 213 A major overhaul of the pretty-printing and error-reporting machinery.
 214
 215 \item
 216 A major overhaul of the ``make world'' machinery.  Ideas welcome.
 217
 218 \item
 219 A fairly significant module-renaming exercise.  A proposal, not yet
 220 agreed, is in \tr{docs/FILE-RENAMING}.
 221 \end{enumerate}
 222
 223 \section[0-02-other-problems]{Other known problems in the distribution}
 224
 225 The GNU Info-file reader (\tr{literate/info-utils/info.c}) is an
 226 unusually buggy version, for some reason.
 227
 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
 230 the test files.