Talk:ToonTalk

Object

The article makes this parenthetical remark: ("Object" here does not mean in the object-oriented programming sense, but rather in the everyday sense where if I give you an object, I don't have it anymore). I don't understand what distinction is being alluded to. In OOP an object is an instance of an abstract class. The particular number of objects at play in a program is well defined. If some notion of exclusive ownership is defined in a program then transfer of ownership of Object A to owner J is certainly accompanied by loss of ownership by owner I. I could also point out that two people can hold an object at the same time. This seems like some artificial constraints are being applied in order to draw a distinction between two things that, in principle, can be arbitrarily similar. Did the author of this remark confuse an object with a class? 71.236.215.87 (talk) 22:09, 1 June 2009 (UTC)

OK, I need to think about how to edit the article to clear up the ambiguity you refer to above. In OO languages, the term "object" carries several important components of meaning that are special to the OO jargon. The programming language Self provides a good generic example of what "object" means in OO jargon. An agent in Self can pass a reference to an object to any number of other agents, who can act on that reference by sending commands to the object. The object can reply to commands by returning information about itself. It can also mutate itself in response to receiving a command. This mutation can affect the object's response to commands it receives in its future.

In the article, I wanted to use the term "object" more the way it is used in everyday English to refer to things, without importing the senses of OO's use of the term. Take for example a two-hole box in ToonTalk. A process can pass this box to another process. There is no way to extract a reference to the box and pass that around. Only one agent can hold the box. There are references in ToonTalk; they take the form of birds. A bird is a reference to the nests it flies to; it cannot be a reference to a box, to a number pad, to a text pad, or to another bird. So there are several types of object in ToonTalk that cannot be referenced, and this makes them fundamentally different from OO objects such as you have in Self for example, as those can be referenced.

Perhaps an adequate solution will be to substitute "thing" where I used "object" and delete the parenthesis.

Jack Waugh (talk) 03:18, 6 December 2011 (UTC)

Notability

This article has been challenged on the grounds that ToonTalk is not a notable programming language, or that I haven't cited sources that say it is. I wish to argue that the notability of ToonTalk stems from its being one of very few concurrent constraint languages that have implementations going beyond the size of an academic "toy" implementation. Further, I would like to submit that concurrent constraint languages constitute a notable class of programming languages, but I'm at the moment too lazy on this to chase down the citations to convince you of that. Concurrent constraint languages are declarative. They address concurrency without shared memory. For the most part, they shy away from allowing the order of the commands or statements in the smallest program unit (a method or a rule or whatever) from having effect on the externally observable behavior of an execution of the unit. I submit that there is reason to regard the concurrent-constraint paradigm as a serious candidate to be one of the contributing ideas toward what should be the future of computer programming. Jack Waugh (talk) 03:36, 6 December 2011 (UTC)

I removed

on the grounds that several references have been added. Some additional discussion appears at http://tech.groups.yahoo.com/group/ToonTalk/message/857 . Jack Waugh (talk) 16:14, 13 July 2012 (UTC)

References

The article was marked as not citing any sources. I reference a paper by Morgado and Kahn. Jack Waugh (talk) 03:24, 6 December 2011 (UTC)