Re: About node references

> Therefore, we should have just a single "ref" type.  It can 
> be a ref to an instance of any other "non-value type". 
> 
> A value type is (like in .NET) any simple atomic type, like 
> xs:integer or xs:string. I used to call these "scalar types" 
> -- types without structure. 

Why the restriction? A ref should be an item that acts as a reference to any
sequence, no exceptions.

That gives us three functions perhaps:

ref(item()*) -> x:ref   creates(*) a reference that points to a sequence

deref(ref) -> item()*   returns the sequence that the reference points to

flatten(item()*) -> item()* applies deref recursively to all items in a
sequence that are references until the sequence contains no references;
reports a dynamic error if the sequence contains circular references
(otherwise this would never terminate).

(*) creates is a poor term, because references don't have identity. Two
references are indistinguishable if the sequences they point to are
indistinguishable.

However, I have a few doubts about use cases myself. Let's look at creating
a map. Conceptually we can model this  as a sequence of pairs, the pair
being an atomic value (say) and a reference to an arbitrary sequence. The
get() method is trivial: get($map, $key) -> item()*. The tricky bit is how
to build the map. If we can define a functional relationship from the key to
the value, then it's easy to define build-map($keys, $function). But that
means the map can only do what a memo-function can do. Are there other cases
for maps where the relationship isn't functional? I can't see how, in a
stateless language. If all the relationships are functional, would we be
better off with memo functions?

Michael Kay