YAPL - yet another programming language


Basically, I would like to present you yet another programming language.
It is in its early stage. Nevertheless, I would like to know how it is perceived and what you think of it.
All details can be found here:


Any feedback and critique is very welcome.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What makes it not Haskell?

So far all I see is Haskell.

Haskell could be seen as a subset with differences

It is partly inspired from haskell ...they share similarities about two concepts: functional prog & algebraic data types. Similar but not identical. For instance, in Arplan, functions allow overloading (for both aguments & results with multi-dispatch). The typing system has some slight differences too, for instance it allows (multiple) inheritance. ...there are more such small differences, but these can already change a great deal of things. In fact, the language is closer to Dylan than Haskell.

Moreover, there are especially two additional big concepts: agents & sub-syntaxes. I have yet to continue to document them well and add examples. Agents are a bit the counterpart of functional programming, more like mini-servers with queuing. It is closer to OO but still different. ...The documentation is insufficient, I know. The other big concept are sub-syntaxes, I haven't seen this feature in another PL yet and should be seen as a "strong" feature as it is more powerful/expressive than macros.

...Somehow, Haskell could be seen as a subset of the language with small (but fundamental) differences.

But, yeah, you are right. With the current content, one can only see Haskell. It's somehow just the part I started with.

Multiple dispatch

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.

It seems the most

It seems the most interesting parts of the language are not yet documented (agents and sub-syntaxes). Mind going into a little more detail? The combination of functional programming + actor based OO has certainly piqued my interest.

peek preview

Thanks for your interest. A few bits of information can already be found at:


A better and detailed documentation is on the way...


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.

Agent != server

Thank you for your interest.

Instead of starting to discuss directly your post, I would like to recapitulate a little ...I feel we don't have the same thing in mind.
I even think we look at it from very different perspectives.

Perhaps I put a little too much emphasis on the word "server" ...since in fact "agents" have nothing to do with the network. An agent is not a server. Making a server was just one possible use of them. Agents are meant to be very primitive, low level constructs, like objects in OO. And in fact, they are very close, with following differences:
- they run independently (no thread of control)
- they treat incoming messages one after another
- a few others...
That defines probaly all we need. This avoids race conditions inside of agents. In the classical example with a bank account, when two concurrent processes call 'withdraw' at the same time, these messages will be handled one after another and thus ensure the balance is ok. (again, this is not meant to be a networked example). It is like objects with solely synchronized methods and built-in message queues. Agents are like mini-servers but at a very primitive level, like functions and data. Using these, you can however build full fledged servers and interact with remote ressources, as you could do with OO.

...It is just a few steps away to build more ellaborate agents controlling other remote agents, defining some network wide ressource identifiers, publishing services, requesting ones, reading configurations files, sending instructions accross the network...

But one should clearly separate what is a core construct of the language and what is provided using libraries/frameworks. Everything having to do with distributed computing is meant to be done via such a library, made of elaborated agents, able to do the stuff mentionned above. It is a layer above and not primitive constructs. The "agent" construct in arplan is used to achieve low-level concurrency and parallelism. Again, making distributed agents is just one step away. As for the 'System.console' and the timer, they are meant to be local ones.

...and thanks for the interesting links!

You inherently have races

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

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

A step back from distributed agents.

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

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.

agents vs. erlang processes

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.

...needs some maturation

Thanks for you comments & links. I especially appreciated:

You inherently have races with agents, just not within them.

So true ...and there is no silver bullet for this. Concurrency is just a fact of life.

As for dmbarbour, I think you are right. My concept of agent is too blury for the moment and needs some maturation. There is clearly room for improvement. I'm working on it.

On the other side, it still looks perfectly fine to me to reference local "agents" like the console and timer. For instance, this works the same way in Orc:
It references prompts and timers the same way as remote services.