[Monetdb-developers] Upcoming changes in the type system affect existing code!

Jens Teubner jens.teubner at in.tum.de
Thu Oct 26 16:43:14 CEST 2006


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

-- 
Jens Teubner
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 mailing list