version 0.7.8
This commit is contained in:
parent
08bc9ac03c
commit
db4f617afc
92 changed files with 3088 additions and 3477 deletions
|
|
@ -7,6 +7,8 @@ Module Description
|
|||
nimrod main module: parses the command line and calls
|
||||
``main.MainCommand``
|
||||
main implements the top-level command dispatching
|
||||
nimconf implements the config file reader
|
||||
|
||||
lexbase buffer handling of the lexical analyser
|
||||
scanner lexical analyser
|
||||
pnimsyn Nimrod's parser
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ symbol ::= '`' (KEYWORD | IDENT | operator | '(' ')'
|
|||
| '[' ']' | '=' | literal)+ '`'
|
||||
| IDENT
|
||||
primary ::= (prefixOperator optInd)* (symbol | constructor |
|
||||
| castExpr | addrExpr) (
|
||||
castExpr | addrExpr) (
|
||||
'.' optInd symbol
|
||||
| '(' optInd namedExprList [SAD] ')'
|
||||
| '[' optInd
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ The Nimrod project's directory structure is:
|
|||
Path Purpose
|
||||
============ ==============================================
|
||||
``bin`` binary files go into here
|
||||
``build`` generated C code for the installation
|
||||
``nim`` Pascal sources of the Nimrod compiler; this
|
||||
should be modified, not the Nimrod version in
|
||||
``rod``!
|
||||
|
|
@ -28,7 +29,7 @@ Path Purpose
|
|||
code go into here
|
||||
``doc`` the documentation lives here; it is a bunch of
|
||||
reStructuredText files
|
||||
``dist`` download packages as zip archives go into here
|
||||
``dist`` additional packages for the distribution
|
||||
``config`` configuration files for Nimrod go into here
|
||||
``lib`` the Nimrod library lives here; ``rod`` depends
|
||||
on it!
|
||||
|
|
@ -45,8 +46,8 @@ The compiler is written in a subset of Pascal with special annotations so
|
|||
that it can be translated to Nimrod code automatically. This conversion is
|
||||
done by Nimrod itself via the undocumented ``boot`` command. Thus both Nimrod
|
||||
and Free Pascal can compile the Nimrod compiler. However, the Pascal version
|
||||
has no garbage collector and leaks memory like crazy! So the Pascal version
|
||||
should only be used for bootstrapping.
|
||||
has no garbage collector and leaks memory! So the Pascal version should only
|
||||
be used for bootstrapping.
|
||||
|
||||
Requirements for bootstrapping:
|
||||
|
||||
|
|
@ -214,7 +215,7 @@ address within this page. So including a cell is done as follows:
|
|||
|
||||
Removing a cell is analogous - the bit has to be set to zero.
|
||||
Single page descriptors are never deleted from the hash table. This is not
|
||||
needed as the data structures need to be periodically rebuilt anyway.
|
||||
needed as the data structures needs to be rebuilt periodically anyway.
|
||||
|
||||
Complete traversal is done in this way::
|
||||
|
||||
|
|
@ -288,11 +289,8 @@ The synax tree consists of nodes which may have an arbitrary number of
|
|||
children. Types and symbols are represented by other nodes, because they
|
||||
may contain cycles. The AST changes its shape after semantic checking. This
|
||||
is needed to make life easier for the code generators. See the "ast" module
|
||||
for the type definitions.
|
||||
|
||||
I use the notation ``nodeKind(fields, [sons])`` for describing
|
||||
nodes. ``nodeKind[sons]`` is a short-cut for ``nodeKind([sons])``.
|
||||
XXX: Description of the language's syntax and the corresponding trees.
|
||||
for the type definitions. The `macros <macros.html>`_ module contains many
|
||||
examples how the AST represents each syntactic structure.
|
||||
|
||||
|
||||
How the RTL is compiled
|
||||
|
|
@ -310,6 +308,21 @@ semantic checking, a ``compilerproc`` is a proc that is used by the code
|
|||
generator.
|
||||
|
||||
|
||||
Debugging Nimrod's memory management
|
||||
====================================
|
||||
|
||||
The following paragraphs are mostly a reminder for myself. Things to keep
|
||||
in mind:
|
||||
|
||||
* Segmentation faults can have multiple reasons: One that is frequently
|
||||
forgotten is that *stack overflow* can trigger one!
|
||||
* If an assertion in Nimrod's memory manager or GC fails, the stack trace
|
||||
keeps allocating memory! Thus a stack overflow may happen, hiding the
|
||||
real issue.
|
||||
* What seem to be C code generation problems is often a bug resulting from
|
||||
not producing prototypes, so that some types default to ``cint``. Testing
|
||||
without the ``-w`` option helps!
|
||||
|
||||
|
||||
Generation of dynamic link libraries
|
||||
====================================
|
||||
|
|
|
|||
13
doc/lib.txt
13
doc/lib.txt
|
|
@ -22,6 +22,9 @@ Pure libraries
|
|||
implicitly by the compiler. Do not import it directly. It relies on compiler
|
||||
magic to work.
|
||||
|
||||
* `macros <macros.html>`_
|
||||
Contains the AST API and documentation of Nimrod for writing macros.
|
||||
|
||||
* `strutils <strutils.html>`_
|
||||
This module contains common string handling operations like converting a
|
||||
string into uppercase, splitting a string into substrings, searching for
|
||||
|
|
@ -33,6 +36,9 @@ Pure libraries
|
|||
commands, etc. This module is -- like any other basic library --
|
||||
platform independant.
|
||||
|
||||
* `osproc <osproc.html>`_
|
||||
Module for process communication beyond ``os.executeShellCommand``.
|
||||
|
||||
* `math <math.html>`_
|
||||
Mathematical operations like cosine, square root.
|
||||
|
||||
|
|
@ -60,6 +66,9 @@ Pure libraries
|
|||
to be somewhat error correcting, so that even some "wild HTML" found on the
|
||||
web can be parsed with it.
|
||||
|
||||
* `parsecsv <parsecsv.html>`_
|
||||
The ``parsecsv`` module implements a simple high performance CSV parser.
|
||||
|
||||
* `strtabs <strtabs.html>`_
|
||||
The ``strtabs`` module implements an efficient hash table that is a mapping
|
||||
from strings to strings. Supports a case-sensitive, case-insensitive and
|
||||
|
|
@ -98,6 +107,10 @@ Pure libraries
|
|||
* `md5 <md5.html>`_
|
||||
This module implements the MD5 checksum algorithm.
|
||||
|
||||
* `xmlgen <xmlgen.html>`_
|
||||
This module implements macros for HTML code generation.
|
||||
|
||||
|
||||
|
||||
Impure libraries
|
||||
================
|
||||
|
|
|
|||
|
|
@ -1649,7 +1649,7 @@ possible within a single ``type`` section.
|
|||
Generics
|
||||
~~~~~~~~
|
||||
|
||||
`Version 0.7.6: Generic types like in the example do not work.`:red:
|
||||
`Version 0.7.8: Generic types like in the example do not work.`:red:
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
500
doc/theindex.txt
500
doc/theindex.txt
File diff suppressed because it is too large
Load diff
|
|
@ -396,7 +396,7 @@ is not executed (if an exception occurs).
|
|||
Generics
|
||||
========
|
||||
|
||||
`Version 0.7.6: Complex generic types like in the example do not work.`:red:
|
||||
`Version 0.7.8: Complex generic types like in the example do not work.`:red:
|
||||
|
||||
`Generics`:idx: are Nimrod's means to parametrize procs, iterators or types
|
||||
with `type parameters`:idx:. They are most useful for efficient type safe
|
||||
|
|
@ -596,7 +596,8 @@ Nimrod's syntax is flexible enough anyway.
|
|||
`Macros`:idx: can be used to implement `domain specific languages`:idx:.
|
||||
|
||||
To write macros, one needs to know how the Nimrod concrete syntax is converted
|
||||
to an abstract syntax tree (AST). (Unfortunately the AST is not documented yet.)
|
||||
to an abstract syntax tree (AST). The AST is documented in the
|
||||
`macros <macros.html>`_ module.
|
||||
|
||||
There are two ways to invoke a macro:
|
||||
(1) invoking a macro like a procedure call (`expression macros`:idx:)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue