blob: d41317a10e5e3abd05cf63e1f2be2dab6ffc089d (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
Jump into a development shell:
nix-shell
Then run `help` to see the dev commands.
The source tree maps to the module namespace, and roughly follows the
Haskell namespace hierarchy (although nothing is enforced). The main
'common' space is `Biz`, other namespaces should be related to their
application.
Development aspects should be localized to their sub-namespaces as much
as possible. Only after sufficient iteration such that interfaces are
solidified and functionality is well-established should some code be
promoted up the namespace hierarchy. The one special namespace/directory
is `nix` which has all of our build rules.
Boundaries and interfaces between namespaces should be small and
well-defined. Likewise, the functionality and purpose of a particular
namespace should be small and well-defined. Following the unix principle
of "do one thing and do it well" is advised.
For building the code, we use `nix` and basically copy the namespace
hierarchy into the main build file `./default.nix`.
Namespaces are always capitalized. I would prefer always lowercase, but
`ghc` _really_ wants capitalized files, so we appeas `ghc`. In Scheme
this actually translates quite well and helps distinguish between types
and values.
File extensions denote _type_ and indicate to the build system how to
handle the file. So for example:
- `.hs` is Haskell source code, the build system compiles it
- `.scm` is Scheme source code, ditto
- `.org` is an organizational text document, the build system ignores
this, but we use them to make plans and such
- `.jnl` is a journal for accounting, the build system will check our
balances, make sure we're profitable
|
