Lambda the Ultimate

Have fun in your new language designing endeavor!

However, I have to warn you that Haskell does have a few of the features you mentioned it didn't. Overloading, multiple dispatch and multiple inheritance can all be easily done with type classes.

As for agents, you should look at Concurrent Haskell (built into GHC), and O'Haskell (now Timber).

As for sub-syntaxes, GHC supports quasiquoting.

I'm not saying your language isn't worth working on - just be familiar with these alternatives. Also, Oz has a great concurrency model, you should check that out.

I commend your favoring of actors, functional, and what is effectively structural typing. I made some similar decisions in my own language design, though your particular design for 'agents' is something I find highly dubious.

To support networks, I might suggest you put some effort into an object/actor configuration language - in particular one targeted for distributed systems and potentially for automatic distribution.

To support networks, you should also consider being rid of 'System' including such things as 'System.console' (as seen here). In a network or distributed system, there is no such thing as a single 'console' or a global timer, and so the binding of these is an open question. Further, global capabilities are a bad idea for security (see motivations for object-capability security), and for testing (which benefits from ability to support confinement by construction - something difficult to do when code can directly name global agents like the console), and various other purposes.

You'll also need considerably greater consideration towards partial failures. This affects your language from the bottom up and top down, since it is a highly cross-cutting concern.

On the opposite, actors are “alive” indepedent processes with transactional memory.

An actor is basically like a server. It receives and sends messages, and can also start/stop other agents. By “transactional state”, we mean that state is associated to a “conversation”; not to the actor itself, as opposed to objects having a global shared state. As a consequence actors are free of concurrency issues.

I have a feeling this use of 'transactional memory' is going to become dreadfully confused with software transactional memory and such possibilities as transactional actors model and process calculi for transactions.

Yet Another Programming Language

Your introduction quotes Edwin Walder as saying "Programming languages are like religions". I don't think its current self-deprecating name is going to win you many believers.

You inherently have races with agents, just not within them. It's the trendy thing to do, but take it with a grain of salt...

[edit: I don't see how advocating agents is tantamount to advocating safe concurrent programming. while it makes it easier to implement some higher level solutions, ultimately, it is incomplete on its own, similar to advocating programming with capabilities.]

"Network oriented" is how you described your language.

It combines major paradigms, is implicitly parallel, network oriented, leverages means of combination & abstraction …and much more.

Was I wrong in taking that to mean you aim to support networks?

I'm not sure where the emphasis on "server" came from. Server is a role for a process on a network, not a primitive.

Again, making distributed agents is just one step away. As for the 'System.console' and the timer, they are meant to be local ones.

Referencing a local System.console and timers as agents directly within the language constitutes a significant step back from ever achieving distributed agents: a problem arises when a mobile or distributed agent decides to print to System.console. A console should be a plain-old-agent, obtained (for object-capability security) by parametric reference.

Timers are a bit different; a distributed agent can use the most local 'time' function and be reasonably certain that the semantics hold across calls. Other features in this same class would be subscribing to a timer, asking for random values, and leveraging the HTTP cache or the local domain-name server. I've done some work towards ambient services in an object capability system, providing a significant optimization for distributed agents without sacrifice of object capability and its associated advantages for systems testing and security.

A recent comment from Andrej Bauer: What [designers] often do not see is that they could have achieved the same advantages in a different way, without introducing the disadvantages. Therefore, it is very important to get the order right: first make sure the design avoids the disadvantages, then think about how to get the advantages back.

I feel it's sound advice.

But, before one can make an informed design decision, one must first recognize the sacrifice or the disadvantages being accepted. In accepting 'System.console', you're accepting a major blow towards ever making that last step towards distributed agents.

Referencing a local System.console and timers as agents directly within the language constitutes a significant step back from ever achieving distributed agents: a problem arises when a mobile or distributed agent decides to print to System.console. A console should be a plain-old-agent, obtained (for object-capability security) by parametric reference.

While I generally agree, a disciplined form of dynamic binding could also solve this problem without making everything parametric.

How do your agents compare with erlang processes? Both have independent execution threads and message queues. Anything in the "few others" that might set your agents apart? For Erlang, the messages in a process' queue may not be processed sequentially I think. In any case, any semantics that depends on the message arrival sequence seems a bit fragile to me. Rgd your bank account example, it shouldn't matter whether your agent processes the two withdrawal requests in order of arrival or out of order.