Re: SQL


Dmitry A. Kazakov wrote:
On 14 Feb 2006 17:05:50 -0800, topmind wrote:

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.

Statement 1. Relational depends on a [minimal] set of operations,

Statement 2. The type system is orthogonal to relational.

You have to choose. (1) implies a definite class of types admissible in
cells. (2) implies that cells can hold anything.


From an ADT/type perspective, let me word it this way:

Relational requires that the "expression engine" used
by the cells AT LEAST have operation(s) that can be
interpretable as Boolean. (Which is not hard to do
since anything that returns more than 1 value
can be interpretable as Boolean if we define
some ranges to map. Whether it is
always practical or not is another matter.)

Whatever other operations there are besides those
that return/interpreterable-as Boolean are a bonus
and generally *outside of relational*, not a requirement
of relational.

Thus, if you want to use imaginary numbers with
relational, it is theoretically do-able.


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.

= the value is either of numeric type (="string of digits") or not (="an
error") I hope, you understand that the way this *type* information is
encoded in the value is irrelevant to the discussion. The type information
is in the value. Full stop.


If you are calling error conditions a "type", then I would like to see
a formal definition of "type" (that is not so vague that it is
everything and anything and unfalsifiable). You are spreading the
concept too thin to be useful it seems.

But to avoid the error-is-a-type issue for now, assume that our math
operation returns the string "error" instead of stops program
execution. Example usage:

x = divide(a, b, maxDecimals);
if (x=="error") {
print("Houston we have a problem");
} else {
print("Result: " & x);
}



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.

OK, I repeat:

1. Whether the thing is a number is determined solely by the value
[contents of the string].

No! This is false. It is determined by the "user", i.e. the particular
operation/library/function. One function may treat it as a string,
another as a number. Library A may "declare" it type "Zorko", library B
may "declare" it type "Flink", and library C declare it type "Fonk" on
Wednesdays, and type "Errrp" on Fridays. (Dr. Suess would love context
typing.) The language and interpreter/compiler has no inharent concept
of "type". In context typing, "typing is in the mind and only in the
mind (or a custom library with its own rules)". Being in the mind, it
is not externally testable.


2. It is not determined by the context of the call.

Wrong. It is.


From this follows that types in the presented case aren't determined by the
context, so it is not "context-typed."

It is dynamically typed per definition: "some types are determinable no
earlier than at run-time."

No. Dynamic typing carries a hidden flag. Here is dynamic typing in
action:

x = 1;
print(typeName(x)); // result: "number"
x = "1";
print(typeName(x)); // result: "string"

In context typing on the other hand, you canNOT do this. There is no
way for a "typeName" function to work because there is no side/hidden
flag.

Some semi-context-typed languages make a distinction between scalars
and arrays, but this is mixed models -- that is a mix of dynamic and
context typing. They are context-typing for scalars at least. Perl,
ColdFusion, and Tcl are examples I believe.

PHP is an example of a dynamically-typed language (and frankly it is
annoying) because it does have hidden/side flags that can be
tested/printed. Some operations will act differently depending on how
it is declared because they look at the type flag.



It goes by
different names and if you don't like my working name, you are welcome
to call it something else.

No, it isn't about names. You are trying to present something well-known
(with all its disadvantages and advantages, which also are well known), as
a new paradigm. You aren't Bill Gates, to get away with this! (:-))

No I am not. It exists (to some extent) in languages that I had no
influence over. (I admit maybe I am using the wrong name for the
concept, but have not found a widely consistent one yet.)


There is only A and B. Your C is one of them. So cannot claim that C is
"orthogonal", "better" etc.

Well, it appears you are learning about a typing model that you did not
know existed.


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

ADT can [do] it.

So can assembler.

But you don't! We could discuss merits of assembler vs. OOPL, but you are
out independently on any possible outcome of that debate.

I am only pointing out that runnable and developer-friendly may be very
different issues. If you want to show how ADT's are useful for custom
biz apps using code scenarios, be my guest...


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.

Read that stuff, please!

If you want to switch the debate to arbitrary-precision arithmetic I'll
beat you there. So far, you claimed that there is some magical number 20,
which limits the number of decimal places. That was fixed-point.


Oh, so that is what you are talking about. No, I did not claim that 20
was magical. It was only an *example* default, and I think one showing
the limits of infix notation (+,-,*,etc.). I was *not* necessarily
endorsing such. There appears to be a miscommunication.


If the
number of places is unlimited, then, please, do 1/3, sqrt(2), pi**2. I have
said it before - for *any* numeric model there are real-life counter
examples. This is the only reason why they all exist.

Context typing does not prevent other models. In fact, decimal models
similar to the examples I showed are are a library with functions
and/or classes. They don't have to be installed into the language
natively to be used.

Now, you might argue that using such models in a context typing
language are slower than a strong-typed language. You might be right. I
won't bother to defend speed for such. In some domains it may be
important, but not all.

BTW, whatever happened to the relational O(n) sub-debate? That was more
interesting than math libraries IMO. Have you conceded or plead boredom
or abandonment of that?


--
Regards,
Dmitry A. Kazakov

-T-

.

Relevant Pages

  • 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, ... 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: SQL
    ... dynamic typing would bust relational. ... If you mean that the context typing system I showed does not have a ... Just a naked string. ... possible to mix in arrays too such that there is no hard difference ...
    (comp.object)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... >>of some specific type (int, float, String, Java.stuff) and use ... > when the type is used out of context. ... > 2) the type usage/relationship is valid for a sizable part of the code. ... If you're right then a language such as C is nearly perfect, ...
    (comp.programming)