Re: Ann: SWI-Prolog 6.5.3

On 11/21/2013 05:47 AM, Michael Hendricks wrote:
>
>     In the same way, in the NU Prolog approach, a byte-per-element string
>     *IS* a code list, just stored differently.
>
>
> I think this is an important point worth extra attention.  In one sense,
> [H|T] is just a comfortable interface for sequences of data.  A linked
> list is the traditional sequence, but string-stored-as-byte-array is a
> sequence too.  A sequence might be the key-value pairs in a map or the
> bytes in a stream, etc.  Clojure sequences take the idea to its
> conclusion by abstracting the cons interface so that many data
> structures can implement it.
>
> I'd love to see this idea in more Prologs.

I don't think it is that easy.  [H|T] is syntactic sugar for a data 
structure, not for an operation.  Prolog's unification does the magic,
both eating (`reading') such structures and creating (`writing') them.
You can make things look like materialized input lists.  The
library(pure_input) does this for files.  This requires a dedicated
predicate to turn the datastructure into a (in the case lazy) list.

You could do something similar as library(pure_input) to turn any 
sequential datastruture into a (lazy) list, but the output of your
list processing will be a list.  You'll need another step to create
the desired datastructure.  So, you still end up with

	x_list(X0, In),
	<list processing>(In, Out),
	x_list(X, Out).

Note that quite a few datastructures provide `map' like high order
predicates to map each element in a collection.

	Cheers --- Jan