Some changes to how streams work, clean up alisp.org

alisp.org

@@ -38,11 +38,14 @@ seamless in that regard.  But we'll need to set a calling convention
 in order to make calling into this seamless from a runtime
 perspective.
 * Tasks
-** TODO Potentially optimise symbol table ingress :optimisation:design:
+** TODO Capitalise symbols (TBD) :optimisation:design:
 Should we capitalise symbols?  This way, we limit the symbol table's
 possible options a bit (potentially we could design a better hashing
 algorithm?) and it would be kinda like an actual Lisp.
-** TODO Reader system
+** TODO Design Strings
+We have ~sv_t~ so our basic C API is done.  We just need pluggable
+functions to construct and deconstruct strings as lisps.
+** WIP Reader system
 We need to design a reader system.  The big idea: given a "stream" of
 data, we can break out expressions from it.  An expression could be
 either an atomic value or a container.
@@ -51,7 +54,7 @@ The natural method is doing this one at a time (the runtime provides a
 ~read~ function to do this), but we can also convert an entire stream
 into expressions by consuming it fully.  So the principle function
 here is ~read: stream -> expr~.
-*** TODO Design streams
+*** DONE Design streams
 A stream needs to be able to provide characters for us to interpret in
 our parsing.  Lisp is an LL(1) grammar so we only really need one
 character lookup, but seeking is very useful.
@@ -74,21 +77,17 @@ parsing isn't as concerned with the specifics of the underlying data
 stream.  We can use a tagged union of data structures representing the
 different underlying stream types, then generate abstract functions
 that provide common functionality.
-**** TODO Design the tagged union
-**** TODO Design the API
-#+begin_src c
-bool stream_eos(stream_t *);
-char stream_next(stream_t *);
-char stream_peek(stream_t *);
-sv_t stream_substr(stream_t *, u64, u64);
-bool stream_seek(stream_t *, i64);
-bool stream_close(stream_t *);
-#+end_src
-*** TODO Figure out the possible parse errors
-*** TODO Design what a "parser function" would look like
+
+2025-08-29: A really basic interface that makes the parse stage a bit
+easier.  We're not going to do anything more advanced than the API
+i.e. no parsing.
+**** DONE Design the tagged union
+**** DONE Design the API
+*** WIP Figure out the possible parse errors
+*** DONE Design what a "parser function" would look like
 The general function is something like ~stream -> T | Err~.  What
 other state do we need to encode?
-*** TODO Write a parser for integers
+*** WIP Write a parser for integers
 *** TODO Write a parser for symbols
 *** TODO Write a parser for lists
 *** TODO Write a parser for vectors