Re: SQL

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.

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.

So you have chosen 1 and dropped 2.

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.

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.

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.

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.

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

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.

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. That's *all* types about. It is no matter how would you do it, it
is typed anyway.

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.

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

Relevant Pages

  • 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
    ... 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: 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: TypeConverter HELP Needed!
    ... > occurred while trying to generate the property value for ControlType. ... > virtualPath, String inputFile, HttpContext context) +36 ... > public override bool CanConvertFrom(ITypeDescriptorContext context, ...
    (microsoft.public.dotnet.framework.aspnet.buildingcontrols)