1 files changed, 36 insertions, 0 deletions
diff --git a/notes/unread.md b/notes/unread.md
new file mode 100644
index 0000000..31b2f91
--- /dev/null
+++ b/notes/unread.md
@@ -0,0 +1,36 @@
+# Must ports support seeking?
+
+With traditional s-expressions, it's not always possible to stop
+reading bytes as soon as the end of the current datum is reached,
+because some data don't have a terminating character.  Consider a
+sequence of s-expressions such as:
+
+    foo(bar)
+
+After reading the second 'o', the parser has no way of knowing that
+the symbol has ended.  It must read another byte.
+
+If the underlying input stream doesn't support "unreading" or seeking
+back, this is troublesome: The opening parenthesis is consumed by the
+first call to the parser, and then discarded, since it's not part of
+the symbol it's reading.  The second call to the parser cannot know
+that the "read head" is already within a list.
+
+I assume that traditional lisps work around this issue by requiring
+all streams (ports) to have seeking or unreading functionality, which
+isn't too bad.  Assuming you only need to look ahead by one character,
+any port without this feature can be wrapped in a port that adds it
+via a simple one-character buffer.  If more than one character of
+look-ahead is needed, a small circular buffer could be used.
+
+Thankfully, Zisp s-expressions are all self-terminating.  This is
+because a datum followed immediately by another datum, without any
+blanks in between, is a "joined datum" expression.  Any number of
+additional data can be joined like this, yielding a more and more
+deeply nested compound datum.  Only a blank or EOF can end this,
+meaning that disjoint data within a stream are necessarily delimited
+by blanks.
+
+
+
+*** WIP ***