Re: Example of expression bias?

From: J M Davitt <jdavitt_at_aeneas.net>
Date: Wed, 21 Jun 2006 15:13:41 GMT

Cimode wrote:

```> J M Davitt wrote:
>
```

>>Cimode wrote:
>>
>>>J M Davitt wrote:
>>>
>>>
>>>>paul c wrote:
>>>>
>>>>
>>>>>Tony D wrote:
>>>>>
>>>>>
>>>>>>...
>>>>>>
>>>>>>
>>>>>>>A data type in RM = (a domain1 to draw values from) + (restrictions
>>>>>>>implemented on domain1 --> domain constraint) + (operators that can be
>>>>>>>defined using that data type)
>>>>>>>...
>>>>>>
>>>>>>This may be one definition of a data type (not quite one I'd accept, as
>>>>>>we've thrashed over elsewhere), but there is nothing particular to RM
>>>>>>...
>>>>>
>>>>>"domain constraint" seems an uncommon term to me because we usually talk
>>>>>of constraints on relations. but I often puzzle over constraints,
>>>>>thinking that they could be as fundamental as any other notion, e.g.,
>>>>>once one arrives at a similar conception of relations to Codd's, one
>>>>>could view everything that one does with them as either adding or
>>>>>subtracting constraints.
>>>>
>>>>CJD calls them type constraints; they define the set of values
>>>>that constitute the type. Types are named, so the sets are named.
>>>>
>>>>The only thing I'd argue about in Cimode's definition is that
>>>>operators are part of the data type. In fact, D+D make the point
>>>>that the declaration of operators is orthogonal to the declaration
>>>>of types -- given that the types are extant before the operators.
>>>
>>>No need to argue on that, operators are indeed a part of a data type
>>>definition. I would personally define *possible* operators applyable
>>>at domain level then define attribute *permissible* operators at data
>>>type level .
>>
>>Then, would you explain why D+D are wrong? And you should probably
>>elaborate on what the "domain level" and the "data type level" are.
>
> Domain level refers to possible value.

Considering the possibility that you have as much difficulty reading as you do writing, let me recap:
- You said that operators are a part of a data type - I said that D+D said they are not - with the exception of the

selector and the /THE_/operators.
- You said, "No need to argue...operators are...part of a data type."

>>And, while you're at it, explain in which data type definition [sic]
>>an operation like, say, division, defined on integers and returning
>>a rational, belongs?

```>
> Data type definition is independent of output.
> In RM, data type definition concerns exclusively input (IPO speaking)
> because the primary focus of RM data type definition is datum integrity
> 'as a value holder'.

```

Why do you bring up input and output? What is "IPO?" What does type declaration have to do with integrity? What does "integrity 'as a value holder'" mean?

What's random about integers and rationals? How can operations be "much more complex" if their declaration is part of the data type declaration?

>>[snip]
Received on Wed Jun 21 2006 - 17:13:41 CEST

Original text of this message