Re: Object-relational impedence

S Perryman wrote:
> 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.

I am trying to get to the heart of the matter instead of play 20 questions.

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

ANY way one represents them will still result in a dag or tree.

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

Sets can be used to represent trees and dags also. Thus, using sets in a compiler does not necessarily remove trees/dags.

A good test for such would be to see if there can be type cycles, such as recursive types that never "solve". If you have a better or different test, then please mention it.

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

You wish.

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

Projection: you are evading the question with tricks.

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

Internal: "not feature or behavior that the user requested or requires".

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

That "inputs" and "outputs" were NOT a necessary part of the problem domain!

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

I am not going to match something stupid just to make the stupidity equivalent. That is silly.

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

You are changing the problem domain here. We can address telecom after we're done with the publications. You appear to be evading.

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

WRONG: I gave you RUNNABLE source code. You can test it with FREE interpreter.

> 2. he cannot explain what the program will output for simple inputs

Your "inputs" are irrelevant to the domain requirements.

You are more interesting than playing word games that exploring technology.

>
>
> Regards,
> Steven Perryman

-T- Received on Mon Mar 17 2008 - 03:35:27 CET