[RangerScience]

Popped in here to say that AFAIK/IMO, most of the things people treat as "state" is actually "data".

And then I started thinking myself in circles around "okay, so what is state?". Rather than /keep/ thinking myself in circles, I'll ask:

What do y'all think "state" is?

[azornathogron]

State is data that you use in control flow decisions.

(This is a 5-second reaction, not a deeply considered opinion, don't take it too seriously)

[RangerScience]

I like it! I don't know if I agree, but, the category of "data used in control flow" is a good one.

I think... maybe this definition needs a narrower category of control flow? Like, technically, if you're converting 24-hour time to 12-hour AM/PM time, you have control flow (if > 12 hours). IMO that seems like it shouldn't be state. But, "we've delivered this message, so don't try to deliver it again" definitely involves control flow and definitely feels like state. Something like "this list is sorted" is in-between; it's re-computable (easily, depending on list size), if it's not done you want to do it, but after that it doesn't affect control flow.

Maybe the difference is "control flow that modifies other data"?

[pull_my_finger]

> (This is a 5-second reaction, not a deeply considered opinion, don't take it too seriously)

If you have to put a disclaimer that basically invalidates your statement, why make the statement at all?

[azornathogron]

It doesn't invalidate it, it offers context.

[gavinhoward]

This is the correct formulation.

I also have a blog post coming out tomorrow with a bit of justification for this.

[btschaegg]

Okay, I'll have a go:

State is the data required to continue the operation of a program. That's always the case (also in non-FP contexts), but state is often smeared all over a program as only loosely and implicitly connected pieces whereas FP is mainly concerned with how to manage state (and thus also with how to compose such pieces of state into a greater whole so it's easier to manage).

Edit: Note that there is also "data you don't need for continuing the operation of the program", which we could categorize as "input", "output" and "wasted memory/storage/cpu cycles". The last of the three can obviously still be crucial for other reasons than program execution (e.g. debugging), which makes the line between output and waste blurry.

[RangerScience]

I like it! I don't know if I agree, but, the category of "data required to continue the operation of the program" is a pretty excellent category, thank you for pointing it out!

Maybe... As you say, state is the information required for continued execution. Which would make "data" the information that's carried through the program. Like - parts of an HTTP request are "state" because they're what you use to route the packet through the internet. The other parts are "data", because all the intermediate programs don't use it during their operation; it's just passed through.

[Jensson]

If you can refactor it then it isn't data, just programming bookkeeping. Some programming bookkeeping is tied to data, but a lot of it isn't.

For example, you can often add or remove state of things without changing how the program works.