A programming Language Idea

Please tell me if this already exists, or if its a stupid idea, but I've been thinking about a possible programming language focused on multithreading. It achieves this with jobs, which are ran in individual threads, Each job corresponds to a single function, and these functions can wait for input from other streams. Each instance of a function has a unique internal state, which is usually shared wholesale to other functions with Send(). The states can be built up on the fly without the use of templates, instead, you can check if a slot exists or is of a given type (How? i'm not sure yet) There are no global states, unless you have a 'main' thread that only has one function, which is to await for input and send what is wanted back to them. Here's an example of what I mean, it reads and 'sanitizes' input with one thread, and prints it out with two other streams. Threads : 'Main //Unique symbols that represent each given stream 'Another 'Input Function Get //Get the name of a person //Get the age of a person, and sanitize it Store age = //age Store name //name //This is the internal state of this function, and it will be usually the one that is sent Send(['Main 'Another],'All) //Send specifically to the two streams, the tag doesn't matter, since Read is already looking for anything End Function Read //let is a temporary variable let person = Wait('Input,'All) //1st parameter chooses specific stream to 'look at' //2nd parameter specifies the 'tag' when it is sent, //You can put the symbols in parenthesis, or 'All can be used to search for any given stream/tag Print("Your name is #, and you are #.",person->name,person->age) End Launch : 'Main = Read 'Another = Read //Because there's two instances of Read in two different streams, they'll both be ran. 'Input = Get I'm sorry if this seems like noise, but its something that i wanted out of my brain before it rots.

Literally Erlang/Elixir short or empty

Good idea Prior art: Occam, Erlang, Pony, ConcurrentML,

>>33402 Basically Erlang. But if you cane up with it yourself you should be a little proud. It's a good thought. You should implement it though, just for some good experience, who knows it might be a better implementation than erlang :D

>>33402 This is the actor model of computation. Sorry, you're a couple decades late, it happens.

>>33408 are there any languages that implement only this model?

>>33410 You might want to look into Erlang. Its platform has a deep focus on the Actor model, incl. supervisor actors to manage actors with bad state and so on.

Always nice to see people trying to come up with new ideas. Your language aims at the core of the concurrency problem, and applies the 'share data by communicating' principle, and any language that does that is automatically worth a second look by my book. Send() doesn't take a value argument - functions can't choose what they send, they always send their whole 'state'. This is, superficially, a limitation, but I think it's a good one - the kind that makes you design your program better. You provide 'let' to differentiate local variables from shared state, so there's no problem there. Myself, I'd like to go further and mandate that the contents of a function's 'state' are declared in the signature or at the top, so you can tell at a glance what values to expect from it. As for streams, if I read you correctly, each 'thread' has a stream generated for it automatically, and the 'thread' names doubles as a stream name, with the names being global and visible to all jobs. This is why Send() and Wait() take 'thread' names as arguments. What's interesting is that BOTH Send() and Wait() take a stream argument, and that was either an oversight or an interesting idea. See, if the argument is supposed to be the stream to write to / read from in both cases ( Send(STREAM, TOPIC) / Wait(STREAM, TOPIC) ), then the jobs aren't actually talking to each other: Function Get // which is bound to thread 'Input at launch time // body omitted Send(['Main 'Another],'All) // write to streams 'Main and 'Another End Function Read // bound to threads 'Main and 'Another let person = Wait('Input,'All) // read from stream 'Input, which no one is writing to // body omitted End But that'd be stupid - if a thread has a stream bound to it automatically, why would it need to pass the stream name as argument always? It makes more sense to think that, at least in one of the cases, the argument is not the name of the stream to use, but a tag. Suppose the argument to Send() is indeed the stream to write to ( Send(STREAM, TOPIC) ), but the argument to Wait() is a tag ( Wait(TAG, TOPIC) ). Then this means that messages are tagged not only by topic, but also by sender, with receivers being able to listen only to messages coming from specific jobs. Send() automatically adds the thread's name as sender tag. And if the argument to both Send() and Wait() is a tag, and not a stream ( Send(RECIPIENT, TOPIC) / Wait(SENDER, TOPIC) ), then, instead of one stream per thread, what you have is one global message queue, with messages being tagged by sender, receiver and topic. Regardless, however, of whether all this was your idea, or my misunderstanding, or a mistake, what's clear is that you do intend for messages to be tagged, and filterable, by 'topic', and that is enough to raise a question whose answer could make or break this language. That is: when Wait()ing for a particular topic, what happens to messages that don't match - are they all discarded until a match is found, or do they stay in the queue to be fetched by a later Wait()? Discarding them is, I think, obviously a terrible idea, but keeping them around poses some interesting implementation problems. Difficulties aside, however, tagged message queues are, as far as I know, an original idea, and well worth exploring.

>>33410 What does "only" mean? You can implement OOP or FP features using actors, so even if it only had actors, a library could provide "the rest".

>>33417 The intention with Wait was to avoid desynchronization. There was another function called Await that didn't stop for input, and instead just continued running until it received something, then it jumped to a label or ran a lambda/block of code. As for why Wait and Send both ask for the chosen stream, I was worried about what would happen if only one of the functions stated the stream to be sent to/read from. Finally, I think it would be better if messages are only destroyed if both the sending and receiving stream don't have any instances, but that may break things, so another possibility is to have a command line interface that can watch actors send messages, so if there's any floating messages, they can be destroyed. Admittedly, I have no idea if this will be viable unless I try. So I'll have to spit out a beta first to see. >>33419 I meant a language that only implements the actor model.

Make a APL with actor model features.