Re: 1GB Tables as Classes, or Tables as Types, and all that refuted
Date: Tue, 23 Nov 2004 17:51:57 -0800
Message-ID: <30i7qjF2vo9d4U1_at_uni-berlin.de>
Alfredo Novoa wrote:
> On Tue, 23 Nov 2004 10:40:02 -0800, Costin Cozianu
> <c_cozianu_at_hotmail.com> wrote:
>
>
>>So don't ask him to provide a summary definition for a variable, because >>he has none.
>
>
> Of course I have a definition for a variable. I posted it many times:
>
> Variable: a holder or a container for a value. The value placed in
> variable may change over the time. To say a variable holds a value
> means that an encoded representation of a value is contained in the
> variable.
>
Incorrect definition. It doesn't apply to most programming languages in existence.
>
>>Such a definition would require formal (mathematical) >>semantics for the model he is defending. And there is none yet.
>
>
> You always use the same trick to dismiss anything you want, but you
> never offer any argument nor any alternative definition.
>
Just read any formally defined programming language. You'll find it there, no need to repeat it. For some languages those are called identifier and they are associated with an
- evaluation context *
Typically such identifiers are not allowed to escape the evaluation context. But in order to discuss the evaluation context you need some kind of formal semantics, either operational or denotational or axiomatic.
> I checked the books you recomended and I have not found any decent
> definition of type, variable, value or operator.
>
Well, because an operator is just a fancy name for a function.
Can you tell me in what books you did not find a definition for the above ?
> BTW I am not defending any model here. I am only saying that types and
> variables are fundamentally different. This should be out of question.
>
But that's trivia. And that's not what at stake here.
>
>>But to answer your question: in Date's sketch of a model called the >>third manifesto, a type is a name that denotes a "set of values".
>
>
> Wrong, according to Date a type is a NAMED set of values with their
> associate operators.
>
I.E. a "name that denotes a set of values" and a "named set of values". Big difference.
> BTW I disagree with Date about that a type always have a name.
>
If types do not have explicit names provided by the programmer, you can
always assigned them a default name such as
int [] -> "int[]"
or
(int->int) -> "int->int"
big deal.
>
>>The >>difference between the type's denoted set of values and the set of >>values denoted by a "relvar" (aka table in common speak) is that the >>later is time varying while the former is fixed in the abstract.
>
>
> A relvar holds a single relation value, and the type's denoted set of
> values might be any set of values: scalars, matrices, vectors, etc, or
> even any combination of scalar and non scalar values.
>
>
Alfredo, I have news for you: every relation is a set and every set is a relation. Of course, I am talking here about the unnamed perspective of relational algebra as documented in the Alice book, and as documented in all standard mathematical books on set theory and logic.
if you want to further troll this point I'll provide a full mathematical account for switching between the named and unnamed perspective.
>>The >>next step is to consider the mapping between the name of the type
>
>
> But you said that a type is a name. Another inconsistency.
>
Every type having an unique name there's no danger of confusion.
>
>>and >>the set of all values of that type ( therefore the subset of the fixed >>immutable set)
>
>
> The relation value holded in the relvar is a subset of the set of all
> relation values. Let's see where you want to go with this chain of
> incoherences.
>
>
>>that are instantiated within the database (i.e. stored in >>a column, in a row, or in a whole table somewhere in the database.
>
>
> Now you are completely lost. This is surrealist, you are interchanging
> the relational type of a relvar and the types of the attributes.
>
No, you have a problem following. According to Date there will be three distinct "kinds" of values. There will be "atomic" values and obviously these cannot be stored in a relvar, but each instance can be stored in a particular attribute of a particular row of a particular relation.
There also tuple values: instances of a tuple type. Those again cannot be stored in a relvar, but can be seen either as the value of a row in a particular relvar, or the value iof an attribute in a particular row (since attributes can store any kind of type -- ioncluding relation itself)
And then there are relation values that can be stored in a relvar, and can be stored in a particular attribute of a particular row.
>
>>And >>the later is a time varying set that can just be as easily thought as a >>relvar, because maps a name (the name of the type) to a time varying set.
>
>
> In a short: What you are trying to say is that we can hold all the
> values of a type in a relvar.
>
> Of course!
>
> For instance if we define a type constituted by the natural numbers
> which are less than 10 and the appliable operators, we can create a
> table of integers and to store those numbers on it.
>
Yes, actually you can do that. If you read Functional Pearls you'll learn how infinite sets can be represented by generators.
> So what?
>
> What a waste of time!
>
> This is of course very different to: types and variables don't have
> any fundamental difference, which is the essence of 1GB.
>
>
No, that would not be the essence of 1Gb, that would be the essence of a Red Herring.
Since nobody, not even the authors alluded to by D&D claimed such a feat, it would be a waste of our time to further discuss red herrings.
>>Depending on the circumstances of the design needs, the schema can make >>this mapping explicit, like in the example I presented from User type to >>the Users table
>
>
> It that example you were mapping a collection of User typed objects to
> an Users table.
>
Anything wrong with that ?
You handwaved quite a bit, now can you explain your point ?
>
>>, and there's *absolutely nothing wrong with that*. As
>
>
> I prefer to map a variable of class RelVar to the Users table.
>
A variable which you just do not have.
>
>
> Regards
Cheers,
Costin
Received on Wed Nov 24 2004 - 02:51:57 CET