[e-lang] Joe-E ByteArray stream interface and character encoding/decoding

[Jon Leonard]

On Thu, Oct 18, 2007 at 05:02:11PM +0100, David Hopwood wrote:
> Adrian Mettler wrote:
> > Here are the proposed implementations for stream adapter logic in
> > ByteArray and character encoding/decoding routines to and from ASCII and
> > UTF-8 in Joe-E.  Tyler suggested that I let you take a look at them and
> > see if there are any unintended bugs or sources of nondeterminism.
> 
> ASCII.input and UTF8.input return an InputStreamReader. The javadoc for
> InputStreamReader.getEncoding says:
> 
> # This method may return null if the stream has been closed.
> 
> InputStreamReader.ready says
> 
> # Returns: True if the next read() is guaranteed not to block for
> # input, false otherwise. Note that returning false does not guarantee
> # that the next read will block.
> 
> Wording such as "may" and "does not guarantee" implies specification
> nondeterminism. I don't know whether this is just reflecting the fact
> that the underlying InputStream may be nondeterministic (in Java).
> How strict do we want to be about specification nondeterminism in
> tamed APIs?

That looks like a friendly reminder that new data could arrive between
the call to ready() and the call to read().  Or it could represent some
additional randomness (latency in updating whatever read() checks), but
I doubt it's intentional randomness.

That doesn't address the fundamental problem, though:  With parallel
communication (with a user or other vats), there's no particular guarantee
as to message order.  Trying to enforce determinism there prevents some
useful real-world programs.

I don't see a lot of point in trying to get rid of IO-related
nondeterminism (since it seems intrinsic:  When will the user act?), but
I may be misunderstanding taming.

Jon Leonard