[m-rev.] for review: delete see/seen/tell/told from io.m

[Julien Fischer]

On Sat, 5 Mar 2022, Zoltan Somogyi wrote:

> 2022-03-05 18:51 GMT+11:00 "Julien Fischer" <jfischer at opturion.com>:
>>> The thing is that io.write_list is quite different from other output predicates,
>>> because its main job is not writing out the list (list.foldl(io.write) on the list
>>> will do that just fine), but managing what goes *between* the elements.
>>
>> Its behaviour is similar io.write_array, which according to the above
>> *is* being moved.
>
> I didn't know that; I don't think I have ever used write_array.

I added it back in 2016 because one the systems we had at Opturion needed 
to write out really big arrays and converting them to lists first and then
printing them using io.write_list was hurting performance-wise.

> But since the task is similar to write_list, the solution can be too:
> a version of array.foldl that takes an update to apply to the accumulator
> between elements.

That's fine in principle.  I wonder about the performance implications
of having to evaluate a closure for every separator.

>> Updating a mutable's value may well be atomic, however update_globals/3
>> does a bit more.  Specifically, it does the following:
>>
>>     1. Gets the current value in the globals.
>>     2. Applies a closure that transforms it in some way.
>>     3. Sets the value of the globals to the transformed value.
>>
>> All of that is supposed to be atomic; AFAIK nothing in the currently
>> documented mutable implementation allows for that.
>
> Right, though the above three steps would not be hard to put
> into the body of an automatically generated clause. Putting lock
> and unlock operations around it would not be too hard either,
> even including the definition of the lock var.
>
> The most error-prone part would be programming the exception handling
> required to recover from an update predicate that throws an exception.

The reason that atomic updates for mutables were never implemented
back in the day was that the compiler's handling of implicit imports --
a mutable with an atomic update would need to ensure the exception
module is imported -- was a bit "interesting".  I believe that situation
has been improved since then.  The actual exception handling code
wouldn't be much more complicated than what we introduce for try goals
-- in fact the current implementation of io.update_globals is pretty
much a template of what it needs to be.

Julien.