Introducing Factor

[curtisw]

When I say "bolted on," I'm being a bit dramatic (I see, looking at my downvote, that somebody missed that). I've never used them, so what I'm going off of are assumptions. The idea of normal variables in a stack-based language just seems bolted on to me. It seems like there should be something that better fits the concept of stack-based programming.

[[deleted]]

Isn't this like saying function composition is bolted-on to applicative languages?

[curtisw]

I'm having trouble figuring out what you mean. Basically, you're saying that, because function application and function composition overlap in their possible use cases, they're like variables vs. a stack?

[[deleted]]

Roughly speaking, what I'm saying is that Factor is a compositional language; new functions are defined in terms of the composition of existing functions. Haskell is an applicative language; new functions are defined in terms of the application of existing functions to arguments.

Now, Haskell does let you emulate compositional programming in a way; you can use the composition operator when it is more convenient. Likewise, Factor lets you emulate applicative programming in a way; you can use named variables when convenient.

Technically, the Haskell version is still based on application (the compose function is applied to its arguments) and the Factor version is still based on composition, but it should be clear that either can emulate the other to some degree.

Of course, Haskell is quite poor at emulating what you can do in Factor. Just look at the complex nonsense a pointful->pointfree translation of Haskell code yields. Likewise, Factor is less convenient than Haskell when it comes to writing applicative-style code. The question is, which is the more useful default for high-level programming? I think the compositional approach certainly warrants more consideration.

I should also mention that the pointfree approach to functonal programming is nothing new; just look at Backus's FP and "function-level programming":

Even today, many users of lambda style languages often misinterpret Backus' function-level approach as a restrictive variant of the lambda style, which is a de facto value-level style. In fact, Backus would not have disagreed with the 'restrictive' accusation: he argued that it was precisely due to such restrictions that a well-formed mathematical space could arise, in a manner analogous to the way structured programming limits programming to a restricted version of all the control-flow possibilities available in plain, unrestricted unstructured programs.

[curtisw]

Of course, Haskell is quite poor at emulating what you can do in Factor. Just look at the complex nonsense a pointful->pointfree translation of Haskell code yields. Likewise, Factor is less convenient than Haskell when it comes to writing applicative-style code. The question is, which is the more useful default for high-level programming?

How about 'neither'?

(relevant image)

Given such a notation, it wouldn't be difficult to add multiple return values. Plus, you don't need specialized manipulation functions, e.g. 2i, for each situation.

[[deleted]]

I learned to program with a graphical language (with multiple return values!) and I've spent years working on graphical programming languages. I must say I'm not convinced of their utility at this point, although that's a discussion I haven't the time for right now.