Re: write_canonical and streams

On 12/02/2014, at 7:53 AM, Anne Ogborn wrote:

>> One could argue that quoted write should refuse to write the term
> 
> instead of read refusing to read it.
> 
> 
> I'd argue for that. Breaking the contract that you can always read what you've
> written is definitely in ROK's 'almost works' territory.

For debugging purposes, it's great to be able to see _everything_,
and at least to know what _kind_ of thing a term was.

Note that SWI has a blob(Atom) write-option.
I don't actually understand how to use it, but
I imagine you could use it to raise an exception.

For what it's worth,
 - The <...> notation seems to be straight of out Lisp,
   where #<...> is used for things that don't read back,
   and the lexical macro #< is basically defined to raise
   an exception.
 - Quintus used special '$stream'(..,..) terms and similar terms
   for data base references, &c, that *could* be read back, and
   *could* be safely used when read back, provided the "object"
   referred to still existed.  Basically, the arguments of the
   term let you find the original object and also gave a quasi-
   random "secret key" so that you could tell if it was still
   the "same" object.  A more modern equivalent would be to
   use a UUID.

The point of mentioning Quintus here is that it shows that
you COULD have a printable representation for "object references"
that DID read back.  The price of that is that you have to
distinguish between
	"well formed" references
and
	"still valid" references.