Input/Output format, scoring, and the status of The Powder Toy

Question

The Powder Toy is a falling-sand game with enough functionality to be classified as a interesting take on fungeoids.

However, there are a few problems with this.

Input/Output

Programs (simulations) written (built) in The Powder Toy (TPT) don't have any built-in IO functionality, but it can be done in many non-canonical ways. Should you write output to the screen, should you output it as an electric (SPRK particle) signal on a wire, or should you output it as data on FILT?

There's a similar problem for input. How should it be taken? From where? Can programs take input at arbitrary points, or does it have to be given at a specific position?

Scoring

TPT is also a bit of a challenge to score fairly. Scoring a program based on the size of the save file may be unfair, because they contain large amounts of "fluff" in the form of metadata (such as the save name, game version, and the names of various fields). The header itself requires about 150 bytes of overhead, and a save containing 8-9 particles has a full weight of nearly a kilobyte.

On the other hand, scoring simulations based on the number of particles may also be unfair because particles can be used to store data.

Status as a Programming Language

This is a simple question: Is TPT actually a programming language? TPT can be classified as a fungeoid, but is it actually a fungeoid? Is it even a language?

Answer 1

Byte count should be based on the file

Regardless of what "header" or "boilerplate" is included, you need to be able to save your source code to a file in some manner for it to qualify, and your score in bytes is the size of that source code in bytes. If you find or make some alternative way to store your TPT programs as a file, and provide an interpreter which can read those files and run the program they represent, then that file format is an option for scoring. A similar situation happened with Minecraft, and the consensus was that there had to be an actual file to use as the byte count, but scores were later greatly improved when a more efficient way of storing structures as files was added. Fortunately you mostly compete within a language rather than between languages because the numbers just differ so much, so as long as the file size correlates reasonably well with program complexity (so golfing remains a programming challenge rather than just an optimize stuff for the file format challenge) it won't really be a problem in my mind. If the file size does not correlate well with complexity... sorry, but you still need to be able to store your source code in a file.

Output

All of the output formats you listed seem appropriate, though I can't evaluate them for sure without more information. As long as you can explain how someone runs the program and how they obtain the output it's probably fine and in some narrow situations it could even be legitimate to use multiple output types in a single answer

Input

For languages that don't accept a standardized or simple Input mechanism, deciding how input is obtained is dependent on relatively deep knowledge of that specific language that I just don't have. In general though, a good input method should be easy to adapt to any challenge. As an example, a language with memory represented as an infinite list of Stacks and no input functionality would most likely take input by assuming the first stack starts populated with the entire input. An uncommon alternative might be that stacks starting from the first and extending to the right each have exactly one item of the input. It would not be allowed to determine for each challenge that it wants, say, "the first input stored in the third stack, the second and third both on the seventh stack, and the fourth input stored as a negative value underneath three 0s in the eleventh stack" and just have input data always prepopulated wherever is convenient.

Is it a language?

If TPT can truly be used to construct functional computers as you claim, then it almost certainly is enough of a programming language for us. The requirements are not very strict.

Suggestion

Try posting an answer to one of the basic challenges like Add two numbers or "Hello, World!" and we can give more definitive comments. I'd recommend Add two numbers so we can critique input methods as well. As long as you're reasonably responsive to comments it shouldn't be deleted and can serve as valuable precedent for future decisions.

Answer 2

We really only need a couple of things to make anything a language:

1. A language must be able to input and then execute source code. Input means something like "load a file" or "paste in some text". It does not mean "click in these 20 spots". We are inputting bytes.
2. We score the entire source code by measuring its bytes.

What we don't do, is define input/output. We like to be very flexible in this manner, and trying to nail down input/output for a language often doesn't work well.

The general rule of thumb is that we try to represent the desired input/output as closely as we can in the given language. For example, if you needed to input 2 integers, I'd personally simply represent each integer by a set of 8 locations (e.g. 8-bit integers, with a piece of sand representing a bit). Output is similar. We simply require that you are consistent (within a post) (you can't have half of your bits be represented by "water" and another half as "oil")

If, after submissions have been posted, it turns out that input/output representation isn't commonly agreed upon, then we can hash out the details on Meta (and the discussion will be more productive, as we will have concrete examples)

Answer 3

Scoring

A stamp is similar to a function and a structure block from minecraft (which is an acceptable way of counting bytes in Minecraft) and can be pasted on the screen.

It is stored locally as files and hence, we may output its byte count instead of an entire save which may have many useless information irrelevant to the problem.

Answer 4

This is my own response to the question, to cover all the bases.

First off, TPT is, truly, just a fungeoid. That's really what it should be classified as, because of two things: One, TPT is provably a Finite State Machine, and two, functional computers can be built in the game.

On scoring TPT, I believe that it should be scored based on the particle count of the save. This probably isn't the best way, but the best way is likely many times more complicated, and I won't try and cover that here.

I/O should be pretty simple, input anywhere, output anywhere. Of any type, essentially allowing the save's designer to choose their I/O format.