Re: SQL

Dmitry A. Kazakov wrote:
On 15 Feb 2006 17:28:41 -0800, topmind wrote:

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.


So you have chosen 1 and dropped 2.

I don't see them as mutually exclusive. The requirements of relational
are kind of like requiring all cars to have a hook on the back that
fits given specifications. The *rest* of the car's design is not
dictated. Adding the hook is a minor price to pay that generally will
not affect the rest of the "math" being used.

I have yet to see any "math system" that is damaged in order to fit
relational's requirements. Got any? Otherwise, I shall consider your
complaint not a practical limitation regardless of whether it clouds
your personal definition space or not.


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

Read it as: it is of a non-numeric type, in which case type check generates
an error. This is a dynamically typed system.


That is validation. How are "types" different from "validation"? Is
validation types, is it a subset of types? A super-set? Again, your
definition of "types" appears to be wide and non-falsifiable.

Note that different libraries may accept different inputs. For example,
library A may accept scientific notation (ex: "2.7e5"), while library B
may not.



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.

This changes nothing. If checking rules vary from function to function,
that only means that you have a mix of [weak in your case] static and
dynamic typing.

Technically it goes as follows, when you call a function from the library
A, the string argument is converted to the type "Zorko"-string, because the
formal parameter of A is of that type. The conversion does nothing, it lets
the string as-is [this is why it is weakly typed.] Then, within the
function, the value is of "Zorko"-string. That value is dynamically checked
for being "Zorko"-numeric. The type flag is stored in the "Zorko"-string
[this is why it is dynamically typed.] If it is "Zorko"-numeric, the
function continues, otherwise, it generates an error.

Each function/library does not necessarily have to use a type flag or
tracker of any kind. It was only an example.


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

Wrong. It is.

No. Even with the modification you made, it is not a context, but, in part,
it is the contract of the library A, in part, it is the [polymorphic]
value. Note that all modern statically typed languages go this way when
dealing with polymorphic objects. This doesn't make them context-typed.
There is no such thing.

Bull. It exists. Note that compiled languages generally track "flags"
during compiling, not necessarily during running. The "flag" is
assocated with a variable, not with a value.

(Compiled languages can also be flag-free if anything can jam anything
it wants in any variable. Assember is kind of like this. Variables are
simply slot names, or more precisely, start-of-slot-addresses. This is
kind of similar to the dynamic version: the variable name is simply a
slot name that carries no other attributes besides the name. When slots
or internal variable tracking tables have a type flag(s), then it is no
longer context typing.)


[ A truly context-typing would mean that what a function does, depends not
only on the type tag of the value and the signature of the function [as it
happens in the example above], but also, on the context of the call. NOBODY
would like to have such thing. It would be an ultimate mess. It would make
functional decomposition impossible, because the developer of a function
would be unable to design it INDEPENDENTLY on the call contexts, which are
UNKNOWN in advance. ]

Perhaps "context" is not the best name for it. "Flag-free" or "untagged
types" may be a better name. Again, I don't want to get caught up in a
name battle. I don't care what it is called as long as it is clear what
is being talked about in this debate.


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.

So, we can finally commit that different numeric models are required? Now
to be able to use them you need a way to distinguish values of different
models.

No we don't. Example:

x = "123456.789012";
y = "7";
x = decimalLibrary.divide(x, y, 20);
print(...);
x = floatingPointLibrary.divide(x, y, 4); // last param is number of
bytes
print(...);

The same inputs can be used by both math models.

That's *all* types about. It is no matter how would you do it, it
is typed anyway.

Sorry, I don't see it.


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?

Huh, there cannot be any debate!

1. Enumerating rows of an unsorted table is O(n), whatever sorting order is
applied.

2. There exist no order for spaces of dimensions greater than 1.

Ergo: tables are useless for spatial data.

You have yet to present a scenario of unexcapable O(n). I showed a
solution to the "distance" calculation by moving that operation to the
internal (domain) notation. We don't have to throw out the baby with
the bathwater.


--
Regards,
Dmitry A. Kazakov

-T-

.

Relevant Pages

  • 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. ... 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)
  • 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: AJAX.NET and prototype.js
    ... The sentiment you espouse almost makes it seem like browser ... needlessly imposed an ongoing maintenance burden through poor script ... sufficiently general to accommodate the context in which you want to use ... So libraries do not offer the full position reporting facially, ...
    (comp.lang.javascript)
  • Re: to learn jQuery if already using prototype
    ... the navigator.userAgent string is a reflection of the HTTP User Agent ... header then any such direction must lead to the definition of the header ... browsers using the UA string whenever two different browsers use UA ... things that gets proposed as a justification for libraries of this sort ...
    (comp.lang.javascript)