dangerous. My goal is to control that power without extinguishing it,
so they become powerful with more clarity, and without the danger.
-Pointers have always been overloaded - the can store either a pointer
+Pointers have always been overloaded - they can store either a pointer
to an actual object, or a 'nil' (or 'NULL') pointer, which isn't an
object and cannot be dereferenced safely. This provides power (it
enables simple finite linked lists) and danger (it is too easy to try
As well as allowing `nil`, it is sometimes useful to allow other
non-pointer values to be stored in a pointer object. The Linux kernel
-does this a lot, and the are two specific cases that are used.
+does this a lot, and there are two specific cases that are used.
In the first case, small integers (normally negative) can be stored in
a pointer variable. These are used as error codes. As the first page
of virtual memory and also the last page are not mapped, any pointer
Linux kernel uses these in hashtables that support lockless lookups
and movement of entries between chains. The loaded value is treated
like a `nil` pointer, but records which hash chain has come to an
-end. If a search find the wrong hash value at the end of the chain,
+end. If a search finds the wrong hash value at the end of the chain,
it know that it might have been diverted between chains and needs to
re-check.
-The odd pointer values can also be used in a different way. In each
+The odd pointer values can also be used in a different way. Instead
of indicating a different interpretation of the whole pointer, the
least significant bit can be treated as a separate value that is
stored in the pointer - to optimize space usage. A particular use for
this natively by allowing a field on a structure to be identified as
reference counter, but it will allow other options as well.
-Points can be classified as either "owned" or "borrowed" references.
+Pointers can be classified as either "owned" or "borrowed" references.
This will probably be determined dynamically from code analysis,
though in some cases such as function parameters and returns, it must
be declared. An owned reference is one that holds a reference count
primary, so both (or all) possible primaries must be preserved.
The "Scope" of the borrowed reference that the owned reference must be
-preserved for will often a a lexical scope, but may not always be. I
-imaging that the language may at some stage be able describe other
+preserved for will often be a lexical scope, but may not always be. I
+imagine that the language may at some stage be able describe other
temporal relationships between different objects. In that case, the
borrowed reference must have a life time contained within the
guaranteed lifetime of the matching borrowed pointer.
I should say that "Garbage collection" will be an option, just not the
-only or the default. Language can potentially identify exactly the
+only or the default. The language can potentially identify exactly the
references that need to be checked. Maybe collectable pointers
reserve the lsb for mark, prior to sweep.
compiler would extract a description of places that gc refs can live,
code / ocean-D / blobdiff