Re: Object-relational impedence

topmind wrote:

> S Perryman wrote:

>>>Can you demonstrate a type cycle (circular reference) allowed in C?

>>For what purpose ??

> What structure would you describe them as?

Sorry, but you haven't answered the question.

Ah, I see.
You want to change the debate to something about *how* compilers might *internally represent* the definition of a type.

Of course, this has nothing to do with (in your own words) :

<quote>

How many popular languages can you name that DON'T rely on trees or DAGS for type matching and equivalency detection?

And that claim is not about types, but rather *usage* of types.

</quote>

But I am willing to educate you further.

> Compilers use search
> algorithms against internal data structures of program/syntax
> representation

They certainly do.

> to determine what type something is (or is compatible
> with). Such can usually be characterized by data structures such as
> trees, stacks, DAGs, graphs, etc.

As someone who has implemented compilers for several computer languages, I can tell you that my impls have always held type definitions as property *sets* and *maps* (the latter being set-based anyway) .

No "trees or DAGS" required. QED (again) .

>>Feel free to show us how/why :

>>"type matching and equivalency detection"
>>"tend to rely on similar hierarchical taxonomies (or at least DAG
>>taxonomies)" .

> Those are two different things. Requiring trees/dags and "usually
> using" trees/dags are not equivalent.

Evasion evasion. Prevarification prevarification.

You made a claim in one of your typical rants that you challenged me to show is "objectively wrong" . Which has been done (twice) .

No matter how you try to reword the question to get the answer you want (and you will try) , you will fail. Because your rant is rubbish.

>>Did you actually manage to understand your own "solution" well enough
>>to be able to show what it outputs with the required input data (ie
>>provide a functional equivalent of the type substitutabilty example as was
>>defined on day 1) ??

> Those were your MADE UP internal goddam requirements. I am NOT
> obligated to mirror them.

Dear oh dear, that same old sad story.
This fallacy of "internal" (whatever that actually means) .

You were presented something that when given some inputs, would produce specific outputs. You were placed under *no constraints whatsoever* as to what/how you used stuff in order to do the same thing.

All that was required was that as the starting point for debate, the two versions *do the same thing* . You spectacularly failed to do even that.

>>If not, *shame on you* for prevaricating (and wasting Usenet resource) , in
>>order to avoid admitting (again) insufficient understanding of english to
>>do the things asked of you.

> You got yourself into a corner and are making up requirements to
> backpeddle. You lost, dude! Fess up. No "combinatorial explosion" is
> required.

For the real-world systems involving "variant records" that I have worked on (100+ different record types, 100+ different property types) your table is merely a global variable from hell (as evidenced by the several telecoms systems that used the same approach in the 1990s and ended up being a lifetime rewrite and rebuild job whenever types and properties came and went) .

> Eat the Truth! Toppie won that one.

The only "truth" is that Toppie writes "hello world" s/w that :

1. no one can be sure actually executes
2. he cannot explain what the program will output for simple inputs

Regards,
Steven Perryman Received on Sun Mar 16 2008 - 21:31:10 CET