From: chak
-Last modified: Sat Nov 17 14:10:48 EST 2001
+Last modified: Mon Nov 26 19:23:12 EST 2001
diff --git a/ghc/docs/comm/rts-libs/primitives.html b/ghc/docs/comm/rts-libs/primitives.html
index bcd67e1..28abc79 100644
--- a/ghc/docs/comm/rts-libs/primitives.html
+++ b/ghc/docs/comm/rts-libs/primitives.html
@@ -37,9 +37,11 @@
As of (about) the development version 4.11, the types and various
properties of primitive operations are defined in the file
The utility
-Last modified: Wed Aug 8 19:29:12 EST 2001
+Last modified: Mon Nov 26 18:03:16 EST 2001
The Glasgow Haskell Compiler (GHC) Commentary [v0.5]
+ The Glasgow Haskell Compiler (GHC) Commentary [v0.6]
primops.txt
+ href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/prelude/primops.txt.pp">primops.txt.pp
.
(Personally, I don't think that the .txt
suffix is really
- appropriate, as the file is used for automatic code generation).
+ appropriate, as the file is used for automatic code generation; the
+ recent addition of .pp
means that the file is now mangled
+ by cpp.)
genprimopcode
@@ -61,7 +63,7 @@
for full details of how GHC is configured to cope with different machine word sizes.
+ Most of what the compiler has to have wired in about primitives and
+ prelude definitions is in
+ fptools/ghc/compiler/prelude/
.
+
+ Some types and functions have to be hardwired into the compiler as they + are atomic; all other code is essentially built around this primitive + functionality. This includes basic arithmetic types, such as integers, + and their elementary operations as well as pointer types. Primitive + types and functions often receive special treatment in the code + generator, which means that these entities have to be explicitly + represented in the compiler. Moreover, many of these types receive some + explicit treatment in the runtime system, and so, there is some further + information about primitives in + the RTS section of this document. +
+ The module TysPrim
+ exports a list of all primitive type constructors as primTyCons ::
+ [TyCon]
. All of these type constructors (of type
+ TyCon
) are also exported as intPrimTyCon
,
+ stablePtrPrimTyCon
, and so on. In addition, for each
+ nullary type constructor the corresponding type (of type
+ Type
) is also exported; for example, we have
+ intPrimTy :: Type
. For all other type constructors, a
+ function is exported that constructs the type obtained by applying the
+ type constructors to an argument type (of type Type
); for
+ example, we have mkStablePtrPrimTy :: Type -> Type
.
+
+ As it is inconvenient to identify type that receive a special treatment
+ by the code generator by looking at their name, the module PrimRep
+ exports a data type PrimRep
, which lists all
+ machine-manipulable implementation types. The module also exports a set
+ of query functions on PrimRep
that define properties, such
+ as a type's byte size or whether a primitive type is a pointer type.
+ Moreover, the function TysPrim.primRepTyCon :: PrimRep ->
+ TyCon
converts PrimRep
values into the corresponding
+ type constructor.
+
+
+ In addition to entities that are primitive, as the compiler has to treat
+ them specially in the backend, there is a set of types, functions,
+ etc. that the Haskell language definition flags as essential to the
+ language by placing them into the special module Prelude
+ that is implicitly imported into each Haskell module. For some of these
+ entities it suffices to define them (by standard Haskell definitions) in
+ a Prelude
module and ensuring that this module is treated
+ specially by being always imported .
+
+ However, there is a set of entities (such as, for example, the list type
+ and the corresponding data constructors) that have an inbetween status:
+ They are not truly primitive (lists, for example, can easily be defined
+ by a data
declaration), but the compiler has to have extra
+ knowledge about them, as they are associated with some particular
+ features of the language (in the case of lists, there is special syntax,
+ such as list comprehensions, associated with the type). Another
+ example, for a special kind of entity are type classes that can be used
+ in a deriving
clause. All types that are not-primitive,
+ but about which the compiler nonetheless has to have some extra
+ knowledge are defined in the module TysWiredIn
.
+
+ All wired in type constructors are contained in wiredInTyCons ::
+ [TyCon]
. In addition to that list, TysWiredIn
+ exports variables bound to representations of all listed type
+ constructors and their data constructors. So, for example, we have
+ listTyCon
together with nilDataCon and
+
consDataCon. There are also convenience functions, such
+ as mkListTy
and mkTupleTy
, which construct
+ compound types.
+
+ All names of types, functions, etc. known to the compiler are defined in
+ PrelNames
.
+ This includes the names of types and functions exported from
+ TysWiredIn
, but also others. In particular, this module
+ also fixes the names of all prelude modules; i.e., of the modules whose
+ name starts with Prel
, which GHC's library uses to bring
+ some structure into the quite large number of Prelude
+ definitions.
+
+ PrelNames.knownKeyNames :: [Name]
contains all names known
+ to the compiler, but the elements of the list are also exported
+ individually as variables, such as floatTyConName
(having
+ the lexeme Float
) and floatDataConName
(having
+ the lexeme F#
). For each of these names,
+ PrelNames
derfines a unique key with a definition, such as
+
+
++floatPrimTyConKey = mkPreludeTyConUnique 11+
+ that is, all unique keys for known prelude names are hardcoded into
+ PrelNames
(and uniqueness has to be manually ensured in
+ that module). To simplify matching the types of important groups of
+ type constructors, PrelNames
also exports lists, such as
+ numericTyKeys
(keys of all numeric types), that contain the
+ unique keys of all names in that group. In addition, derivable type
+ classes and their structure is defined by
+ derivableClassKeys
and related definitions.
+
+ In addition to names that have unique keys, PrelNames
also
+ defines a set of names without uniqueness information. These names end
+ on the suffix _RDR
and are of type RdrName
(an
+ example, is times_RDR
, which represents the lexeme
+ *
). The names are used in locations where they pass
+ through the renamer anyway (e.g., code generated from deriving clauses),
+ which will take care of adding uniqueness information.
+
+ The module
+ PrelInfo
+ in some sense ties all the above together and provides a reasonably
+ restricted interface to these definition to the rest of the compiler.
+ However, from what I have seen, this doesn't quite work out and the
+ earlier mentioned modules are directly imported in many places.
+
+
+ +Last modified: Mon Nov 26 19:29:33 EST 2001 + + +
diff --git a/ghc/docs/comm/the-beast/prelude.html b/ghc/docs/comm/the-beast/prelude.html new file mode 100644 index 0000000..dd9717e --- /dev/null +++ b/ghc/docs/comm/the-beast/prelude.html @@ -0,0 +1,138 @@ + + +
+ +
+ + +
+