Syntax Solicited for Imperative-flavored Concurrent Language with Keywords

Who would be willing to suggest a syntax to go with the semantics I allude to here?

Since the language I am hinting at here (thinking to flesh a definition out, once someone else has drafted a syntax) does not try for referential transparency, and therefore retains sort of an imperative flavor, I assign the langauge the working title, Imperatrix Mundi. If someone wants to suggest another name, maybe I'd favor adopting such suggested name instead.

I think it could be interesting (for me with help and suggestions from you readers) to flesh out a language of this sort, even though for some years I have been thinking a referentially transparent (RT) language would be the ultimate way to go. I suggest Imperatrix Mundi as an intermediate step in a possible evolution toward an eventual RT language for general computer programming purposes that don't require blindingly fast performance nor specialization to an unusual application area.

For talking about the message passing in this language, I borrow the terms "bird" and "nest" from ToonTalk, but with some semantic differences, chief among them being that whereas in ToonTalk, bird/nest channels guarantee that the messages read off the nest come in the same order as they were handed to the bird, in this language I say that the order of the messages is not guaranteed to be preserved.

This language does not try for referential transparency. However, it must meet a weaker requirement, that the values (or references or meanings) denoted by the occurrences of a given identifier in a given context could be exchanged with each other without changing the semantics of the segment of code occupying the context. This should happen because of don't-care nondeterminism. For example, suppose a <- b is a command meaning to send a message denoted by b via a bird denoted by a, and the code says a <- b; a <- c. What this would mean is that the message stream sent along 'a' is some random merge of a1 with a2; a1 <- b; a2 <- c. The bird, 'a', would get the messages b and c, and whoever is reading the nest at the other end could get b before c or c before b.

A segment of code consists of a bag of commands (or statements if you prefer to think of them that way); the order of the commands cannot affect the meaning of the segment.

List of semantic constructs that need syntactic expression:

The usual complement of literals that a language would have.
Manifest a bird/nest pair out of thin air.
Compose a message from a word to function as a verb, and from a list of keyword/argument pairs. For example, {bletch foo: 2; bar: 3;} could mean a message with verb bletch and keywords foo and bar associated to values 2 and 3 respectively. {bletch bar: 3; foo: 2;} would be the same message, because the order of the keywords does not matter. {bletch bar: 2; foo: 3;} would be a different message, because the association of the arguments to their respective keywords does matter.
Send a message via a bird, and optionally capture a result (which would be a nest). Failing to capture the result should change the semantics of the message in a way detectible by the process that eventually receives the message from the nest associated to the bird (argue against this distinction if you think it's a bad idea).
Send a message to any value, and capture a result. For example 2 + 2 could be interpreted as a message {+ : 2} (where the naked colon indicates an empty keyword) being sent to the value 2, and the result should be 4.
Associate a nest to a process that is an instance of a class, so that the process will interpret the stream of messages arriving on the nest.
Instantiate a process from a class by sending the class a message and capturing the resulting new process.
Define a class with methods. Each method should have a header that can match messages based on their verbs and keywords. Maybe it should be possible to make some keywords optional in the sense that the method would be invoked even if the optional keywords are not supplied in the message. The class definition should also provide for message patterns for creating an instance from the class (class methods). There may need to be a definition of parameters that would be given values in the instances (instance variables).
Refer to a value to be taken from a nest.
Compose a list of values.
Quote functions for passing to map functions, etc.
Quote code for conditional execution.
Disappear the current process, but capture the residue of the nest it has been interpreting (e. g., to pass the residual nest as an argument in some message).

Avian symbols

OK so for a bird taking off you can do:

/p'\      ^p'^       ^,o'/      --,o'--

For a small bird on a branch:

For a big nest:

(%%%)

A small nest:

Hope that helps.
;-)

By Denis Bredelet -jido at Thu, 2007-03-15 21:43 | login or register to post comments

Imperatrix Ornothologica

http://www.toontalk.com/english/computer.htm

Wow. ToonTalk appears to be a serious product to teach concurrent constraint programming, to children, by means of the following metaphors:

computation :: city
actor or process or object :: house
methods :: robots
method preconditions :: contents of thought bubble
method actions :: actions taught to robot
tuples or messages or vectors :: boxes
actor spawning :: loaded trucks
actor termination :: bombs
channel transmit capabilities :: birds
channel receive capabilities :: nests

Another way to understand the computational model of ToonTalk is to consider what you can train robots to do:

send a message by giving a box or pad to a bird,
spawn a new agent by dropping a box and a team of robots into a truck,
perform simple primitive operations (e.g. +, -, *) by dropping a pad on a pad
terminate an agent by setting off a bomb

Again, wow. That's one hell of a metaphor there!

By Tim Sweeney at Fri, 2007-03-16 02:18 | login or register to post comments

Metaphoritis?

Indeed, but is there any evidence that children find these metaphors helpful, or do they find them as distracting as adults do? I understand the actor model, but the metaphors have always put me off Toontalk.

By dhopwood at Sun, 2007-03-18 17:19 | login or register to post comments

fundamental assumptions

I'm not sure that you need any special syntax at all. Have you considered simply using a basic, generally applicable syntax with few or no keywords to start, and adding syntax only if it brings real value to the language? It makes sense to validate the utility of your semantics by actually making use of them before worrying about syntactical issues.

I'm not making the argument that syntax isn't important, so you can just put it off until later. I'm rather making the point that syntax is far too important to guess at before your semantics are nailed down and well-tested. Perhaps I've misunderstood and you already have a working implementation.

By John Nowak at Fri, 2007-03-16 06:33 | login or register to post comments

basic, generally applicable syntax

Have you considered simply using a basic, generally applicable syntax with few or no keywords to start . . . Do you mean such as for example, S-expressions as in Lisp?

(send (via a-bird) (message the-verb (key1 arg1) (key2 arg2)))

By Jack Waugh at Fri, 2007-03-16 15:18 | login or register to post comments

well...

Yes, that's what I had in mind. :-)

By John Nowak at Sat, 2007-03-17 09:23 | login or register to post comments

Terms

Perhaps the "bird", "nest" metaphor is too distracting. We can as well speak of communication "channels" each of which has two ends (which can be referred to with identifiers), the "teller" and the "asker". The inventors of the Janus language used those terms, "teller" and "asker".

By Jack Waugh at Fri, 2007-03-16 19:19 | login or register to post comments

occam and occam-pi

Have you looked at the syntax of occam, and it successor occam-pi? Both are imperative languages that utilize message-passing concurrency. Granted, I'm not a huge fan of the ALL CAPS KEYWORDS, which seem a bit dated these days. But other than that, the syntax is very clean and easy to use.

By Allan McInnes at Sat, 2007-03-17 01:43 | login or register to post comments

pre processor?

I've a) always been super interested in what occam and occam-pi have to offer b) always been super turned off by their syntax. You'd think somebody (cough cough*) would release a little pre-processor to turn pretty syntax into the core syntax. Or something (like just use JCSP, I guess).

* as in, i should get off my own lazy butt.

By raould at Mon, 2007-03-19 18:35 | login or register to post comments

Occam syntax

I'm not aware of any preprocessors for occam (doesn't mean they don't exist of course, but they're apparently fairly obscure). The language (excluding some of the more exotic occam-pi extensions) is fairly simple though, so I imagine a preprocessor of some sort would be relatively straightforward to implement.

The subject of updating occam's syntax has come up a number of times in the community (see this thread on the occam mailing list to get a feel for the pro and con arguments). There are a few recent suggestions for improvements to the occam syntax floating around, and from the look of things some of those have even become occam enhancement proposals. Meanwhile, Fred Barnes (current primary developer on the KRoC occam-pi compiler) is hard at work on a new occam compiler which has the explicit goal of making it "reasonably easy to support other language syntaxes (e.g. a C-style syntax)". So there's a good chance that we may get to see some alternative occam syntaxes in the near future.

By Allan McInnes at Tue, 2007-03-20 03:12 | login or register to post comments

Syntax from Occam

The Occam link leads to http://frmb.org/occtutor.html, an easy tutorial introduction. Yes, the use of "?" and "!" as the "get" and "put" operators, as well as to identify the ends of a newly declared channel, could be worth copying, if I get past the stage correctly identified by John Nowak in his posting above, where I should implement something before trying to narrow the syntax too precisely.

Thanks for all the responses to my query.

By Jack Waugh at Mon, 2007-03-19 16:06 | login or register to post comments

Lambda the Ultimate

User login

Navigation