[Monetdb-developers] Upcoming changes in the type system affect existing code!
jens.teubner at in.tum.de
Thu Oct 26 16:43:14 CEST 2006
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
Technische Universitaet Muenchen, Department of Informatics
D-85748 Garching, Germany
Tel: +49 89 289-17259 Fax: +49 89 289-17263
Unix is user friendly - it's just picky about it's friends.
More information about the developers-list