1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
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 ***
|
