If you allocate a vector on the stack and default initialise
it (i.e. {0}), then by default "is_inlined" = 0. This is bad, as
technically speaking we should expect the vector to attempt to use
it's small inline buffer for vector operations before going onto the
heap - this will mess up our functions. So here I adjust the name to
make default stack based allocation a bit easier.
Since most use cases require indexing the data directly, and the macro
implies you're retrieving data from it, may as well take the index.
If you wanted a pointer to that data, &VEC_GET(vec, index, type) works
just fine.
Easier to iterate through, O(1) amortized registering just like the
Linked List.
VEC_SIZE just makes it easier to iterate through a vector of specially
typed elements.
Main reason to have this at all is to make char-by-char reading
feasible. This occurs at `stream_chunk`, and previously if we passed
in STDIN for `stream_init_file`, STDIN will only terminate once
STREAM_DEFAULT_CHUNK number of characters have been fed into the pipe.
This isn't desirable for STDIN (we really want to read char-by-char
for expressions), nor would it necessarily be desirable in network
applications. So any stream marked STREAM_TYPE_PIPE will only chunk
character-by-character rather than genuine chunks.
If it isn't a CONS, we return NIL instead of failing. This way, we
can use it in our general iteration functions. Eventually the actual
runtime would use this as well. The macros are mostly for internal
use to do assignment etc.
Avoid 2 levels of indirection, and having to allocate twice for small
payloads, by having an inlined array on the vector directly!
Beautiful and simple.
Required a bit of refactoring around the board, but overall the result
makes me feel happier.
Stable vectors will be used in the lisp runtime to implement actual
vectors, instead of using the disgusting lvec trick. This way we at
least can get attributes about the vector through one pointer hop.
I'm going to implement a normal stable vector instead of an inline
vector so we have both options for use. I think that's smarter than
just sticking to one.
We're storing them as sv_t's anyway, we're fucked with regards to
indirection. Thus, let's be nice to ourselves, and deal with the
structures. We get the size of the structure for free anyway!
