The Factorio Programming Language/Compiler (split off from We need more control over bots)

[Eketek]

this thread is split from viewtopic.php?f=5&t=99001 We need more control over bots

You need to carefully read the first 4-5 articles where the idea, that combinators / circuit network is indeed a programming language is developed.
— ssilk

The easiest solution would be two types of bots. Current bots as basic bots and then high tech-bots with sophisticated and preferable programmable logic. Megabase builders could use current UPS-cheap bots and logistic nerds could use smaller numbers of sophisticated bots to achieve complicated functions (or even reasonable basic operation).

I think that "high-tech" robots would be interesting if a Befunge-like programming language is used for them (program represented as a physical arrangement of objects or signals from circuit-connected objects, program execution accomplished by robots driving around and scanning things for commands).

If this would be enabled, what is then the difference between a computer controlled robot and a computer controlled player with a jet pack?

I mean this: it’s already possible to make a mod, that spawns another player that does more or less clever things.
And it’s also possible (?) to control bots like so.

What new game-play would that enable? That’s the good question here. And I mean: nothing special. The only really interesting thing would be, to let those computer controlled “players” build a factory, like JOSEF in https://alt-f4.blog/ALTF4-39/ . Anything else would be just more comfort for more complexity and less speed.

So, just more control (programmable) over bots without a very good and specific argument why that would enable a better game-play is a “shoot against the wind”. A very specific new ability for the bots to make a specific situation more controllable is on the other hand something, that could be thought about, but also here: there are already some suggestions about more clever routing of bots. Will not implemented, because of the extra CPU it takes for this task.

In terms of gameplay, I think the main addition befunge-like programmable automatons would add to Factorio is visual programming.

The intent with my previous post was to suggest something [to any would-be modders] that can be accomplished through the modding interface.

I am also quite aware that all current logistics systems are subject to heavy optimization, so if I must stick with suggestions involving the internals, I'd probably have to make a few wild guesses... maybe allow mods to promise to satisfy logistics requests (either passively by letting the mod call a function when it wants to dispatch its own bot(s) or actively by raising events when supplies & requests are updated) and allow mods to specify SIMD programs to move particles and/or lightweight entities around (presumably to be handled by a relatively heavyweight controller which is only active if/when enabled by mods, so as to avoid having to add extra logic to the bot controller).

[ssilk]

@Eketek I won’t destroy ideas, but I need to say, you underestimate how much slower such a mod would be in comparison to pure c++. We speak here about a factor between 100 to 10000 times slower. Meaning where Factorio core controls 10000 bots a mod can control one (or ten or maybe and with much optimization 100). That is about the numbers we need to deal with here.

Which doesn’t mean that the idea is useless. Because - and now we are at Krazyrkl’s post - there are already some suggestions about somehow flying roboports or similar things. One of the best I think are robots that act like a supply-chest and request the number of items to build a blueprint, fly to that area and supply the construction bots. But I got distracted.

What I liked with idea of befunge-like programming language is, that it reminds me to how JOSEF works (also in 2-dimensional cells).

Keep also in mind:
1. It is possible (should be) to translate any programming language into another, as long as they are Turing-complete. Which means you can translate any program into a network of combinators. (I’m just not 100% sure, if combinators are really Turing-complete)
2. Now you have some crazy complex build, that can do things that works with the same simple logic as a computer program. (It’s difficult to use terms like simple and complex here, but I don’t know how to make it better in this context.) The point is: You can make a blueprint out of that. And you can print it somewhere else. Which means, that a blueprint can store programs in “Factorio-language”.
3. And now, what’s missing to have a self-growing factory (imitate biological life) is this:
3.1 Sensors. Is there “food” (resources, aka iron, copper, oil…)? Is there stonewall? Can it see, what the radar sees? Enemies in sight?
3.2 Copy yourself. Make a blueprint of yourself. Move to another place and “plant” this copy.
3.3 Enable changes. Either through errors when copying or other random changes. And implement some kind of fitness measures - to compare two copies and enable choose the “better”.

Well all quite theoretically and I’m not sure if everyone could follow me. but this post is already too long and I won’t explain it in detail, I just want to bring in new thoughts.

And to close the circle: I can think of something, that tries to avoid the situation that has been described in OT above. Instead of giving every bot a “brain” it would be enough to have one brain, that “sees”: “oh, we want to clear roboports, so we do that roboport by roboport to make sure that nothing get stuck.”

That would be much more interesting (in my opinion), that would add a lot of new game-play and it would be possible to implement it as mod first, because one “brain” can be easily handled (but not hundreds).

[eradicator]

Meaning where Factorio core controls 10000 bots a mod can control one
[...]
befunge-like programming language

Reminded me of the Logistic Carts mod. Not sure how much circuit magic can be done with Transport Drones but it's probably a good estimate for performance cost.

[Qon]

What I liked with idea of befunge-like programming language is, that it reminds me to how JOSEF works (also in 2-dimensional cells).

Isn't combinators already programming in factorio? Why add another language?

(I’m just not 100% sure, if combinators are really Turing-complete)

They are. You only need deciders which can check a single signal, like X, which outputs 1 on X if X is 0 (negation) to build a complete CPU in Factorio. Signals adding together automatically makes them implicit OR gates. We don't even actually need values besides 0 and 1 for this either. It would be really slow to do it this way...

To work with all kinds of signals you don't just want Turing completeness though. That only tells you if any function is computable. But the combinators can handle more than a single signal type and can handle many more operations "quickly". We can actually do fairly straight forward translations from a normal text programming language into combinators.

Screenshot from 2021-07-04 21-31-35.png (3.54 MiB) Viewed 7670 times

Top part is a program with conditional goto that sends signals on the red wire to the big grid thing below and branches depending on the answer given on the green wire. Black signal is an instruction pointer (red is translated into black, used for jumps). Only the program line with where the black signal matches the "line number" sends out the signals to the red wire.

The big grid below is a limited and fairly minimal computational unit (not a complete CPU, to make it faster and simpler to control for my usecase) repeating over and over. Each cell can do computations depending on what instructions are sent to it on red wire and responses are sent back on green wire.

These designs are supposed to be used for an an advanced self-expanding factory.

2. Now you have some crazy complex build, that can do things that works with the same simple logic as a computer program. (It’s difficult to use terms like simple and complex here, but I don’t know how to make it better in this context.) The point is: You can make a blueprint out of that. And you can print it somewhere else. Which means, that a blueprint can store programs in “Factorio-language”.

Factorio-language is combinators. And yes they can be blueprinted.

3. And now, what’s missing to have a self-growing factory (imitate biological life) is this:
3.1 Sensors. Is there “food” (resources, aka iron, copper, oil…)? Is there stonewall? Can it see, what the radar sees? Enemies in sight?
3.2 Copy yourself. Make a blueprint of yourself. Move to another place and “plant” this copy.
3.3 Enable changes. Either through errors when copying or other random changes. And implement some kind of fitness measures - to compare two copies and enable choose the “better”.

Recursive blueprints now has a resource scanner. It is limited to "resources" (ores, water, oil, cliffs and nests/worms) though. But that's enough for most cases if you keep track yourself of what you build. But it can do whole areas at once.

AAI Programmable Structures mod adds a single tile scanner that can find more things.

Con Man (Recursive Blueprints alternative) is supposed to be able to copy areas and make blueprints out of them. But it is bugged atm. But if your designs were build once by placing blueprints then you can just do it again to do a copy.

Don't think making random changes to cells is wanted. Things will just break.

[ssilk]

Thanks for this answer. I think this becomes more and more a little bit sidetracked , still a little bit relevant to the OP, but if this continues, I will split this topic.

Some comment:

What I liked with idea of befunge-like programming language is, that it reminds me to how JOSEF works (also in 2-dimensional cells).

Isn't combinators already programming in factorio? Why add another language?

Yes and no.

Yes: The point is, computer programming as we know is one dimensional. A text. A stream of chars. But this befunge makes it two dimensional. And in Factorio we have also this two dimensional component, that was my association. A bit far. But, hell, I see some small commons between befunge and Factorio.

No: I meant a transpiler, that translates a program written for example in LUA to Factorio combinators. The simple version would be to have another LUA program that reads the source and generates a blueprint. The “extended” version would be a mod that reads the source and generates the blueprint in the game. And the superhero version would be to read the source into the game somehow and have a Factorio CPU that makes a blueprint out of that.

(I’m just not 100% sure, if combinators are really Turing-complete)

They are. You only need deciders which can check a single signal,

Yes, I should know that, I was tired when I wrote it to remember correctly.

2. Now you have some crazy complex build, that can do things that works with the same simple logic as a computer program. (It’s difficult to use terms like simple and complex here, but I don’t know how to make it better in this context.) The point is: You can make a blueprint out of that. And you can print it somewhere else. Which means, that a blueprint can store programs in “Factorio-language”.

Factorio-language is combinators. And yes they can be blueprinted.

What I really miss here with the “Factorio language” are these things:
1. Readability. A program is generally much more often read than written. In Factorio this isn’t so, it is designed for writing once and then forget.
2. If you try to read it, you don’t know where to start reading. Because it is two dimensional and you can rotate blueprints into any direction you cannot know where to begin to read and where to end. In “one dimensional computer languages” (like LUA), you normally exactly know where to begin and end. In Factorio you need to “comment” for the reader how to read the program.
3. Even then it is sometimes really difficulty to read the program, because of this pseudo 2D rendering. For example you can put a pole so, that it exactly covers the connectors of a combinator. In some rare cases you have no chance to see how the wires are connected than to copy the circuit, rotate it before pasting to see how the stuff is really connected.
4. If I write one-dimensional programs I can create more space out of nothing (just add more lines where I want to add extra code). In Factorio this isn’t the case. I need to move either things out of the way (loosing the wire connections), or to add the extra-functionality outside, and so completely loosing the order of how to read. I know there are mods to go around this ( https://mods.factorio.com/mod/circuitissimo , https://mods.factorio.com/mod/Factorissimo2 , https://mods.factorio.com/mod/ImprovedCombinator , https://mods.factorio.com/mod/PickerDollies …), but this is only a workaround.
5. Difficult to debug/test: well, there are https://mods.factorio.com/mod/SBS-Combinators and https://mods.factorio.com/mod/controllinator and several mods to see the state of the signals. It feels a bit clumsy. All in all I’m also missing a framework to test the program.
6. Produce items to program. Well, we had that with Gutenberg, where we need to produce the letters before we could print, but that’s centuries away. But in Factorio I need to craft even the wires. https://mods.factorio.com/mod/WireShortcuts
7. No self reference. How many items does a stack of basic circuits have? Such simple questions aren’t possible without modding ( https://mods.factorio.com/mod/stack-combinator ).


Of course I’ve addressed some parts already ( viewtopic.php?f=6&t=41176
viewtopic.php?f=6&t=9092 ) but now, with the idea of two-dimensional programming languages it saw suddenly why this is as it is.

Recursive blueprints now has a resource scanner. It is limited to "resources" (ores, water, oil, cliffs and nests/worms) though. But that's enough for most cases if you keep track yourself of what you build. But it can do whole areas at once.

AAI Programmable Structures mod adds a single tile scanner that can find more things.

Con Man (Recursive Blueprints alternative) is supposed to be able to copy areas and make blueprints out of them. But it is bugged atm. But if your designs were build once by placing blueprints then you can just do it again to do a copy.

While interesting to see, what’s currently possible (and tried out more or less) it feels so clumsy. I mean: see my list above. To check an area you need to have many circuits, all take space and you cannot straight forward program it (at least for the first try), so you need to play around with it for a while. But playing means constant change and that is not really possible here.

Don't think making random changes to cells is wanted. Things will just break.

That random changes was stupid from me - I was too tired to think about the consequences.

[Qon]

Isn't combinators already programming in factorio? Why add another language?

No: I meant a transpiler, that translates a program written for example in LUA to Factorio combinators. The simple version would be to have another LUA program that reads the source and generates a blueprint. The “extended” version would be a mod that reads the source and generates the blueprint in the game. And the superhero version would be to read the source into the game somehow and have a Factorio CPU that makes a blueprint out of that.

I might have to actually make some text-to-combinators compiler to be able to complete my self-playing and self-expanding factory. I considered doing it in Lua before with Lua-combinator mods but I've started on the path on doing it with combinators, so I guess I'll finish it that way too. I have some minor experiments with the designs of combinators that would be useful for being the target of a compiler.

Making factorio-language something that compiles to combinators means combinators are still a part of Factorio. Otherwise combinators would be completely obsoleted if text-code could run in Factorio vanilla and no-one would use combinators again. And people still get the advantage of having text code. And raw combinators can be used to gain a speed advantage over compiled code by doing parallel computations.

What I really miss here with the “Factorio language” are these things:
1. Readability. [...]

Yeah readability is really bad. What I'm doing to mitigate this is for my combinator designs to be placed down in a structured way, similar to the ideas of making your code readable with some empty lines, proper indentation and reasonable line lengths etc. Code is readable because we are taught to make it readable, newbie coders make unreadable code even if it is in text.

But then to fit my designs where I need them I for some cases have to use picker dollies and compress them down to something less readable.
But to make it readable I have a start point, and "all" signals flow in the same direction (except for loops) just like control flow in a program. And "all" combinators on the same distance (along the chosen time axis) from the start of the combinator program have equal amount of combinators before them so they are synchronized tick perfectly. I add deciders (each ~= 0 > each count) or arithmetics (each + 0 = each) to do simple single tick delays to stick to this when necessary. This means I get some kind of indentation and lines similar to text code. It's pretty annoying to only be able to move a single thing with dollies and copy paste loses outside connections, but I at least also reduce my need for moving things around, slightly, if I structure where things belong from the start this way.

But it's still not easy to read or modify, just slightly easier than impossible

5. Difficult to debug/test: [...]

I'm debugging with Editor mode so I can control time and single step through combinators. Also get combinators and space and time to work on the designs for free. And wire shortcuts of course. And I will probably use stack combinator soon. But I agree of course.

[ssilk]

I might have to actually make some text-to-combinators compiler to be able to complete my self-playing and self-expanding factory. I considered doing it in Lua before with Lua-combinator mods but I've started on the path on doing it with combinators, so I guess I'll finish it that way too. I have some minor experiments with the designs of combinators that would be useful for being the target of a compiler.

do I understand it right: you transpile your source (which language?) to Factoriolang (I use this term, like golang for “go language”) by using Factorio?

Making factorio-language something that compiles to combinators means combinators are still a part of Factorio. Otherwise combinators would be completely obsoleted if text-code could run in Factorio vanilla and no-one would use combinators again. And people still get the advantage of having text code. And raw combinators can be used to gain a speed advantage over compiled code by doing parallel computations.

I really like this concept. It would explain also how compilers work and what an executable program is. And many more things.

Yeah readability is really bad. What I'm doing to mitigate this is for my combinator designs to be placed down in a structured way, similar to the ideas of making your code readable with some empty lines, proper indentation and reasonable line lengths etc. Code is readable because we are taught to make it readable, newbie coders make unreadable code even if it is in text.

Well, with Factoriolang the difference is, that it is really, really hard to write readable code. Yesterday for example I learned, that humans can remember only 7 things at once. We can say, their stack is limited to about 7. more or less, depends for example on stress level, my experience says: if we need to remember more than 3 things at once, code will eventually fuck up. A function with more than 3 parameters is something I really try to avoid meanwhile, for example.
Now with Factoriolang this is quite difficult to achieve, you need mods like Circuitissimo to outsource functions, that otherwise block your mind. That helps a bit, but still it’s possible to use hundreds of signals at once (e.g. the roboport output from the logistic network). Even without that then it’s super strange, because there are the signals, which are not only values but also the maximum number of available “variables” on one wire and it’s not very useful to have only symbols as variable names.

But then to fit my designs where I need them I for some cases have to use picker dollies and compress them down to something less readable.
But to make it readable I have a start point, and "all" signals flow in the same direction (except for loops) just like control flow in a program. And "all" combinators on the same distance (along the chosen time axis) from the start of the combinator program have equal amount of combinators before them so they are synchronized tick perfectly. I add deciders (each ~= 0 > each count) or arithmetics (each + 0 = each) to do simple single tick delays to stick to this when necessary. This means I get some kind of indentation and lines similar to text code. It's pretty annoying to only be able to move a single thing with dollies and copy paste loses outside connections, but I at least also reduce my need for moving things around, slightly, if I structure where things belong from the start this way.

But it's still not easy to read or modify, just slightly easier than impossible

100% agreed

After some thinking I need to say, that Factoriolang seems to be a sort of non-blocking language, like JavaScript. You see that for example that you need to use this synchronization to execute the code in an order.
What plays here together is, that functional programming and non-blocking play hand in hand. JavaScript is also quite functional.
So, what I recommend is, that the source language to transpile to Factoriolang should be also a functional language, I think this helps in some ways (not exactly sure how, just thinking ). Also recommend to use circuitissimo mod, because it enables to transpile a function into a circuitissimo-block.

[Qon]

I might have to actually make some text-to-combinators compiler to be able to complete my self-playing and self-expanding factory. I considered doing it in Lua before with Lua-combinator mods but I've started on the path on doing it with combinators, so I guess I'll finish it that way too. I have some minor experiments with the designs of combinators that would be useful for being the target of a compiler.

do I understand it right: you transpile your source (which language?) to Factoriolang (I use this term, like golang for “go language”) by using Factorio?

[...]

After some thinking I need to say, that Factoriolang seems to be a sort of non-blocking language, like JavaScript. You see that for example that you need to use this synchronization to execute the code in an order.
What plays here together is, that functional programming and non-blocking play hand in hand. JavaScript is also quite functional.
So, what I recommend is, that the source language to transpile to Factoriolang should be also a functional language, I think this helps in some ways (not exactly sure how, just thinking ). Also recommend to use circuitissimo mod, because it enables to transpile a function into a circuitissimo-block.

It's not that far along yet that I can promise anything at all. I'm thinking of maybe a subset of Lua. Without tables and "for" and "if" only in some limited form. There's no way to do dynamic memory allocation or garbage collection and many other high level language features. Realistically it would be more like an assembly language with Lua syntax. But Lua has goto so maybe I could make the code work "the same" if used in a Lua combinator?

The compiler would have to be a mod so you can compile it in game and get a blueprint. Well it could be an external tool but then there's some integrations that are not possible.

Haven't figured out how functional (with dynamic recursion depth) would fit while maintaining high speed in combinators. With known depth at compile time the structure could be similar to how my Circle Generator is designed.

Now with Factoriolang this is quite difficult to achieve, you need mods like Circuitissimo to outsource functions, that otherwise block your mind. That helps a bit, but still it’s possible to use hundreds of signals at once (e.g. the roboport output from the logistic network). Even without that then it’s super strange, because there are the signals, which are not only values but also the maximum number of available “variables” on one wire and it’s not very useful to have only symbols as variable names.

Using the Circle Generator as an example again, there are "clear" (separated by some space) repeated identical structures which correspond to different "function calls" of the same function. So I don't really need Circuitissimo to have functions that I can re-use. All Circuitissimo gives me is less space requirements. But even that is not really true since Circuitissimo combinators have a fairly small and strictly limited inside without the possibility of using circuitissimo combinators "recursively" within other circuitissimo combinators. And the deal breaker is that they are not blueprintable (which might be a bug). You can blueprint the inside (and even that has bugs I think), but using many circuitissimo combinators is much harder than regular combinators. Another limitation is the limited IO ports on the circuitissimo combinators, 1 red and 1 green on each side. The last one can be worked around by simply not using circuitissimo combinators for your entire circuit that has many more IO ports, but just use that mod it for parts of a design. But the other parts are deal breakers.

Schall Circuit Scaling does something completely different and yet still the same thing. Circuitissimo also really just makes scaled down combinators. Schall's mod does the same without any of the bugs and limitations. You have to do the "functional separation" yourself though by leaving some space around reusable parts, but that is doable since leaving space around for-purpose designs is a core Factorio skill anyways and all space used is shrinked down by the mod so it doesn't cost you much when deployed.

[Eketek]

If you want something which compiles to an arrangement of combinators, then Verilog would be a reasonable starting point (because combinators are much more like digital circuits than like conventional computer software).

[farcast]

This seems like the best place to post this now so:

I've been working on making a language for combinators based on c++. This gives the advantage of all the quality of life tools for c++ automatically working with this language that I've been calling comb script. The key detail that makes this possible is that this language describes the steps to build a circuit, not how to simulate one. To use this language is to write a set of instructions a person could follow to construct the original circuit minus combinator positions. Since this language is just stripped down c++, I'll be assuming you know the basics of that while reading this.

To start, this language introduces 5 types: "rwire", "gwire", "pair", "signal", "comb".


"rwire" & "gwire" represent red wire and green wire respectively. A variable with either type is a label for a specific network in the circuit with the respective color.


"pair" is a struct with a red wire member "r" and a green wire member "g". It may or may not just be the pair in std::pair. A "pair" is created when attempting to connect red & green wires together.

"comb" is a struct with "pair" members "i" and "o". A comb is used to label the inputs and outputs of a combinator, or a group of combinators with shared i/o.

"signal" is an enumerator with every signal in the game, excluding wild cards. Spaces and hyphens in the names the game uses would need to be replaced with underscores.

Additionally, there are three global constants "each", "every", & "any" representing the three wildcards in the game.


Operations:

There are three main c++ operations that can be used with these types: "+", "()", "=".

"+" & "()" are for connecting wires together. These cannot be used with "signal".

For "+" & "()":

• If both operands are wires with the same color: The return type will be a wire with the same color, and both operands become retroactively interchangable until either is assigned "=" to a different network.
• If both operands are wires with different colors: The return type will be a "pair" with its members initiated with the operands of the respective color.
• If both operands are "pair"s: The return type will be a "pair", and members will be connected red to red, green to green.
• If both operands are "comb"s: The return type will be a "comb", and members will be connected input to input, output to output.
• If one operand is a wire and the other is a "pair": The return type will be a "pair"; the wire will be cast to a "pair" where the opposite colored member is 0 initiated, then connected to the other "pair".
• If one operand is a wire or "pair" and the other is a "comb": The return type will be a "comb"; A wire will be cast to a "pair", and the "pair" will be connected to the "i" or "o" member of the "comb" depending on if the "comb" is the left side or right side operand respectively.

"=" will make a variable represent a different network(s) without connecting to the original, future instances of the left side variable will not connect to past instances.

• a wire cannot be assigned to a wire with the opposite color.
• Wires will be cast to "pair", but "pair"s will not be cast to wires.
• Neither wires nor "pair"s can be cast to or from "comb"s.
• For "signal"s, this is just normal c++ assignment.

Combinators:

Combinators are represented by a combinator expression, which looks like this:

"(setting = setting operator setting)"

where "setting" can be an integer literal or a "signal", or the wildcards "each", "every", or "any". Only combinations that are possible with combinators can be used. Whether it's a decider or arithmetic combinator is determined by the operator used.

The expression returns a "comb", and should pretty much always be in parenthesis to prevent operator precedence from interfering.

For decider combinators, using += instead of = will set it to output 1 instead of input count.

In factorio, ^ is exponentiation and bitwise XOR, while c++ lacks an exponentiation operator and uses ^ for bitwise XOR. For this language, ^ will be bitwise XOR and ^= will be exponentiation.

A new combinator is created whenever a combinator expression is executed, so connecting to the same combinator in different places has to be done through wire, "pair", or "comb" variables.



Constant combinators:

Constant combinators are created by initializing a "pair" or wire with an initializer list of integers being assigned to "signal"s, like so:

Code: Select all

const signal control = signal_red;
pair conCombinator = {iron_plate = 1, copper_plate = 5, signal_green = 1,  control = -5};

A new constant combinator is created for every 20 constants in the initializer list.

Functions:

Functions would work just as in c++, with a return type, parameter list, and a block of statements. Useful for giving a name to a group of combinators.


Here's an example of the comb script for a circuit I made. I use it in my train stations to ensure only one station accesses the global network at a time. When a station needs to use the global network, it activates this circuit which does the following:

Hold a 1 to a global lock signal, which prevents other such circuits from activating.
Output the station's unique ID to the global network. So all circuits activated at the same time have their IDs summed up.
Output a 1 to a global count signal. This gives the total number of activated circuits.
If the ID of the station is greater than the average of the IDs, stop outputting the ID and to global count.
If this station's ID is the only one left, output a user definable constant value until the circuit is disabled.
Add 1 to the station ID and send it to the next adjacent station.

selector comb script

Code: Select all

rwire selector(gwire input, rwire output, rwire global, rwire incrementID = 0,
               const signal isLocked         = signal_1, 
               const signal id               = signal_2, 
               const signal countContesting  = signal_3, 
               const signal disable          = signal_red
               const signal average          = signal_m)
{
   
   //The first two constants must have the same integer value, which is the output value.
   gwire control = {countContesting = -131072, disable = -131072, disable = -2147483647};
   
   rwire setID = {id = 0, disable = 2147483647, countContesting = -2147483648, isLocked = 1};
   setID + incrementID;
   
   gwire conInput = {isLocked = -2, countContesting = -1};
   conInput + input;
   
   gwire lock;

   (global + lock)
   +
   (isLocked+= isLocked == -3)
   (global + control)
   .o
   
   +
   (isLocked+= isLocked == 0)
   (setID + lock)
   .o;
   
   (setID + lock)
   +
   control
   (disable= every >= id)
   .i
   
   +
   global
   (id= every >= id)
   .i
   
   +
   global
   (countContesting+= every >= id)
   .i
   
   +
   (average= id / countContesting)
   (global)
   .o.r;
   
   (setID + control)
   (every= disable == 0)
   (input);
   
   output
   (disable= disable == countContesting)
   (global + control);
   
   // alternative i/o configuration where the circuit disables itself and pulses the output for 1 tick
   /*
   (setID + control)
   (every= disable == 0)
   (output + input);
   
   (output + control)
   (disable= disable == countContesting)
   (global + control);
   */
   return (id= id + 1)(setID).o.r;
}

I might have failed to make it readable, and it's quite tedious to convert a circuit into comb script manually, but if it makes editing combinators even a little bit easier, I'd consider it a success.

I think the features I listed above would be good enough for most uses. In the context of this language, the other features of c++ (pointers, if statements, loops, etc.) would just be for efficiently defining ever more complex patterns. Of those features, I suspect the most helpful ones would be loops, integer const expressions, and arrays. I suppose how much c++ should be allowed in this language depends on how much of a c++ compiler I or someone else would be willing to make in lua, but I also don't want someone to need to learn all of c++ just to start using this language.

I tried to follow the rules of c++ as strictly as I could to make it possible to write classes that would allow comb script to directly compile as actual c++ code.

I'm no expert by any means, which is why I just copied the syntax of c++ entirely. What do you think, is it usable? Am I taking "object oriented programming" too literally? I'd like to know if there's a way to make this post in general more readable, or the language more useful. Maybe a different programming language would be better for what I'm trying to do.

Here's the blueprint for the circuit in the example:

0eNrlWt1umzAUfpXKtyNdbAOGSLvYVGmq1K0329VUIZK4iaUEImO6RRUPsAfZi+1JZkibEGIDBtJO200k/o6Pz/f5nPPZeQTTVUo3nEUCTB4Bm8VRAibfHkHCFlG4yu+J7YaCCWCCroEFonCdX83pjM0pH83i9ZRFoYg5yCzAojn9ASYwsxoN5AOJMBJqCyi7swCNBBOM7vwpLrZBlK6nlMsh9obWdM7S9Yiu6ExwNhtt4hWVw2ziRH4cR7kD0uAIe+jSscAWTFwMLx05lPQgkt+wYsaPAOY/nM7LozF5Zcs3GZ+lTBSX0rNMfhxRtlhO45Tn3kH/Lp9xxUVUO1eFh8SreDhnfOfgzos4EjxeBVO6DB+YNCG/u2crQbkGsQfGRSrv7P3YvTHCoJh9mkM+ghiOCTpA5ymx05nK41VjzO9jDEGb2B52bXKgxVhGX43cglMaVbFzj7GDOXYKpLAxUuRlkIJH8ega12O8OwfTaxdMez98yJlYrqmQi7I+nKWlaWfq8B1sBfLxnO39vWc8EUHrWKA8FgnNbQTPYBfZJN5QHu68Am/kZ3EqNqmZ4ax9UtkhWLrxBAbSva8JtlOXkFWRHu8jjVvR9slsv6DTB8q3YsmiRSn6ZpDJaW1CXkxrAn7//NUBoX162WyDYjUE9zxeByySVsBE8JQaAEiqi+EYTohOqoalXlXktLw80aBPRnMNeVEqPTg7IxOeEtrzuhvhCrLvOuAKa1C9D1eJCaxuFY0KrHZbWKtfOvWGPS0Lmp2sco/0oJ6KS8SUS/6rcGn8l1HJqUfJ64xShZLOaUZoTZ3Wo8J6Olcfu+2Y5Zkyi7xG9drXjSGZdlwSO9QkJWq4goNfS4YTjHVkaEg4sGVR8o01G3EPgJtoNjhucFFPfK9hrlCl/4hK/8GxsaywK9MtMdwdUFbclgTBuEG162x8VdpARja+KG1grSxRIO1ruAZhj+Cjcwb/eoDgfx4g+Mdq+1gWyoskyCe+K3oGGUiLB+ogCw9ipZ3GPodINFPZZRX5tkNZ+GSmIh2TtrGhZsOG54VCVUKLzffi4EHwG+V1os3b+SNFYrbUe3PQ7i6QnOyfl8p4wD5Y0aDqIOzTyjbRGXVsWqDTXf78B0xBw22pnO6Z1Itv2FW8KAzVbb0hM2s6sQPd7mrHeXG106n69VZFg27RnQJjtS0mRtsx2paH9NE7ZnURN2a3ynNPn4WxqpBiS11HvR5ttnPONvvjAG32zQBt9q1G45jY+KC0YRvZeK+04QwQD9fIBjQ+jNL0geo15/c5FyY9zoWV+wIWxMqTYeOdgZIUcs954IgGWDXXAzD+agDGHwtcxWmy4Vk3Vh5Oe11PZaFWfffgYOMplFw1ubrP/4oxKf31wwKrcEql2+Am/k4TcXF9dZEUS6fgo2w1k4JryJPz9hHBPoFEVorsDy9ejVM=

Copy blueprint

[Qon]

If you want something which compiles to an arrangement of combinators, then Verilog would be a reasonable starting point (because combinators are much more like digital circuits than like conventional computer software).

I haven't used Verilog, but a Hardware Descriptor Language seems like a good fit for how to describe combinator circuits. Though the language I was thinking of was higher level, imperative or assembly like. The point is to be able to write algorithms and get blueprints out instead of designing circuits which requires you to still know how to use circuits well and implement all the things (like basic memory and control flow) for every circuit that needs it. But a HDL could be a compilation target for the language I'm thinking of.

But to get it working (and make sure the blueprint generated is laid out in a somewhat readable fashion) I'm currently skipping this step and I'm designing a blueprint book that can work as a framework for my circuits where each instruction is a blueprint that can be placed down to simply connect it to a program. This means I can get something usable even without any compiler at all also. It might be a bit finicky but scrolling through a book to select the right instruction and doing some light modifications for constants could be much quicker to write programs in than just raw combinators at least. But at some point switching to a HDL target would make sense.

RedGate -- About a non-practical HDL I made

I have made a HDL (works but I want to add some more features before it's considered complete) with a compiler to a data structure that can be simulated. I want to add a factorio combinator targeting compiler for it some day. The language is called RedGate (after red stone in MineCraft) and Red wires in Factorio. It's supposed to be minimalistic and simple and to be able to be compiled to anything that can be used to make simple gates. It isn't made for Factorio specifically so it isn't going to be used for practical combinator setups since it wont support multiple signal types or multiple bits. It just assumes that there's some basic minimal set of gates and wires that carry single bits. But that means Each ^ -1 combs with Each | combs could be used to run the same RedGate ciruit in parallel on each signal and each bit on every signal. Or just Each ~= 0 combs with implicit or by wire combination could be the target for 1 simulation per signal in parallel. Though RedGate has a concept of buses of multiple bits of signals which a compiler could take advantage of it it wanted to send a bus of signals on different bits of some signal or on different signals or on both.

Targeting an intermediate HDL specific for Factorio would make the compilation fairly trivial and let that languages compiler do the heavy lifting of positioning the combinators and making sure wires can reach the targets.

I've been working on making a language for combinators based on c++.

Awesome! Do you have code to actually execute your compilation? Release when? Would be an awesome target for RedGate already.

I think having a compiler written in Lua would be an advantage for anything specific for Factorio though, so it can be integrated in any mod that needs it.

Edit: I just read through it, need more time for a more in-depth answer.

[Hannu]

Isn't combinators already programming in factorio? Why add another language?

I think combinators are Turing complete. But your picture tells why we (read: I and couple other HC nerds) would like to have text based scripts to control things. Most non-trivial tasks need huge contraption of combinators. It takes much room and makes factories ugly. It is very hard to build and debug compared with simple text. At least I do not bother to do nothing but very trivial tricks, like SR-latches to control pumps or simple dividers to control chest loading on stations.

It may be too small user base to be economically feasible to implement any programmable logic. And it is not needed in Factorio. It would just be very interesting add on to get factories and logistics more realistic like and interesting (from engineering point of view).

[Qon]

I think combinators are Turing complete. But your picture tells why we (read: I and couple other HC nerds) would like to have text based scripts to control things.

I would respond but I already have, DRY.

[farcast]

Awesome! Do you have code to actually execute your compilation? Release when?

The idea is that compiling comb script would result in a program that, when executed, generates a set of combinators in some global container that can then be simulated and manipulated by the rest of the program. Meaning comb script is only supposed to run exactly once. It's a bit silly to be expected to recompile some circuit debugging program for every different circuit, so getting comb script to compile would just be for merit.

I don't have any code yet, I'm gonna start by making a mod that lets you select a bunch of combinators and it spits out some basic comb script, then using that to organize my circuits to see if there are any changes I want to make to the language. I'll be learning lua along the way, and I'm slow, so I have no idea when a public release would be.

A mod that turns comb script into combinators wouldn't just need to compile, but also execute the comb script, which is why I don't really intend to allow all of c++ in the language. Basically, comb script is just a way to give combinators, signals, and wires descriptive names.