Re: SQL

On 13 Feb 2006 18:17:05 -0800, topmind wrote:

Dmitry A. Kazakov wrote:

So far you have shown no traces of any concept, which could make relational
independent on types.

And you've showed nothing that makes it dependent on them (barring a
minimal set of operations).

It is a mistake of your own. I saw no indications
that it is anyhow shared by DB community. Look at what respected people
like C.J. Date do. Do they propose to get rid of types in DBs? Nope, they
do exactly the *opposite*.

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.

[ 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.

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. 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":

1. Utterly inefficient implementation
2. Exceptionally space consuming
3. Very unsafe because nobody actually knows what x + y could mean.
4. It can be used as a video game: the players write arbitrary strings and
trying to predict the outcome of +, -, /, * etc

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

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

ADT can it.

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.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: SproutCore--over 20000 lines of new code!
    ... You will not usually create a render context yourself but you will ... single string using join. ... context.end<-- ends the tag context... ...
    (comp.lang.javascript)
  • Re: SQL
    ... Just a naked string. ... also that in this case it is not the context which determines the types, ... I.e. it is dynamic typing, ... interesting than math libraries IMO. ...
    (comp.object)
  • Re: SQL
    ... Just a naked string. ... Note that different libraries may accept different inputs. ... In context typing, "typing is in the mind and only in the ...
    (comp.object)
  • Re: Test first as specification
    ... >>> the only valid input string is an infinite string of a's? ... Without some additional knowledge about the language we ... The context you mention below. ... correctness may be a matter of degree. ...
    (comp.object)
  • Re: SQL
    ... Just a naked string. ... also that in this case it is not the context which determines the types, ... I.e. it is dynamic typing, ... PHP is an example of a dynamically-typed language (and frankly it is ...
    (comp.object)