Pathfinder folks,

I am currently busy rewriting Pathfinder's type system. In the short-term view, this rewrite will bring us a much cleaner and more consistent representation of types, and I'm quite confident that there will be less bugs in the new code; I have actually found quite a few in the existing code while doing the rewrite.

Most importantly, however, on a longer term view, my rewrites pave the ground to implement also *dynamic* typing in Pathfinder in an elegant and standards-compliant manner.

The rewrite will also change the internal representation of types in Pathfinder. Most of the current built-in primitive types will become *named* types, in line with the XQuery specs. Most importantly, this makes Pathfinder highly flexible and easily extendible with respect to types.

Unfortunately, there's a bunch of code flying around in the project that inspects the (current) internal type representation in a deprecated manner. My changes *will* break such code. This mainly affects code that looks into the enum field PFty_t.type, a field that is not (and has never been) supposed to be inspected by code outside types.c and subtyping.c. milprint_summer.c in particular is full of such references. ONCE I'M DONE WITH MY REWRITES, SUCH CODE *WILL* BREAK.

MY NEXT CHECKIN WILL TAG AFFECTED CODE IN MILPRINT_SUMMER.C WITH #ifdef'S. WHOEVER FEELS RESPONSIBLE FOR THIS ABUSE OF THE CURRENT TYPE REPRESENTATION OR WANTS TO RESCUE THE CODE IN milprint_summer.c FROM DYING CAN USE THESE #ifdef'S TO FIND THE APPROPRIATE PLACES AND FIX THE RESPECTIVE CODE. I WILL *NOT* FIX THE AFFECTED CODE MYSELF.

The "official" way to inspect Pathfinder's types is to use the functions provided by types.c and subtyping.c. The subtype check PFty_subtype() is the function that allows most of the checks against types that one ever needs. Additional helpers can be PFty_prime() (which normalizes a structured type to have the form `t1 | t2 | t3 | ...') or PFty_quantifier() (determining the quantifier, `0', `1', `?', `+', or `*', of a given type).

The test whether a type t is the type `xs:string' may, e.g., implemented by testing

PFty_subtype (t, PFty_xs_string ()).

(Some care has to be taken, though, that this is a *subtype* relationship. Often, this is what you actually need. If you want to test for type *equivalence*, use PFty_equality(), which applies the subtype test in both directions.)

Quantifiers are usually tested with a subtype test against a regular expression over the `item' type.

PFty_subtype (t, PFty_item ()),

e.g., tests whether the quantifier of t is exactly one.

You may want to look into other pieces of our code, e.g., core2alg.brg, to see how PFty_subtype() and others can be used to test types. Just watch out for invocations of PFty_subtype().

If you need any further assistance regarding types, just contact me.

Jens