Google's Go language and "goroutines"
in [TCL]
|
Prev: tcl ssh extension library?
Next: Expect spawn expect
From: tom.rmadilo on 20 Nov 2009 17:37 On Nov 20, 1:22 pm, Bruce Hartweg <doNOTmai...(a)example.com> wrote: > tom.rmadilo wrote: > > So I should write a book instead? I'm not saying that all type > > hierarchies are unnatural, I just wish someone would present a natural > > one as an example. > > Look at the java.util Collection hierarchies plenty > of natural and useful examples > Why is it so hard to produce one example? Of course data structures are more naturally hierarchical than models from the real world. The point is that if you "define" B is a subtype of A, it is obviously natural...by definition. > > Even if such an example emerges, why do the > > subtypes need to be constructed via this formal mechanism? Copy/Paste > > & Edit is great way of creating a new subtype. > > It's a great way of creating a mess, and doesn't provide the same results.. > I'm not interested in the same results, I'm interested in easier programming and better results. > If a type B is a "subtype" of A that is just a copy of the code and new > stuff tacked on, then even though type B can do everything an A can > other areas can't treat B as an A since they are different. > > and maintainance would be a disaster - you would end up with multiple > copies of bugs all over the place. I already explained that the concept of interface is preferable to subtyping. Subtyping takes A, changes it a little and creates a new type, bound to A, but a little different...just enough to cause trouble. An interface has the potential of taking completely different (in details) objects and making them look the same. In other words, you do work to simplify when you create an interface, but you do almost no work to complicate stuff when you create a subtype. Subtyping is like free complications which you can pay for later...and you will pay for them. It seems obvious to me why many developers prefer subtyping: it is quick and easy and you don't pay for it until later. In fact, if you are the one which produces the class which is to be subtyped, you never have to pay! It is kind of like "details are left as an exercise for the reader". How exactly has Tcl survived without types or type hierarchies?
From: Donal K. Fellows on 21 Nov 2009 03:13 On 20 Nov, 23:37, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > How exactly has Tcl survived without types or type hierarchies? There are types. They're just not permanently attached to values; they're more of a characteristic of operations. It is thus a part of the [llength] operation that it operates on values of list type. However, that a value is of list type is merely a transient thing (since we use "duck typing" really). That we maintain the type of value at all for any time after an operation is just an optimization; it's not a vital part of the language's semantics. Because of this fundamentally different approach to types, the type hierarchy question simply isn't pressing. That a value is of one type does not preclude it from being of another type, whatever the relationship of those types to each other is. (Arguably types in Tcl are just arbitrary subsets over the domain of all strings.) Donal.
From: tom.rmadilo on 21 Nov 2009 03:25 On Nov 20, 1:22 pm, Bruce Hartweg <doNOTmai...(a)example.com> wrote: > tom.rmadilo wrote: > > I just wish someone would present a natural > > one as an example. > > Look at the java.util Collection hierarchies plenty > of natural and useful examples Sometimes I hate taking people up on their offer. Why _not_ look at the java.util Collection? Why not start at the very top and breath in the pathology? http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html or newer: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html "A collection represents a group of objects, known as its elements. Some collections allow duplicate elements and others do not. Some are ordered and others unordered. The JDK does not provide any direct implementations of this interface: it provides implementations of more specific subinterfaces like Set and List. This interface is typically used to pass collections around and manipulate them where maximum generality is desired." So the collection offers no direct implementations, check elsewhere for working code. Of course the manpage is longer than Tcl's list manpage which actually describes working code. But check out the last sentence: "This interface is typically used to pass collections around and manipulate them where maximum generality is desired." So basically this interface is used to avoid type checking. This is a perfect example of paying up front for basically the right to pay more later on. The very top of the collection hierarchy is advertised as a way to avoid all the nasty requirements imposed by this ugly system. Not sure if you are going to use a list or an array, a bag or a set or a queue or a sorted map? Just use a collection as the type. Probably the developers are happy that their lists and bags can contain any type. Like wow! Dog types and Cat types in the same bag, oops "collection", we might need to pass this around.
From: Neil Madden on 21 Nov 2009 07:25 tom.rmadilo wrote: > On Nov 20, 3:25 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote: >> tom.rmadilo wrote: > >>> My point is that "flat" hierarchies obviously >>> don't need language features to support inheritance. This should be >>> obvious. So, languages which support type hierarchies obviously have >>> at least two completely different mechanisms in which to define types: >>> directly and by reference to some other type. The by reference is much >>> more complex than the direct method. >> Do you have any evidence to support this assertion? > > Why don't you give an example which proves the assertion wrong. It > would be impossible for me to "prove" by example the assertion, but > you can easily disprove it with one example. Because it is your assertion -- the burden of proof is on you. You stated that building types by reference to other types is more complex than the "direct" method (whatever that is). If this were true, it would rule out *all* compound types, not just subtypes. > >>> Object in my house = a collection >>>> then you'd almost certainly say "yes, there is >>>> a kind-of (subtype) relationship between them". >>> Ah, this is the problem: the relationship is also a "type". Using a >>> static subtype (pointer) relationship to a collection requires a map. >> Eh? In what way is a relationship a type? And why would this require a map? > > Well, below you know about RDF, so I assume you know that each part of > the triple is an object of some type. That's not true, RDF triples are of form (subject,predicate,object) -- the subject and objects are objects, but the predicate is a predicate (relation). > >>> Simple, but relatively limited since every mapping is identical. If >>> the relationship is also a type, you can create a triple (Me<->Mine<- >>>> Stuff) or (Chair<->Kind Of<->Furniture) >> Yes, you can express arbitrary relationships with triples, cf. RDF, but >> what does that have to do with anything? > > Everything. Independent object/type creation. The relationship (Kind > Of) is also a type. > > >>> When you make a static "kind-of" relationship between chair and >>> furniture, you cannot reuse that relationship like this: >>> (Furniture<->Kind Of<->Stuff). >> Umm... sure you can. >> > > Only if "Kind Of" is a type. Not even slightly. E.g. consider Java, where we can define exactly this hierarchy as subtypes without the "Kind Of" relation being reified as a separate type: interface Stuff {} interface Furniture extends Stuff {} interface Chair extends Furniture {} > >>> With the type of relationships above, I can say that this is legal: >>> (Me<->Mine<->Chair), since I can own "Stuff", I can own "Chair". >> The only valid reason for making that assertion would be if you also >> knew that all chairs are stuff -- i.e., that your logic has some notion >> of subsumption/subtyping. > > That is not true. You dynamically create the relationships. You don't > "know" anything until you ask. Your system might have the following > triples: > (Me<->Mine<->My Chair) > (My Chair<->Kind Of<->Chair) > (Chair<->Kind Of<->Furniture) > (Furniture<->Kind Of<->Stuff) > > The "language" does not have a notion of subtyping, just creating > triples. Sure, but your statement was that you can own chairs because you can own stuff. This is only valid if you know that chairs are a kind of stuff -- so either you have such a mechanism built in to your logic, or you manually specify it, as in FOL: \forall x.Chair(x) => Stuff(x) Either way, you are describing a subtyping/subsumption relationship. > >> That was my point. You cannot make blanket statements like "type >> hierarchies are unnatural" without first stating what your domain of >> interest is. Sometimes they're useful, sometimes they're not. > > So I should write a book instead? I'm not saying that all type > hierarchies are unnatural, I believe that is exactly what you said: "I don't think the real world supports type hierarchies". > I just wish someone would present a natural > one as an example. Even if such an example emerges, why do the > subtypes need to be constructed via this formal mechanism? Copy/Paste > & Edit is great way of creating a new subtype. I thought the Chair->Furniture->Stuff example was sufficient. They don't need to be created by any formal mechanism, but they do still exist. Copy/Paste & Edit is a valid (if suboptimal) strategy for *implementing* a subtype, but this is not the same as specifying such a relationship. The difference is between "extends" (inheritance) and "implements" (subtyping) in Java. > > I know that my terminology is loose. Is there a difference between > data subtypes and class/object subtypes which include behaviors? How > about inheritance vs. extensions vs. implementations? All of these are > different, yet pretty much the same thing: they all require language > support to get from the original thing to the new thing. > > But I would like to separate out one type of "subtyping" that seems > easy for me to understand (amazing!), and produces subtypes whose > members are a true subset of the original type. The definition still > requires language support, but the subtype mechanisms are pre-defined. > Not sure if there is an actual name for it, but in XML-Schema they > call it derivation by restriction. Although not required in the XML- > Schema system, one additional requirement I would add is that type > derivation cannot span more than one namespace, in other words, start > with the primitive types in XML-Schema/programming language and derive > new types in the target namespace, no imports. Also, once a simple > type is used in a complex/structural type, it can't be further > restricted. > > There is an article which almost gets at my general distaste for > subtyping: > > http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html > (Why Extends is Evil) This article backs up my point: it favours subtyping (implements) over inheritance (extends). > > Interfaces are probably my favorite abstraction. They are built from > the ground up and hide potentially vast technical differences behind a > common model. Two well known interfaces are "unix files": everything > is a file, and a URI. Or more on topic: tcl channels. And these are all potential examples of subtyping relationships at work: Tcl File -> File HTTP URI -> URI FTP URI -> URI socket -> channel file channel -> channel Etc, etc. -- Neil
From: Donal K. Fellows on 21 Nov 2009 13:43
On 21 Nov, 12:25, Neil Madden <n...(a)cs.nott.ac.uk> wrote: > tom.rmadilo wrote: > > Well, below you know about RDF, so I assume you know that each part of > > the triple is an object of some type. > > That's not true, RDF triples are of form (subject,predicate,object) -- > the subject and objects are objects, but the predicate is a predicate > (relation). Actually, relations can be the subject of relations. That way lies OWL... > Not even slightly. E.g. consider Java, where we can define exactly this > hierarchy as subtypes without the "Kind Of" relation being reified as a > separate type: > > interface Stuff {} > interface Furniture extends Stuff {} > interface Chair extends Furniture {} In general, whether or not you can do this sort of thing depends on the axiom system adopted. Subtypes are just one (common) thing that can be adopted. But indeed, there's no need at all for relations to be in the particular system. Donal. |