The empty sequence & treat as

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

The empty sequence & treat as

frans.englich (Bugzilla)

I have once more run into the peculiarities of the empty sequence. Saxon
statically fails on:

() treat as xdt:yearMonthDuration?

with the message: "XTTE0570: Required type of value in 'treat as' expression
is xdt:yearMonthDuration; supplied value has type empty()"

According to my common sense, the expression should succeed(evaluating to the
empty sequence). I have been unable to support either alternative with Formal
Semantics.

As stated in one of the specifications and written on various mailinglists,
the empty sequence is special and, as Michael wrote, 'a system that does
static typing (even the optimistic kind) can distinguish (treat differently)
an "empty sequence of integers" and an "empty sequence of strings".'

If the behavior can be justified by referring to how the type system is
defined, I still wonder what purpose that has. For example, an
expression(typed as whatever required to make "... treat as
xdt:yearMonthDuration?" not fail with a type error) that evaluates to the
"empty sequence" would have the same result as if "()" was the operand, from
what I can tell.

The 'treat as' expression uses sequence type matching, which in turn uses the
"Derives from" judgment. From what I can tell, the judgement "statEnv |-  
xdt:yearMonthDuration derives from empty-sequence()" does not hold, but
perhaps the empty-sequence() is somehow special cased.

Why shouldn't "max( () )" be a type error if "() treat as
xdt:yearMonthDuration?" is?

"() treat as xdt:yearMonthDuration?" -- type error or not?


Cheers,

                Frans



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

RE: The empty sequence & treat as

Michael Kay
I think this should probably succeed in a dynamic typing implementation.

With static typing, it fails: any expression other than () that statically
returns an empty sequence is an error, and [() treat as
xdt:yearMonthDuration?] is such an expression.

Saxon does have some difficulty with its static type analysis when empty
sequences get involved. The code likes to imagine that there is a type
hierarchy, but there isn't, because the type empty-sequence() (as it is now
called) is a subtype of pretty well everything else. A particular difficulty
is that Saxon generally decides whether A is a subtype of B by testing the
item-type of A,B and the cardinality of A,B separately, but empty-sequence()
doesn't fit this pattern because it's item type is effectively null.

I'll take a look at it.

Michael Kay

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Frans Englich
> Sent: 25 October 2005 13:34
> To: [hidden email]
> Subject: [saxon] The empty sequence & treat as
>
>
> I have once more run into the peculiarities of the empty
> sequence. Saxon
> statically fails on:
>
> () treat as xdt:yearMonthDuration?
>
> with the message: "XTTE0570: Required type of value in 'treat
> as' expression
> is xdt:yearMonthDuration; supplied value has type empty()"
>
> According to my common sense, the expression should
> succeed(evaluating to the
> empty sequence). I have been unable to support either
> alternative with Formal
> Semantics.
>
> As stated in one of the specifications and written on various
> mailinglists,
> the empty sequence is special and, as Michael wrote, 'a
> system that does
> static typing (even the optimistic kind) can distinguish
> (treat differently)
> an "empty sequence of integers" and an "empty sequence of strings".'
>
> If the behavior can be justified by referring to how the type
> system is
> defined, I still wonder what purpose that has. For example, an
> expression(typed as whatever required to make "... treat as
> xdt:yearMonthDuration?" not fail with a type error) that
> evaluates to the
> "empty sequence" would have the same result as if "()" was
> the operand, from
> what I can tell.
>
> The 'treat as' expression uses sequence type matching, which
> in turn uses the
> "Derives from" judgment. From what I can tell, the judgement
> "statEnv |-  
> xdt:yearMonthDuration derives from empty-sequence()" does not
> hold, but
> perhaps the empty-sequence() is somehow special cased.
>
> Why shouldn't "max( () )" be a type error if "() treat as
> xdt:yearMonthDuration?" is?
>
> "() treat as xdt:yearMonthDuration?" -- type error or not?
>
>
> Cheers,
>
> Frans
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> saxon-help mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>





-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

RE: The empty sequence & treat as

Michael Kay
In reply to this post by frans.englich (Bugzilla)
I've no changed "treat as" to behave the same way as type checking in other
circumstances:

(a) () treat as xxxx?

     returns ()

(b) 23[$n] treat as xs:string?

     gives a warning:

Warning: on line 1 of *module with no systemId*:
  the only value that can pass type-checking is an empty sequence. Required
item type of
  value in 'treat as' expression is xs:string; supplied value has item type
xs:integer


Michael Kay



> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Frans Englich
> Sent: 25 October 2005 13:34
> To: [hidden email]
> Subject: [saxon] The empty sequence & treat as
>
>
> I have once more run into the peculiarities of the empty
> sequence. Saxon
> statically fails on:
>
> () treat as xdt:yearMonthDuration?
>
> with the message: "XTTE0570: Required type of value in 'treat
> as' expression
> is xdt:yearMonthDuration; supplied value has type empty()"
>
> According to my common sense, the expression should
> succeed(evaluating to the
> empty sequence). I have been unable to support either
> alternative with Formal
> Semantics.
>
> As stated in one of the specifications and written on various
> mailinglists,
> the empty sequence is special and, as Michael wrote, 'a
> system that does
> static typing (even the optimistic kind) can distinguish
> (treat differently)
> an "empty sequence of integers" and an "empty sequence of strings".'
>
> If the behavior can be justified by referring to how the type
> system is
> defined, I still wonder what purpose that has. For example, an
> expression(typed as whatever required to make "... treat as
> xdt:yearMonthDuration?" not fail with a type error) that
> evaluates to the
> "empty sequence" would have the same result as if "()" was
> the operand, from
> what I can tell.
>
> The 'treat as' expression uses sequence type matching, which
> in turn uses the
> "Derives from" judgment. From what I can tell, the judgement
> "statEnv |-  
> xdt:yearMonthDuration derives from empty-sequence()" does not
> hold, but
> perhaps the empty-sequence() is somehow special cased.
>
> Why shouldn't "max( () )" be a type error if "() treat as
> xdt:yearMonthDuration?" is?
>
> "() treat as xdt:yearMonthDuration?" -- type error or not?
>
>
> Cheers,
>
> Frans
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> saxon-help mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

Re: The empty sequence & treat as

frans.englich (Bugzilla)
In reply to this post by Michael Kay
On Tuesday 25 October 2005 18:08, Michael Kay wrote:

> I think this should probably succeed in a dynamic typing implementation.
>
> With static typing, it fails: any expression other than () that statically
> returns an empty sequence is an error, and [() treat as
> xdt:yearMonthDuration?] is such an expression.
>
> Saxon does have some difficulty with its static type analysis when empty
> sequences get involved. The code likes to imagine that there is a type
> hierarchy, but there isn't, because the type empty-sequence() (as it is now
> called) is a subtype of pretty well everything else. A particular
> difficulty is that Saxon generally decides whether A is a subtype of B by
> testing the item-type of A,B and the cardinality of A,B separately, but
> empty-sequence() doesn't fit this pattern because it's item type is
> effectively null.

In my implementation I ran into the same problem, that empty-sequence() can't
be splitted up into cardinality and item type as sequence types usually can.  

Basically, I have SequenceType, ItemType, SchemaType and Cardinality classes.
The type "element()*" would be represented by a SequenceType instance having
a Cardinality and ItemType instances as data members.

I implemented the empty-sequence() case by letting my EmptySequence class
inherit both SequenceType and ItemType. This, combined with that my type
hierarchy navigation/introspection functions were on the ItemType class(and
not static, for example), meant I could simply override the functions and
adapt to the special cases of the empty-sequence().

Another case is similar: the "sequence type" whose instance the effective
boolean value can be extracted from. That is, the 'and' expression(for
example) can be said to have two operands of "EBV" type. So I created an
EBVType class, that inherited SequenceType and ItemType, and implemented
checking. Thus, it became possible to statically detect various type
errors(say, trying to extract EBV from a date or similar).


Cheers,

                Frans


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help