Re: more closed-world chatter
Date: Sat, 05 May 2007 21:23:11 GMT
Message-ID: <3B6%h.1620$rk5.124_at_trndny06>
"Marshall" <marshall.spight_at_gmail.com> wrote in message
news:1178396255.293864.297010_at_e65g2000hsc.googlegroups.com...
> On May 5, 12:40 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> > "Marshall" <marshall.spi..._at_gmail.com> wrote in message
> > > On May 5, 8:50 am, Jon Heggland <jon.heggl..._at_idi.ntnu.no> wrote:
> >
> > > > > when it comes to the advantage of sub-typing in dealing with
> > > > > my question.
> >
> > > > I don't know about "advantage"; I just don't see how you can avoid
it.
> >
> > > It's easy to avoid: just don't put subtying in the language design.
> >
> > > Much of the talk in language design in the last ten years or more
> > > has focused on various mechanisms for subtyping, but it's an
> > > entirely optional language feature. That's easy to forget when
> > > it's all anyone's talking about, but it is possible to just leave it
> > > out.
> > > It's also possible to leave a static type system out entirely.
> >
> > You've lost me here. As Bob pointed out a few days ago,
> > all types can be considered subtypes of the universal supertype.
> > Doesn't that mean that all typing is, in reality, subtyping?
> >
> > If so, how can you implement typing without
> > implicitly implementing subtyping?
>
> Be sure to distinguish between a theoretic view of a formal
> system that is outside the system, and the system itself.
> We can analyze any type system with set theory, and
> speak of the universal set, but that doesn't mean the
> universal set is a concept within that system.
>
> Imagine a programming language with exactly two types:
> int and string. The language is statically typed, in that every
> term in a program can be categorized as having one of
> those two types. Functions arguments are either ints, (+ - * /)
> or strings (append, length.) Some functions might take
> one argument of each type: left("hello", 2). Any attempt
> to use a term of one type as an argument that requires
> the other type is a compile time error.
>
> This language is statically typed, but has
> no subtyping whatsoever.
>
OK.
> Now, we can certainly speak of the set of all ints
> and strings, but we can't express anything about
> that set *within* this language.
>
> Similarly, we can imagine a typed relational language
> in which every attribute of every relation has a type;
> all types are disjoint, and any attempt to join two
> relations that have attributes with the same name
> but different types yields a compile time error. Is
> this the nicest thing you could do for the programmer?
> Probably not, but then again this language can be
> implemented quite easily and could produce
> very efficient code.
>
What's the difference, in this context, between a type and a domain?
The reason I ask is because I once had occasion to every occurence, in the
code,
of comparisons like "WHERE ... A.X = B.Y" and the two items being
compared were based on different domains. I was able to use Rdb itself,
and some fancy features of a text processing utility, to get the answer
automatically. No big deal.
End of digression.
You are right. This could be evaluated at compile time. Of course, provided that the metadata is available at compile time, which is definitely a good idea anyway.
It might be desirable to allow the query programmer to override the restriction, if desired. Received on Sat May 05 2007 - 23:23:11 CEST