Re: The IDS, the EDS and the DBMS

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Tue, 14 Sep 2004 08:34:17 +0200
Message-ID: <414690ee$0$78738$e4fe514c@news.xs4all.nl>

Marshall Spight wrote:

> mAsterdam wrote:

>>Marshall Spight wrote:
>>>erk wrote:
>>>
>>>>Type implementation; I think Date had it right in suggesting that type
>>>>implementations could be done in a variety of languages, and even that
>>>>those languages might be different than those used in the rest of the
>>>>app...
>>>
>>>I don't see any value to Date's position here. His canonical polar/rectangular
>>>point example is uninspiring: you can't even represent (1,1) precisely
>>>in polar; you can't represent (45 degrees, 1) in rectangular.
>>
>> > type definition is an area where you can't get away from the
>> > limitations of the underlying data structure.
>>
>>Is this your reasoning? :
>>To represent polar(45,1) as a cartesian(x,x) we would need an exact
>>way to represent the square root of 2. We don't have that so
>>"you can't represent (45 degrees, 1) in rectangular."

> Yes.
>

>>That begs the question: why, exactly? or: is it really impossible?

>
> There is only one way to do it, which is not to evaluate the expression,
> but keep it as an expression: so sqrt(2) remains exactly "sqrt(2)" internally,
> so that if you were to square that expression, you'd get exactly two.
> No programming language I know of does this,

The generalized notion would be: Inverse operations are not to be relied upon to result in the original value. ("It's inverse operations, Jim, but not as we know it"). It appears that a type system using multiple possible representations needs reliable inversion of operations.

> but I believe Mathematica does.
>
> Other than that, yes, it really is impossible.
>

>>And, related: is this an implementation issue or a type-model issue?
>>And: is the (current) impossibilty of an implementation enough
>>reason to abandon a model?

>
> If it provides no particular benefits, and adds complexity, then
> it shouldn't be done. I'm not clear whether it provides any
> benefits; it certainly adds complexity, and the canonical
> example doesn't work!

Yet?

>>((10 divided by 3) times 3) does not give you 10 in any
>>programming language (barring optimization effects :-)
>>It does not realy stop us from thinking of these operators
>>as the ones we are familiar with from math.

>
> Au contraire! Any language with a true rational type
> will handle this just fine. I believe Lisp and various
> other languages provide this.

Ah! Good. Thanks.

> The difference here is between rationals and irrationals;
> rationals present no huge difficulties but irrationals
> cannot be represented extensionally in finite space.

>>
>>>And Date's idea that there *not be* a way to define new types in
>>>the application language is disastrous!
>>
>>Are you sure?
>>D&D Tutorial D supports UDT's (User Defined Types) -
>>or am I misunderstanding your statement?

>
> IIRC TTM explicitly states that the implementation of a UDT
> should be in a different language than the application language.

I won't outguess you :-) Anyone has a reference? Received on Tue Sep 14 2004 - 01:34:17 CDT