Lambda the Ultimate

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).
  

Google Summer of Code 2007 is now on. Among the projects suggested by mentoring organizations, quite a few may be of interest to language hackers.

Here are some organizations that have interesting (language oriented) project ideas: Boost C++, Haskell.org, Jikes RVM, LLVM, PHP and Python.

When replying, if you leave the subject field blank the current default is to take the first n characters of your post and make that the subject. Alternatively, you can supply your own subject.

This leads to a mix of comments using both approaches. I would like to read the subject if the user supplied their own. However, if the user did not supply their own, I end up reading the same thing twice, which takes me out of my "flow".

Would it be possible to have the default subject be the same as the previous subject, with an "Re: " prepended? That would be a good visual cue when reading, to make it easy to skip over them.

Note that I'm not advocating in any way whether people supply their own subjects or not. It's nice to have both options and let the user choose.