Re: SQL

Dmitry A. Kazakov wrote:
On 13 Feb 2006 18:17:05 -0800, topmind wrote:

Dmitry A. Kazakov wrote:

Like I've said multiple times, the type system is or can be orthogonal
to relational.

Please, re-read what you have answered, and choose one thing.

May I suggest you re-word and/or number your question(s). I don't know
which one you are referencing. I thought I answered everything. If I
missed something, it was not intentional I assure you.

I have never read anywhere where C. Date claimed that context typing or
dynamic typing would bust relational.



[ Constraints are applied to types. Constrained types are subtypes. In
general it is called specialization. ]

You are *calling* constraint parameters "subtypes". One can also view
them as simply constraints without any connection to types.

Then answer my question. The result should have a constraint, which
constraint it will have in your "disconnected" view. It is a simple
question. Should your customer know when your program will crash or not?

I think two different subjects got confused here.

I.e. you cannot.

If you mean that the context typing system I showed does not have a
constraint feature like you showed earlier, you are right. I never
claimed it did. It was not the context of those statements.


Situation determines the semantics of "+" is exactly same as: situation
determines the type. This changes nothing.

I am only saying that your "unknown" statement is false.

Either you know the "situation" or not. When you know it, so you know the
type. Then you cast the value to that type and continue. This is what you
propose: explicit casting all over the program!

There is no "casting" in "context typing". Casting requires a hidden or
side "flag(s)" that tells what type a variable is. Context-typing vars
have no such flag. Every variable is generally tracked as a string (or
array of strings, depending on how arrays are implemented) with no
other indicator/flag/marker of any kind. Just a naked string.

When "+'" takes two strings it have to parse them to figure out what
numbers they represent. The result of this parsing *is* the type flag.

Please clarify. The result is a flag? In what sense? The result should
either be a string of digits or an error.


Note
also that in this case it is not the context which determines the types,
but solely the actual values. I.e. it is dynamic typing, with "String"
substituted for "Object." The exclusive properties of your "system":

You can call a type system with only one type a "type system" if you
really want to, but I don't see what that gets you. It is like saying a
toothpick house has "types" of components because it has one type: the
toothpic. It is only a name game. Call it whatever you want. I seek
usefulness, not label fights.


1. Utterly inefficient implementation

They used to say that about non-assembler. CPU is *** cheap compared
to other bottlenecks such as network response/bandwidth. If we can get
machines to slave away so that humans don't have to, that is a good
thing. That is why we have GUI's, which are mega-wasteful as far as
resources. (Some people over-use GUI's, but that is another topic.
Either way, they are popular.)

2. Exceptionally space consuming


I agree on a large scale (uncompressed) strings are not the way to go,
but I am not recommending them on a large scale. BTW, a "dynamic
database" may be able to effectly compress records such that the net
space difference is is almost nil. Strings of digits compress well.


3. Very unsafe because nobody actually knows what x + y could mean.

Only if the lang allows operator overloading, which I am generally not
a fan of. I prefer another character, such as "&", for string
concatenation. JavaScript sucks in that regard.


And of course, there is no such thing as "context typing."

I know two languages that have it, at least for scalars (and it is
possible to mix in arrays too such that there is no hard difference
between strings and arrays, but that is another topic.) It goes by
different names and if you don't like my working name, you are welcome
to call it something else.


"Any" is a very tough request. I might hit 99%, but I cannot anticipate
everything.

ADT can [do] it.

So can assembler. Runnability alone does not tell us anything about the
human-managability of the app/system. Turing Tarpit. And, you seem to
want to rekindle the Yin-Yang debate again.


Again, I did not propose that decimal math is appropriate for all
domains.

But you do claim that it (decimal fixed-point arithmetic) is suitable for
all financial domains and for all domains where a DB comes in
consideration?

First, I don't know if "fixed point" is an appropriate description.

It is. Read the links I posted before.

Sorry, but I don't know what criteria you are using to assertain
fixed-ness.

If you do 12.34 * 56.78, you get 700.6652

The number of decimal places went from 2 to 4. Nothing "fixed" there
that I see.


--
Regards,
Dmitry A. Kazakov

-T-

.

Quantcast