Please consider whether partial_string/1 and partial_string_tail/2 are needed

[triska]

There are currently 3 predicates for reasoning about partial strings:

• partial_string/3
  I can see that this may be useful for example to implement library(pio), when a file is read block-wise for efficiency. This means that a list of characters is already read from a file (i.e., one block), and we want to turn this into a list difference so that more can be read later, and quickly appended. However, ideally, append/3 could be used to do the exact same thing (for instance, GC may rewrite the resulting list to use this efficient internal representation).
• partial_string/1
  This is to test whether its argument is a partial string. Since the internal representation of a list should not matter at all to Prolog code, I think this can very safely be removed.
• partial_string_tail/2
  This relates a partial string to its tail. However, that tail is always also available as a Prolog term, namely as the second argument of partial_string/3. So, also this predicate seems to be unneeded.

As I see it, a key attraction of partial strings is that they blend in completely seamlessly into Prolog code, since they are "only" an efficient internal representation for what appears as partial lists to Prolog code. This is their main selling point over dedicated ad hoc data types, which require additional interface predicates. In the end, it's only a performance improvement, nothing that affects the meaning of Prolog code in any way.

From these considerations, and to ensure good portability, elegance and simplicity of Prolog application code, it seems prudent to reduce these interface predicates as much as possible, either to only partial_string/3, or, if possible, to none at all.

[UWN]

We need some functionality of this kind to evaluate improvements. But maybe they should not be directly accessible to the regular programmer.

[triska]

Yes! And also, maybe improvements can be tested in other ways, for instance via a predicate like term_size_in_memory/2 etc.?

[UWN]

No. That would never uncover the problem of semicontext context as in look_ahead

[UWN]

@triska, BTW: Can you fix #278 ?

[mthom]

@triska, BTW: Can you fix #278 ?

I did, I think. I haven't pushed it.

[UWN]

Not yet

[UWN]

Perfect!

[UWN]

By the same token #267

[triska]

As per fac6d54, these predicates are now no longer so prominently advertised, and as per 6e4b76a, they are no longer needed in application code at all (see #328 for examples).

For internal testing, it is OK that they are available, so I am closing this issue. Thank you a lot!