From benito at benibela.de  Fri Aug 30 04:11:33 2013
From: benito at benibela.de (Benito van der Zander)
Date: Fri, 30 Aug 2013 13:11:33 +0200
Subject: [xquery-talk] operations on derived numeric type
Message-ID: <52207DE5.3010709@benibela.de>

Hi,
is it true that *all* operations on types derived from the numeric types 
return a value of one of the four base numeric types?
For example xs:byte(1) + xs:byte(1) or abs(xs:byte(1)).

What's the point of even having these sub types then?

And why does the XQuery 1 test suite have two different output files for 
the "abs(xs:byte(<e>0</e>)) instance of xs:byte" case (K2-ABSFunc-46)?
One is "true", the other is "false"


Benito

From mike at saxonica.com  Fri Aug 30 06:24:45 2013
From: mike at saxonica.com (Michael Kay)
Date: Fri, 30 Aug 2013 14:24:45 +0100
Subject: [xquery-talk] operations on derived numeric type
In-Reply-To: <52207DE5.3010709@benibela.de>
References: <52207DE5.3010709@benibela.de>
Message-ID: <E597AB13-42E9-463E-9BE4-7AFDBE6AD49B@saxonica.com>


On 30 Aug 2013, at 12:11, Benito van der Zander wrote:

> Hi,
> is it true that *all* operations on types derived from the numeric types return a value of one of the four base numeric types?
> For example xs:byte(1) + xs:byte(1) or abs(xs:byte(1)).

Certainly for all arithmetic operations, yes. (Obviously not for operations like (a gt b).
> 
> What's the point of even having these sub types then?

In my view there's very little point in having these subtypes, but they are there in XSD so XQuery supports them.
> 
> And why does the XQuery 1 test suite have two different output files for the "abs(xs:byte(<e>0</e>)) instance of xs:byte" case (K2-ABSFunc-46)?
> One is "true", the other is "false"

The specification says that abs() applied to an xs:byte value returns an xs:integer. An implementation that returns an xs:byte conforms to that rule, because every xs:byte is an xs:integer. So some implementations might return an xs:integer that is an xs:byte, others might return an xs:integer that is not an xs:byte. Note that there is one case where the result cannot be an xs:byte, namely where the input is xs:byte(-128).

(I suspect that Saxon returns the original value unchanged, including type annotation, if it is positive, and returns a value with type annotation xs:integer if it is negative. That's a permitted and in my view reasonable implementation).

Michael Kay
Saxonica

From msokolov at safaribooksonline.com  Fri Aug 30 07:07:44 2013
From: msokolov at safaribooksonline.com (Michael Sokolov)
Date: Fri, 30 Aug 2013 10:07:44 -0400
Subject: [xquery-talk] operations on derived numeric type
In-Reply-To: <52207DE5.3010709@benibela.de>
References: <52207DE5.3010709@benibela.de>
Message-ID: <5220A730.2090000@safaribooksonline.com>

On 08/30/2013 07:11 AM, Benito van der Zander wrote:
> Hi,
> is it true that *all* operations on types derived from the numeric 
> types return a value of one of the four base numeric types?
> For example xs:byte(1) + xs:byte(1) or abs(xs:byte(1)).
>
> What's the point of even having these sub types then?

It's really a headache to use the subtypes since you are constantly 
fighting against the grain.  For example, if you write a function like:

declare function local:factorial($x as xs:int) as xs:int {
   if ($x < 2) then 1 else local:factorial($x - 1) * $x
}

You get various compilation errors

You have to do something like:

declare function local:factorial($x as xs:int) as xs:int {
   if ($x < 2) then xs:int(1) else xs:int(local:factorial(xs:int($x - 
1)) * $x)
};

local:factorial (xs:int(10))

This is using Saxon 9.4.  Somehow in MarkLogic there seems to be some 
kind of automatic casting going on, and the first function compiles and 
runs OK.

-Mike

PS how many times will I forget that $x-1 is parsed as a variable name.  
A token allowed in a symbol *and* as an operator makes no sense.  Old 
argument I'm sure.

From davidc at nag.co.uk  Fri Aug 30 07:45:40 2013
From: davidc at nag.co.uk (David Carlisle)
Date: Fri, 30 Aug 2013 15:45:40 +0100
Subject: [xquery-talk] operations on derived numeric type
In-Reply-To: <5220A730.2090000@safaribooksonline.com>
References: <52207DE5.3010709@benibela.de>
	<5220A730.2090000@safaribooksonline.com>
Message-ID: <5220B014.5060109@nag.co.uk>

On 30/08/2013 15:07, Michael Sokolov wrote:
> PS how many times will I forget that $x-1 is parsed as a variable
> name. A token allowed in a symbol *and* as an operator makes no
> sense.  Old argument I'm sure.

for variables it could (perhaps) have been different but it's more
consistent to keep all identifiers based on the XML Name production, and
the fact that x-1 is parsed as the element name x-1 but x -1 is parsed
as the value of the element x minus 1 caused a lot of headaches in the
design of xpath1, but couldn't really be avoided given that x-1 is a
legal element name. It's not really any different to the difference
between $x div 1 and $xdiv1.

David

From msokolov at safaribooksonline.com  Fri Aug 30 07:57:37 2013
From: msokolov at safaribooksonline.com (Michael Sokolov)
Date: Fri, 30 Aug 2013 10:57:37 -0400
Subject: [xquery-talk] operations on derived numeric type
In-Reply-To: <5220B014.5060109@nag.co.uk>
References: <52207DE5.3010709@benibela.de>
	<5220A730.2090000@safaribooksonline.com>
	<5220B014.5060109@nag.co.uk>
Message-ID: <5220B2E1.6090405@safaribooksonline.com>

On 08/30/2013 10:45 AM, David Carlisle wrote:
> On 30/08/2013 15:07, Michael Sokolov wrote:
>> PS how many times will I forget that $x-1 is parsed as a variable
>> name. A token allowed in a symbol *and* as an operator makes no
>> sense.  Old argument I'm sure.
>
> for variables it could (perhaps) have been different but it's more
> consistent to keep all identifiers based on the XML Name production, and
> the fact that x-1 is parsed as the element name x-1 but x -1 is parsed
> as the value of the element x minus 1 caused a lot of headaches in the
> design of xpath1, but couldn't really be avoided given that x-1 is a
> legal element name. It's not really any different to the difference
> between $x div 1 and $xdiv1.
>
> David
It is different because of conventional expectations about operators 
being represented by punctuation characters.  If only we had ? on our 
keyboards!

-Mike

From dlee at calldei.com  Fri Aug 30 09:52:59 2013
From: dlee at calldei.com (David Lee)
Date: Fri, 30 Aug 2013 16:52:59 +0000
Subject: [xquery-talk] operations on derived numeric type
In-Reply-To: <5220B2E1.6090405@safaribooksonline.com>
References: <52207DE5.3010709@benibela.de>
	<5220A730.2090000@safaribooksonline.com>	<5220B014.5060109@nag.co.uk>
	<5220B2E1.6090405@safaribooksonline.com>
Message-ID: <3a7d5ea50b6d4043a8638de5a2a51ab5@BY2PR08MB014.namprd08.prod.outlook.com>

Just use
  $x/1  instead  :)


----------------------------------------
David A. Lee
dlee at calldei.com
http://www.xmlsh.org

-----Original Message-----
From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf Of Michael Sokolov
Sent: Friday, August 30, 2013 7:58 AM
To: David Carlisle
Cc: talk at x-query.com
Subject: Re: [xquery-talk] operations on derived numeric type

On 08/30/2013 10:45 AM, David Carlisle wrote:
> On 30/08/2013 15:07, Michael Sokolov wrote:
>> PS how many times will I forget that $x-1 is parsed as a variable 
>> name. A token allowed in a symbol *and* as an operator makes no 
>> sense.  Old argument I'm sure.
>
> for variables it could (perhaps) have been different but it's more 
> consistent to keep all identifiers based on the XML Name production, 
> and the fact that x-1 is parsed as the element name x-1 but x -1 is 
> parsed as the value of the element x minus 1 caused a lot of headaches 
> in the design of xpath1, but couldn't really be avoided given that x-1 
> is a legal element name. It's not really any different to the 
> difference between $x div 1 and $xdiv1.
>
> David
It is different because of conventional expectations about operators being represented by punctuation characters.  If only we had ? on our keyboards!

-Mike
_______________________________________________
talk at x-query.com
http://x-query.com/mailman/listinfo/talk


From mike at saxonica.com  Fri Aug 30 10:15:59 2013
From: mike at saxonica.com (Michael Kay)
Date: Fri, 30 Aug 2013 18:15:59 +0100
Subject: [xquery-talk] operations on derived numeric type
In-Reply-To: <5220B2E1.6090405@safaribooksonline.com>
References: <52207DE5.3010709@benibela.de>
	<5220A730.2090000@safaribooksonline.com>
	<5220B014.5060109@nag.co.uk>
	<5220B2E1.6090405@safaribooksonline.com>
Message-ID: <A557C29D-BBD7-4BDB-85B2-E01B7E001A26@saxonica.com>


On 30 Aug 2013, at 15:57, Michael Sokolov wrote:

>> 
> It is different because of conventional expectations about operators being represented by punctuation characters.  If only we had ? on our keyboards!
> 

I guess there are not many of us left whose expectations are coloured by COBOL.

Michael Kay
Saxonica



From benito at benibela.de  Fri Aug 30 11:23:27 2013
From: benito at benibela.de (Benito van der Zander)
Date: Fri, 30 Aug 2013 20:23:27 +0200
Subject: [xquery-talk] operations on derived numeric type
In-Reply-To: <5220A730.2090000@safaribooksonline.com>
References: <52207DE5.3010709@benibela.de>
	<5220A730.2090000@safaribooksonline.com>
Message-ID: <5220E31F.9000702@benibela.de>

>
>
> PS how many times will I forget that $x-1 is parsed as a variable 
> name.  A token allowed in a symbol *and* as an operator makes no 
> sense.  Old argument I'm sure. 


That's especially fun if you have an implementation that does not raise 
an error on an unknown variable name...



On 08/30/2013 04:07 PM, Michael Sokolov wrote:
> On 08/30/2013 07:11 AM, Benito van der Zander wrote:
>> Hi,
>> is it true that *all* operations on types derived from the numeric 
>> types return a value of one of the four base numeric types?
>> For example xs:byte(1) + xs:byte(1) or abs(xs:byte(1)).
>>
>> What's the point of even having these sub types then?
>
> It's really a headache to use the subtypes since you are constantly 
> fighting against the grain.  For example, if you write a function like:
>
> declare function local:factorial($x as xs:int) as xs:int {
>   if ($x < 2) then 1 else local:factorial($x - 1) * $x
> }
>
> You get various compilation errors
>
> You have to do something like:
>
> declare function local:factorial($x as xs:int) as xs:int {
>   if ($x < 2) then xs:int(1) else xs:int(local:factorial(xs:int($x - 
> 1)) * $x)
> };
>
> local:factorial (xs:int(10))
>
> This is using Saxon 9.4.  Somehow in MarkLogic there seems to be some 
> kind of automatic casting going on, and the first function compiles 
> and runs OK.
>
> -Mike
>
> PS how many times will I forget that $x-1 is parsed as a variable 
> name.  A token allowed in a symbol *and* as an operator makes no 
> sense.  Old argument I'm sure.
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk
>


From mike at saxonica.com  Sat Aug 31 05:09:14 2013
From: mike at saxonica.com (Michael Kay)
Date: Sat, 31 Aug 2013 13:09:14 +0100
Subject: [xquery-talk] operations on derived numeric type
In-Reply-To: <5220E31F.9000702@benibela.de>
References: <52207DE5.3010709@benibela.de>
	<5220A730.2090000@safaribooksonline.com>
	<5220E31F.9000702@benibela.de>
Message-ID: <6BB23C6E-95E6-40D4-84B3-CBEF9BD2C237@saxonica.com>


On 30 Aug 2013, at 19:23, Benito van der Zander wrote:

>> 
>> 
>> PS how many times will I forget that $x-1 is parsed as a variable name.  A token allowed in a symbol *and* as an operator makes no sense.  Old argument I'm sure. 
> 
> 
> That's especially fun if you have an implementation that does not raise an error on an unknown variable name...
> 

I would question whether such a product would qualify as an "implementation".

Though admittedly, while the spec requires variable names to exist in the static context, it doesn't actually prohibit the static context being infinite.

Michael Kay
Saxonica