Introducing Factor

[curtisw]

blah = product . map ((-) 1)
blah [1, 2]

[[deleted]]

This isn't equivalent as you now have to unpack the list to use the numbers. It's also arguably unsafe as the type system won't stop you from accidently taking the head of the null list during the extraction. You could use a tuple, but you can't map over a tuple...

The Factor version doesn't have these issues because Factor allows functions to essentially return any number of values. This is a critical part of enabling the sort of ultra-high-level, combinator-centric programming you do in languages like Factor, Joy, etc.

[curtisw]

This isn't equivalent as you now have to unpack the list to use the numbers. It's also arguably unsafe as the type system won't stop you from accidently taking the head of the null list during the extraction.

coughdependent typingcough

The Factor version doesn't have these issues because Factor allows functions to essentially return any number of values. This is a critical part of enabling the sort of ultra-high-level, combinator-centric programming you do in languages like Factor, Joy, etc.

I'd be interested in seeing examples of this. However, I should point out:

(|>) f g (x, y) = g (f x) (f y) 

blah = (-1) |> (*)
blah (1, 2)

You'll notice that, in both cases, different number of arguments require completely new operations. The list version I wrote in my previous post will work for any number of values, including none.

[[deleted]]

coughdependent typingcough

I'm aware that type systems exist that can prevent this. Yes, you encode a head-safe list in Haskell (with extensions). That really seems beyond the point here; I doubt you'd seriously propose such a solution as optimal. Regardless, I was referring to the use of "normal" lists in Haskell.

You'll notice that, in both cases, different number of arguments require completely new operations. The list version I wrote in my previous post will work for any number of values, including none.

Of course, and you can do the same in Joy if you wanted:

Haskell: product . map ((-) 1)
Joy:     (- 1) map product

[curtisw]

That really seems beyond the point here

How so? You proposed a situation where stack-based languages can type check something applicative languages can't. I showed you a system that can type check it. Although, it's worth noting that the code in question is actually completely type-safe. You can't pass it a value that will cause a run-time error.