Update vector space
parent
155c77cecb
commit
59bcbf55d5
|
@ -51,6 +51,10 @@ A thought which has recently occurred to me is that the mark bit could be the ca
|
|||
|
||||
I really don't at this point have any idea what sorts of things we'll want to store in vector space. This is a non-exhaustive list of things I can think of just now.
|
||||
|
||||
### BMAP
|
||||
|
||||
A bitmap; a monochrome raster; a two dimensional vector of bits.
|
||||
|
||||
### EXEC
|
||||
|
||||
We definitely need chunks of executable code - compiled functions.
|
||||
|
@ -66,3 +70,11 @@ In either case, anything which held a pointer to the old version still sees the
|
|||
A namespace. A namespace is a hashtable with some extra features. It has a parent pointer: NIL in the case of a namespace which was not created by 'adding to' or 'modifying' a pre-existing one, but where a pre-existing one was acted on, then that pre-existing one. It also must have an additional access control list, for users entitled to create new canonical versions of this namespace.
|
||||
|
||||
A lot of thinking needs to be done here. It's tricky. If I get it wrong, the cost to either performance or security or both will be horrible.
|
||||
|
||||
### RSTR
|
||||
|
||||
A raster; a two dimensional vector of 32 bit integers, typically interpreted as RGBA colour values.
|
||||
|
||||
### VECT
|
||||
|
||||
An actual vector. Has a finite number of dimensions, but probably not more than 4,294,967,296 will be supported (i.e. 32 bits for `dimensions`).
|
Loading…
Reference in a new issue