[plt-scheme] typed scheme problem: "Expected Attribute, but got Attribute"

Hi all,

I'm stuck with a problem during type matching in typed scheme which I don't know how to get along with. Somehow I suspect it might be related to nesting type definitions in the standard type scheme (define-struct: and define-type)
and the planet dherman/types:2 package (define-datatype) way, like this:

#lang typed/scheme
(require scheme/match)
(require (planet dherman/types:2))

(define-struct: Attribute ((name : String) (typename : Symbol)) #:mutable)

(define-datatype Value
  (S ((s : String)))
  (N ((n : Real))))

(define-type Operand (U Attribute Value))

(define-datatype Predicate
 (Is ((op : Operator) (rand1 : Operand) (rand2 : Operand)))
 (Not ((p : Predicate)))
 (And ((p1 : Predicate) (p2 : Predicate)))
 (Or ((p1 : Predicate) (p2 : Predicate))))

Now when I try something like this:

(define p (make-Is eql (make-Attribute "name" 'type) (make-N 3.6)))
(display (match p
                  ((struct Is (op r1 r2)) (cond ((Attribute? r1) (Attribute-typename r1))
                                                      (else #f)))))

I get the error

Type Checker: Expected Attribute, but got Attribute in: r1


I have no idea what to do with this - alone, both the use of match for types defined with define-datatype works fine, and the use of cond to match types defined as unions is like in the typed scheme documentation 2.1 chapter.
Could someone help?

Also in general, my mixed usage of both makes the matching code itself look awkward when nesting the different ways of definition. In the above example, I test for Attribute with Attribute?, but when I need to test for Value I have to
write

(or (N? rand1) (S? rand1)

- or at least that's the only way I found, so I have "different granularities" somehow. Would someone perhaps know a better way of handling this?

Many thanks in advance for any help,
Sigrid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100425/25cc0308/attachment.html>