I just wanted to quickly answer a few questions and explain why the language exists at all. The points below are pretty much incomplete and in random order, with no clear thread among them. I hope they're useful anyway:
Cell was designed first and foremost to combine functional programming and the relational model, with the former providing the computational capabilities and the latter the ability to easily encode, navigate and update complex information/state, with many different types of entities and relationships between them.
It also borrows other ideas from the database world: chief among them is the practice of removing all forms of redundancy from the data structures that are used to encode the state of an application. There are two main reasons for this: first of all, a data structure that contains little or no redundancy is much less likely to be left in an inconsistent state by a buggy update. Secondly, the code that updates the state of the application becomes a lot simpler, because there are fewer things to update.
Redundancy includes not only information that is duplicated, but also information that can be derived by other information that is already present in the dataset. Eliminating derived information is more difficult than doing the same with duplicate information of course, because there are in many cases performance issues. In order to address those, Cell is meant to include several form of memoization, but that's a long-term effort.
A paper that came out more than a decade ago, "Out of the tar pit" (google it), explains in more detail the notion of "essential state" and the idea of combining functional programming and the relational model. I'm not connected in any way to the authors of that paper, and the particular flavor of the relational model implemented in Cell is very different from the one advocated in that paper, but until the documentation on the website is complete, that's probably the best reference to those ideas I can point you too.
I believe the relational model is by far the best data model I know of, and that it's far superior to the records+pointers data model used by most programming languages, and by object-oriented languages in particular. I can't explain why in just a few lines, though. It's a part of the website/documentation I'm still working on, but which I hope to put out relatively soon. Note however that the relational model is not the same thing as SQL: in relational databases the relational model is saddled with a number of limitations that would not be acceptable for a programming language (like the fact that the types of the columns in a relation/table can only be chosen from a few predefined datatypes) and SQL itself is of course an abomination of a query language. But that's not the only way to do it, just like C++ is not the only way to do OOP.
Cell is not meant to be an alternative to spreadsheets, or to do computational biology (I'm actually starting to suspect the choice of name is a rather unfortunate one). It's not meant to write compilers either. Quite the opposite, actually: it's designed to build stateful systems. Of course, functional languages are in general a pretty good choice for writing compilers, and Cell does have a (semi-)functional subset, which was used to write the compiler.
The target application for Cell is actually a particular type of stateful systems. Let's agree to call them "reactive systems", or maybe "event-driven systems", in what follows. These systems are usually at rest (meaning that there's no code being executed, no call stack, and no instruction pointer) and when they are the only property they have is their state. They react to external events by changing their state, which is conceptually an atomic, all-or-nothing operation. Their new state after an event depends only on the state before the event and the event itself. They do not do any sort of I/O, and are totally oblivious to the world around them.
It's a very general concept, that can be applied to many types of applications. An example is the Elm architecture. In order to define an application in Elm, you've to define the type of the state of your web application; an initial state for your application; the types of all messages your application can receive; and a transition function that given the current state of the application and a message returns the new state of the application. There's actually more than this, but let's ignore that for now.
Static automata work in a similar way. The two main differences is that you can make use of the relational model to define the type of the application state (as if you were defining a small database schema) and that the transition function instead of returning the new state of the application returns a set of atomic update operations (set/insert/delete/update) that are applied to the current state to produce the new one. This is similar to what you do to update the data contained in a database: you just send a set of atomic insert/delete/update command that are executed by the DBMS.
I'll stop here, this post is already too long. Maybe I'll post more tomorrow, if anyone is still around. Does this make things a bit clearer?
> Maybe I'll post more tomorrow, if anyone is still around.
I can only speak for myself but I will definitely be around to read another post if you write one.
The design is fascinating and I'm very excited to see a new language that combines functional, relational, and reactive elements.
One design choice that I'm particularly interested in is your choice to fix the set of possible values in a way that supports generic value introspection and orthogonal persistence. There are clear benefits but some costs include possible obstacles to abstraction / modularity and also extensibility. I'm wondering how you see these trade-offs.
(Replying to my own comment because I don't see a way to edit it.)
Another question I have is about recursion. Browsing through the code a little bit, I see loops and comprehensions are often used but I'm not sure I've seen a single recursive function. Is recursion something you've consciously tried to avoid and if so can you speak about the rationale on that topic?
I just wanted to quickly answer a few questions and explain why the language exists at all. The points below are pretty much incomplete and in random order, with no clear thread among them. I hope they're useful anyway:
Cell was designed first and foremost to combine functional programming and the relational model, with the former providing the computational capabilities and the latter the ability to easily encode, navigate and update complex information/state, with many different types of entities and relationships between them.
It also borrows other ideas from the database world: chief among them is the practice of removing all forms of redundancy from the data structures that are used to encode the state of an application. There are two main reasons for this: first of all, a data structure that contains little or no redundancy is much less likely to be left in an inconsistent state by a buggy update. Secondly, the code that updates the state of the application becomes a lot simpler, because there are fewer things to update.
Redundancy includes not only information that is duplicated, but also information that can be derived by other information that is already present in the dataset. Eliminating derived information is more difficult than doing the same with duplicate information of course, because there are in many cases performance issues. In order to address those, Cell is meant to include several form of memoization, but that's a long-term effort.
A paper that came out more than a decade ago, "Out of the tar pit" (google it), explains in more detail the notion of "essential state" and the idea of combining functional programming and the relational model. I'm not connected in any way to the authors of that paper, and the particular flavor of the relational model implemented in Cell is very different from the one advocated in that paper, but until the documentation on the website is complete, that's probably the best reference to those ideas I can point you too.
I believe the relational model is by far the best data model I know of, and that it's far superior to the records+pointers data model used by most programming languages, and by object-oriented languages in particular. I can't explain why in just a few lines, though. It's a part of the website/documentation I'm still working on, but which I hope to put out relatively soon. Note however that the relational model is not the same thing as SQL: in relational databases the relational model is saddled with a number of limitations that would not be acceptable for a programming language (like the fact that the types of the columns in a relation/table can only be chosen from a few predefined datatypes) and SQL itself is of course an abomination of a query language. But that's not the only way to do it, just like C++ is not the only way to do OOP.
Cell is not meant to be an alternative to spreadsheets, or to do computational biology (I'm actually starting to suspect the choice of name is a rather unfortunate one). It's not meant to write compilers either. Quite the opposite, actually: it's designed to build stateful systems. Of course, functional languages are in general a pretty good choice for writing compilers, and Cell does have a (semi-)functional subset, which was used to write the compiler.
The target application for Cell is actually a particular type of stateful systems. Let's agree to call them "reactive systems", or maybe "event-driven systems", in what follows. These systems are usually at rest (meaning that there's no code being executed, no call stack, and no instruction pointer) and when they are the only property they have is their state. They react to external events by changing their state, which is conceptually an atomic, all-or-nothing operation. Their new state after an event depends only on the state before the event and the event itself. They do not do any sort of I/O, and are totally oblivious to the world around them.
It's a very general concept, that can be applied to many types of applications. An example is the Elm architecture. In order to define an application in Elm, you've to define the type of the state of your web application; an initial state for your application; the types of all messages your application can receive; and a transition function that given the current state of the application and a message returns the new state of the application. There's actually more than this, but let's ignore that for now.
Static automata work in a similar way. The two main differences is that you can make use of the relational model to define the type of the application state (as if you were defining a small database schema) and that the transition function instead of returning the new state of the application returns a set of atomic update operations (set/insert/delete/update) that are applied to the current state to produce the new one. This is similar to what you do to update the data contained in a database: you just send a set of atomic insert/delete/update command that are executed by the DBMS.
I'll stop here, this post is already too long. Maybe I'll post more tomorrow, if anyone is still around. Does this make things a bit clearer?