83 lines
2.7 KiB
Markdown
83 lines
2.7 KiB
Markdown
|
+++
|
||
|
|
title = "Packages"
|
||
|
|
weight = 3
|
||
|
|
sort_by = "weight"
|
||
|
|
insert_anchor_links = "right"
|
||
|
|
+++
|
||
|
|
|
||
|
|
Packages are the outermost constructs in BH--- all BH code must be
|
||
|
|
inside packages. There should be one package per file. A BH package is a
|
||
|
|
linguistic device for namespace control, and is particularly useful for
|
||
|
|
programming-in-the-large. A package does not directly correspond to
|
||
|
|
hardware modules. (Hardware modules correspond to BH modules, described
|
||
|
|
in section [5.13](fixme))
|
||
|
|
|
||
|
|
|
||
|
|
A BH package consists of the package header, import declarations, and
|
||
|
|
top level definitions. The package header indicates which names defined
|
||
|
|
in this package are exported, *i.e.,* available for import into other
|
||
|
|
packages.
|
||
|
|
|
||
|
|
```
|
||
|
|
packageDefn ::= package packageId ( exportDecl ) where {
|
||
|
|
{ importDecl ; }
|
||
|
|
{ fixityDecl ; }
|
||
|
|
{ topDefn ; }
|
||
|
|
}
|
||
|
|
exportDecl ::= varId |typeId [ conList ]
|
||
|
|
conList ::= (..)
|
||
|
|
importDecl ::= import [ qualified ] packageId
|
||
|
|
fixityDecl ::= fixity integer varId
|
||
|
|
fixity ::= infix |infixl |infixr
|
||
|
|
packageId ::= conId
|
||
|
|
```
|
||
|
|
|
||
|
|
Example:
|
||
|
|
|
||
|
|
```hs
|
||
|
|
package Foo (x, y) where
|
||
|
|
import Bar
|
||
|
|
import Glurph
|
||
|
|
|
||
|
|
-- top level definition ...
|
||
|
|
-- top level definition ...
|
||
|
|
-- top level definition ...
|
||
|
|
```
|
||
|
|
|
||
|
|
Here, `Foo` is the name of this package, `x` and `y`
|
||
|
|
are names exported from this package (they will be defined amongst the
|
||
|
|
top level definitions in this package), and `Bar` and `Glurph` are the
|
||
|
|
names of package being imported (for use in this package).
|
||
|
|
|
||
|
|
|
||
|
|
The export list is a list of identifiers, each optionally followed by
|
||
|
|
`(..)`. Each identifier in the list will be visible outside the package.
|
||
|
|
If the exported identifier is the name of `data`, `struct`, or
|
||
|
|
`interface`, then the constructors or fields of the type will be visible
|
||
|
|
only if `(..)` is used. Otherwise, if you export only the name of a type
|
||
|
|
without the `(..)` suffix, the type is an abstract (opaque) data type
|
||
|
|
outside the package. The list of identifiers may include identifiers
|
||
|
|
defined in the package as well as identifiers imported from other
|
||
|
|
packages.
|
||
|
|
|
||
|
|
|
||
|
|
If the keyword `qualified` is present in the import declaration all the
|
||
|
|
imported entities from that package must be referred to by a qualified
|
||
|
|
name.
|
||
|
|
|
||
|
|
|
||
|
|
The fixity declaration can be used to give a precedence level to a
|
||
|
|
user-defined infix operator. The `infixl` specifies a left associative
|
||
|
|
operator, `infixr` a right associative operator, and `infix` a
|
||
|
|
non-associative operator.
|
||
|
|
|
||
|
|
|
||
|
|
## Name clashes and qualified names
|
||
|
|
|
||
|
|
|
||
|
|
When used in any scope, a name must have an unambiguous meaning. If
|
||
|
|
there is name clash for a name $x$ because it is defined in the current
|
||
|
|
package and/or it is available from one or more imported packages, then
|
||
|
|
the ambiguity can be resolved by using a qualified name of the form
|
||
|
|
$M.x$ to refer to the version of $x$ contained in package $M$.
|