aboutsummaryrefslogtreecommitdiff
path: root/alisp.org
diff options
context:
space:
mode:
authorAryadev Chavali <aryadev@aryadevchavali.com>2025-09-01 21:47:25 +0100
committerAryadev Chavali <aryadev@aryadevchavali.com>2025-09-01 21:47:25 +0100
commit030a289497db1fcbd22eafb99d7d8827bca94563 (patch)
treed07e486230092ab10e3b13680c72d21afc4907ca /alisp.org
parent1aa01d2a893350d979f1c763f0216ba2dcf501bc (diff)
downloadalisp-030a289497db1fcbd22eafb99d7d8827bca94563.tar.gz
alisp-030a289497db1fcbd22eafb99d7d8827bca94563.tar.bz2
alisp-030a289497db1fcbd22eafb99d7d8827bca94563.zip
Some changes to how streams work, clean up alisp.orgmaster
Diffstat (limited to 'alisp.org')
-rw-r--r--alisp.org31
1 files changed, 15 insertions, 16 deletions
diff --git a/alisp.org b/alisp.org
index bbeb97d..be27f37 100644
--- a/alisp.org
+++ b/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