UWN

Shorter, the age of terms influences the outcome. ``` f(freeze(T)) :- [T|s]=T. h(F_0) :- [T|s]=T, F_0 = freeze(T). g(freeze(T),T). ?- f(T). T = freeze([s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,...|...]), unexpected. ?- h(T). T = freeze([s|s]),...

What is most irritating here is that the result is stateful

**if** you want to have something special for it, then use a `built-in predicate`. Like `list_to_compactlist/2` or the like. But not a special functor as `diff_string/1`.

But most of the time there will be built-ins (like those for `library(pio)`) that will generate compact representations. Or think of `atom_chars/2`, `number_chars/2`. Another option is to produce a compact...

... and the other advantage of null-terminated strings on the heap is that a DCG for parsing does not require auxiliary memory. Not like #1714

There is one aspect which caught my attention recently. The key element of partial strings is the use of null-terminated UTF-8 strings which begs the question how to represent the...

> I was more thinking about "partial lists of bytes/octets" Compared to using UTF-8 characters, this would reduce their overhead at best by a factor of two. Worth the effort?

> just store the length of the inlined string somewhere There is no such space. That is it would produce garbage all the time, like #1714

Just look at `l/1`: ``` l([]). l([_|L]) :- l(L). ``` And now use your representation with "abc". In the first inference, `L` is "bc". How do you express this with...

(I don't get your point) What happens with `l/1`? How does this scheme avoid the creation of any auxiliary datastructure?