Re: write_canonical and streams

On 02/12/2014 12:41 AM, Richard A. O'Keefe wrote:
> 
> 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.

That was mostly the motivation.  Most terms are just written during
development and debugging and are never intended to be read.

> 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.

I guess you can do

	..., write_term(Term, [blob(portray)])

portray(Stream) :-
	blob(Stream, stream),
	throw(error(domain_error(printable, Atom), _)).

This kind of works, but of course trying to print the error
causes this to be called recursively, so it gets a mess.  We'll
run into the same mess if we throw exceptions from write_term
for blobs.  Seems we should not go that route.

> 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.

Possibly we should reconsider this.  I think the decision to use
an atom for such handles is still wise, as it allows us to GC
streams, clauses, etc. (the plan is to use this for many more
objects in the future, think notably of message queues and
threads).  The textual representation of these special atoms
is of course completely open.  At the moment, most use
<type>(Address)

You could (in theory) try to see whether the special atom
representing type-Address still exists.  Indeed, you'd need
an additional key because addresses tend to recycle, often
of the same type because the size of the object is the same.

One of the problems is the syntax.  As Joachim once pointed
out, <type>(Address) is not really illegal syntax in Prolog,
as you can define > as infix op and < as prefix op to make
it legal ...

The second issue is of course what to do if the target object
does not exist any more.

	Cheers --- Jan