Re: Object-relational impedence

S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> TM>How many popular languages can you name that DON'T rely on trees or
> TM>DAGS for type matching and equivalency detection?
>
> TM>And that claim is not about types, but rather *usage* of types.
>
> >>Here are some very popular prog langs for the following arenas :
>
> >>commercial, general-purpose, Internet, safety-critical
>
> >>The prog langs : COBOL, C, Javascript, Ada(83)
>
> >>Which of them rely on "trees or DAGS for type matching and equivalency
> >>detection" ??
>
> >>None. QED.
>
> > Can you demonstrate a type cycle (circular reference) allowed in C?
>
> For what purpose ??

What structure would you describe them as? Compilers use search algorithms against internal data structures of program/syntax representation 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.

I should point out that many set systems don't have cycles either, and could be represented with DAGs if one wanted to.

>
> The definition or use of such a type does not "rely on trees or DAGS for
> type matching and equivalency detection" .
>
>
> >>Additionally, you exposed your (previously indicated) ignorance
> >>about the fundamentals of type theory. For type matching is always done
> >>on the basis of type *name* and/or *structure* .
>
> >>Neither of which require "trees or DAGs" .
>
> > I never claimed "required". You are putting words in my mouth.
>
> 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.

>
> >>2. You have not been able to show us anything in my posting that is
> >> "vaguery" (surprise surprise) .
>
> > It wouldn't do any good if I did.
>
> Of course it would. For the sake of other people, and Usenet archive
> posterity at least.
>
> But tis a convenient excuse *not* to have your claims scrutinised, is it
> not.
>
>
> > Delusional people are usually not fixable.
>
> Good of you to own up to that mental defect that you suffer.

Neener Neener to you too.

>
>
> >>It is has been most amusing watching you squirm like an impaled worm on
> >>yet another episode of your muppetry. And as always, Usenet archives record
> >>them for posterity
>
> > Speaking of shameful record, were you the one who claimed a p/r
> > version of the publications exampled would have to have a
> > "combinatorial explosion", which you failed to prove and tried to
> > change the subject? Or was that lameman? I get the two of you mixed up.
>
> 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.

>
> If so, and you can demonstrate so to me, I am only too happy to resume that
> particular debate and show you the combinatorial problem inherent in your
> "solution" .
>
> 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.

Eat the Truth! Toppie won that one.

>
>
> Regards,
> Steven Perryman

-T- Received on Sat Mar 15 2008 - 06:21:22 CET