Google's Go language and "goroutines"
in [TCL]
|
Prev: tcl ssh extension library?
Next: Expect spawn expect
From: tom.rmadilo on 21 Nov 2009 19:54 On Nov 21, 4:25 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote: .... (see previous post) All I can say is that you are mixing up two different points that I was trying to make. I am not saying that subtyping cannot be used to represent subtypes or "kind of" relationships. Never even got close to that. My point is simple: subtyping breaks the definition of a type/class/ interface over many different files, Java is a good example regardless of extends or implements. Both are top-down and fixed. They require prior understanding of the similarities and relationships (the model) before you can create the type/class/interface hierarchy. Changes are difficult to introduce. The subtyping is a language feature and represents a different style of programming. That was point one. Second point: You don't need these language features to get similar results, maybe better results. This was the whole point of my original "Wow, goroutines have a flat type hierarchy!" post. Never did I say that such features do not exist or cannot model something, maybe anything. It just isn't a very flexible development strategy. I also gave examples of other systems, but these were never meant to indicate you could not model the same thing using a hierarchical type system. They were instead examples of systems which develop from the ground up, before any hierarchy exists.
From: tom.rmadilo on 22 Nov 2009 03:28 On Nov 21, 10:43 am, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > 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... I guess I shouldn't have ventured into the RDF terminology, but OWL is a little closer to what I was describing, but not quite. OWL has strict language features used to create subtypes or subclasses. Essentially set theory. When you create the subtype, you essentially the mathematical relationship between the classes and establish the inferences you can make, or can't. This type of language falls into the same category as XML-Schema types which are derived via restriction using a fixed and known set of rules. Much easier to understand than generic type extension which provides no guarantees. Anyway, the relations composed of triples, where the predicate is also an object is similar to the OWL notion of allowing type instances to be subtypes. But the subtyping is constrained by the allowable value space of the object. However, the subtyping is both dynamic and non- hierarchical. As someone who always thinks in terms of verbs and not nouns, and interactions but not actors, the thought that the action isn't an object, with features, seems not right. I mean that is the whole friggin thing. The world would be pretty boring with out predicates. > > 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. I really have nothing against this type of system, I just can't think that far ahead. Tomorrow, I will think maybe there is Househhold Stuff and Office Stuff. And both have Furniture which also has Chair. Now what do I do? How do I move my Office Chair into my Home? The problem isn't that hierarchies can't be defined, the problem is tomorrow, yesterday's hierarchy is out of date. Just look at the two links I provided to the Java Collection. Two versions of Java, different hierarchy, same names.
From: Donal K. Fellows on 22 Nov 2009 07:07 On 22 Nov, 08:28, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > I really have nothing against this type of system, I just can't think > that far ahead. Tomorrow, I will think maybe there is Househhold Stuff > and Office Stuff. And both have Furniture which also has Chair. Now > what do I do? How do I move my Office Chair into my Home? The problem > isn't that hierarchies can't be defined, the problem is tomorrow, > yesterday's hierarchy is out of date. The problem is that you're trying to make classes be the total description of the world. The world consists of instances, and classes are just the shadows on the wall that are cast by the instances. A particular object, an instance, is quite capable of being a piece of furniture (specifically, a chair) and at different times, both a household item and an office item. Actually with a home-office, it can be both of those latter classes simultaneously. And yet, what is the defining characteristic of the class of Office Stuff? Well, it's got to be that instances of the class have an instance of the class of Offices that they belong to. The belonging-to relation (in the sense used here) is not one that is immutable over time, and so it is usually easier to describe the Office Stuff class as a Rôle; a Class that is only temporarily bound to the instance. Usually people consider classes to only be those that are inherently characteristic of the instances; where the instance cannot stop being a member of that class without ceasing to exist as an instance at all. That probably ought to be a subclass of Class as a concept, but people ambiguously mix these things up. The majority of OO languages only use the "inherently characteristic class" concept. XOTcl and TclOO use the broader definition (I don't know about the other Tcl object systems; it depends on the mutability of classes and instances and that's not something I've explored in great depth). BTW, the difficulty of describing these things is often down to the inherent ambiguity in natural languages. That's why ontologists use formal vocabularies instead, where one thing can mean exactly one thing. > Just look at the two links I provided to the Java Collection. Two > versions of Java, different hierarchy, same names. Evolving a class hierarchy over time is where things get interesting. Description logics (the foundation of ontological description) tend to not sit well with temporal logics; IIRC, the combination of the axioms of the two tends to make the overall intuitionistic meta-logic intractable. Donal.
From: tom.rmadilo on 22 Nov 2009 15:59 On Nov 22, 4:07 am, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > On 22 Nov, 08:28, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > > > I really have nothing against this type of system, I just can't think > > that far ahead. Tomorrow, I will think maybe there is Househhold Stuff > > and Office Stuff. And both have Furniture which also has Chair. Now > > what do I do? How do I move my Office Chair into my Home? The problem > > isn't that hierarchies can't be defined, the problem is tomorrow, > > yesterday's hierarchy is out of date. > > The problem is that you're trying to make classes be the total > description of the world. The world consists of instances, and classes > are just the shadows on the wall that are cast by the instances. A > particular object, an instance, is quite capable of being a piece of > furniture (specifically, a chair) and at different times, both a > household item and an office item. Actually with a home-office, it can > be both of those latter classes simultaneously. > Exactly! An object (instance) can be multiple things at the same time, or have multiple relationships at the same time (but my example doesn't work very well, maybe a new class Location is needed to attach directly to Chair, since the object propertied don't depend on location. Or maybe the owner needs to be "Company X" instead of Me. > And yet, what is the defining characteristic of the class of Office > Stuff? Well, it's got to be that instances of the class have an > instance of the class of Offices that they belong to. The belonging-to > relation (in the sense used here) is not one that is immutable over > time, and so it is usually easier to describe the Office Stuff class > as a Rôle; a Class that is only temporarily bound to the instance. Yes, temporarily bound, yet the system as a whole may need to represent this temporary binding in order to represent other relationships in the current system. That is why the "predicate" for lack of another term also has a type/ class and you create an instance to bind the subject and object. In other words, the predicate is not a language operator with immutable properties. > Usually people consider classes to only be those that are inherently > characteristic of the instances; where the instance cannot stop being > a member of that class without ceasing to exist as an instance at all. > That probably ought to be a subclass of Class as a concept, but people > ambiguously mix these things up. The majority of OO languages only use > the "inherently characteristic class" concept. XOTcl and TclOO use the > broader definition (I don't know about the other Tcl object systems; > it depends on the mutability of classes and instances and that's not > something I've explored in great depth). The class of an object does not change, but the instance properties of the predicate might change. For instance, I might sell my chair to someone else. Instead of removing the previous (Me<->Mine<->Chair) relationship, I modify the Mine predicate to include a time interval and create a new relationship (Me2<->Mine2<->Chair). Somewhat by accident I have created a history of ownership of the Chair.
From: Bruce Hartweg on 22 Nov 2009 18:12
tom.rmadilo wrote: > 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. > no Collections work fine - you can use them *without* caring about the implementation. And the man pages for the implmentation classes are there as well, so why are you whinging around on that point? > 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. > exactly, and if you don't see the usefulness of that, there isn't much else to say. > 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. Yes, they are. and if they want to restrict it further they can by instead of using a Collection of Objects, they can have a Collection<Cat> which will only contains Cats. bruce |