[crimsonalucard5]

>Filters tend to run concurrently and, importantly, do not return their results, they pass them on to the next filter in the pipeline.

Filters are functions. They are one and the same. For unix it's a function that takes in a string and outputs a string. The unix world reduces everything into a singular type. You will note that unix "filters" cannot compose with functions of "other" types either. If unix included types like arrays or ints in stdout you would have the same typing problems as you have with functions.

In the unix world all your types are strings so things seem simpler, but in reality your little unix programs need to deserialize the strings into proper types in order to do anything meaningful. You could achieve the same thing if you used functions that returned strings all the time then did internal deserialization but that's not really a solution.

I do get your point about arity and parameter types. You're referring to the fact that not all functions can compose UNLESS they have compatible types and an arity of 1 in the parameters and an arity of 1 in the return value (Golang for example can have arity > 1 in the return value).

However this arity issue doesn't really exist. A function with Arity of two is isomorphic to a function of arity 1 that takes in a 2-tuple as input.

  f(a, b) -> c
  f'(Tuple[a, b]) -> c

  g(d) -> Tuple[a, b]

Both f' and f are equivalent in theory. Plus you can compose g with f'.

The only compatibility problems with composition among functions in the end is just types (not arity) but this problem still exists even in the unix world... it's just hidden from you because you don't actually watch the programs perform deserialization and serialization.

[mpweiher]

> Filters are functions

As I explained before: no they are not.

They have some similarities, but they also have the important differences I outlined above.

The single type is also a restriction relative to the functional model, and crucial to (syntactic) composability.

> If unix included types like arrays or ints in stdout ...

But it doesn't...

> you would have the same typing problems as you have with functions.

...so you don't.

> Both f' and f are equivalent in theory.

But they are not actually equal (never mind the same), at least not in typed FP, and most FP is typed.

> it's just hidden from you

Exactly. It is hidden in Unix and not in FP. That's a difference.

> You could achieve the same thing if you used functions that returned strings

Two points:

(1) you write that you "could" achieve the same thing. Meaning that, once again, they actually are not the same. Otherwise the "could" wouldn't make sense (and it does).

(2) returning strings would not be the same at all, because filters do not "return" their results. They return status codes. The result is not returned, it is passed directly to the next filter, continuously.

So: it is good to recognize that 'X is similar to Y', but that doesn't imply that 'X is just Y'.

[crimsonalucard5]

>Functions run to completion and return their result. Filters tend to run concurrently and, importantly, do not return their results, they pass them on to the next filter in the pipeline.

Let me address this point so it is more clear. Functions by definition do not need to "run" at all. The underlying implementation of a programming language may "run" a function lazily, eagerly or concurrently but that is not what the Definition of a function is describing.

A function is simply a relation between two sets, one set called a codomain, another set called a domain is deterministic. That is all.

So within unix piping the domain is stdin, the codomain is stdout, the function is the unix program. This paradigm fits the definition of a function and as long as that "function" remains deterministic and compose-able it fits within the paradigm of functional programming BY definition. there is no need to discuss "similarities" here, because it fits the definition therefore it is functional programming. Of course we can get pedantic about certain non-functional use cases but in basically you are fully aware of the generality I'm describing. No point in getting pedantic.

Also keep in mind when you "execute" these functions it does not matter HOW these functions are executing whether concurrently, lazily or eagerly. The only important thing is the relation between the domain and codomain. That is all.

>The single type is also a restriction relative to the functional model, and crucial to (syntactic) composability.

Every unix program must internally deserialize this string type and serialize it again for output. The typing must be handled regardless. It seems like you don't need to deal with it but it's dealt with regardless. You also get inevitable deserialization problems of incorrect types. You do not escape typing in the unix world.

>But they are not actually equal (never mind the same), at least not in typed FP, and most FP is typed.

A relation that takes a string from a domain and returns a string that is from a codomain is a function that is part of functional programming. This is EXACTLY what a unix program does when relating stdin to stdout and therefore it IS a function and it is FP By definition.

You can look at it from another direction. A function that returns an Array does not fit the definition of what a unix program should output to stdout therefore a function IS NOT a unix program. BUT a unix program IS a function.

Formally unix programs are just the set of all functions where the domain and codomains are strings.

>>Both f' and f are equivalent in theory. >But they are not actually equal (never mind the same), at least not in typed FP, and most FP is typed.

The mathematical term is "isomorphic" meaning you get the EXACT same properties going one way vs. the other way. It's the syntactic sugar that prevents composition. Using multi-arity functions and single arity functions with tuples only involves two additional parenthesis:

   f(a, b)
   f'((a, b))

It's just syntactic sugar that causes a difference to occur.

Arity and tuple types are well described to be isomorphic in category theory. I'm not making this up.

One way to think about an isomorphism is that if two things are isomorphic then they are just different perspectives of the exact same thing. Any differences are superficial or illusory.

>Exactly. It is hidden in Unix and not in FP. That's a difference.

Exactly what? If you're not dealing with the type conversions someone else has too. Just because it's hidden from you doesn't mean it doesn't need to be dealt with. Someone has to serialize things and deserialize it. Even from the command line level you cannot escape types. Let's say you have a unix program that can only take numerical strings from stdin. Let's say you pipe english letters to it... if you do then you will have still triggered a sort of type error despite everything being typed as strings in unix. It's just not handled explicitly as a system error.

You cannot escape typing even in the unix world because it is in the end just FP.

>So: it is good to recognize that 'X is similar to Y', but that doesn't imply that 'X is just Y'.

Except we're not talking about similarity. Like I said above X is just Y BY definition.

[mpweiher]

You keep claiming things are the same and then describing differences.

Not sure what else I can do to make you understand this.

As such, I am bowing out as I can only repeat what I’ve written.

[crimsonalucard5]

No I did not do what you wrote.

Here's what I did: I defined what a function is, then I described how a unix program fits the definition of what a function is...

In short a unix program with stdin as domain and stdout as a codomain is a function but a function is not necessarily a unix program.

I think what's actually going on is you didn't read what I wrote very carefully. You sort of just skimmed over it. I can't blame you, it is rather long and detailed...

But if you want to have a meaningful discussion you need to read it and ask questions about things you don't understand.

[mpweiher]

As I wrote before:

> > Unix piping is basically functional programming.

> Only in the same sense that all computing is Turing Machines or NAND gates.

Yes, you can map and analogize long enough until you reach a point where you find what you perceive to be equivalences.

However, what you've done at that point is rediscover that all these mechanisms are computational and thus at some level equivalent and transformable into each other, just like yoo can implement all of this with just NAND gates.

You have not shown what you claim. ¯\_(ツ)_/¯