@Leo This is very much like (or exactly?) what Jelly does, and I think it's a good idea.

First off, name idea: Higher Order Golf, or HOG for short.

@MartinEnder And this is exactly what I mean with more combinators. I think we should try to encourage the pointfree/tacit style as much as possible. In Haskell, if you want to compute, say, the square root of the maximum of two numbers, you can't do sqrt . max because . doesn't work like that. So you do (sqrt .) . max, which is clunky and requires parentheses. Our language would have a combinator for this case and others, so you could simply do sqrt .: max (with 1-byte tokens of course).

My 2 cents: I don't like Functiogolf as a name :p

Even pattern matching could be done with combinators. For lists, we could have a function matchList :: b -> (a -> [a] -> b) -> [a] -> b such that f [] = foo; f (x:xs) = bar would be equivalent to f = matchList foo (\x xs -> bar).

Inline recursion could be handled with fix, possibly integrated into a special kind of lambda and/or combinators.

By "increased laziness" I mostly mean lazy integers with support for arithmetic, so you can do stuff like 2 * length x > length y and have it work when x is an infinite list. Another idea is that lists should have implicitly stored properties like "increasing", "cyclic", "finite" etc that builtins like filter and elem can take advantage of, so infinite lists are even more handy.

And for the syntax I feel like we have to go for infix expressions, with function application and/or composition as an "invisible" operator like in Haskell. Otherwise we'd need special syntax for higher order functions, which feels morally wrong. ;) Unless of course you have some ideas for that.

I don't like this name either, it was just a placeholder. HOG sounds nice, suggestions are welcome :)

I like the idea of using combinators for pattern matching and doing recursion with fix. Lazy arithmetic seems wonderful, but I really wouldn't know how to do it (though I think brachylog has it, so it should be doable)

I'm not sure I get the implications of infix vs prefix notation, why would we need special syntax for higher order functions with the latter and not with the first?

I think prefix syntax has even greater problems for us. Pyth has a prefix syntax where a function can have an arbitrary fixed arity. So you do +TQ to get the sum of T and Q, since + has arity 2. We'd like every function to have arity 1. What would the syntax for adding two things be?

uh... +TQ ?

I'm sure I'm being dumb, but I can't see the problem

+ gets applied to T, returning a function which is then applied to Q

Okay, then concatenation is essentially an invisible left-associative infix operator for function application. :) It's parsed as (+T)Q

Yes, that's how it's done in haskell, I think

Now we'd like to add three things. Pyth does +K+TQ. We'll do +K(+TQ). Or we'll have an infix operator like $ in Haskell, and we can do +K$+TQ.

And how would you do that with infix notation?

That is the infix notation.

$ is infix, but + is still prefix, right? I thought you meant everything should have infix notation :)

Oh no. :) I meant that we'd have basically Haskell's expression syntax, where function application is an invisible infix operation. Most functions will be prefix-style. There should probably be a short way to convert prefix functions to infix and back, like `elem` and (+) in Haskell.

Regarding overloading, I think that it would be possible to abuse typeclasses in order to give the same function different implementations depending on the type of its argument... We need to make sure that types are always decidable, though

I did some research on that some time ago, and decided that it's probably easier to roll an implementation of the Hindley-Milner type checker and add non-determinism. The type system and its extensions seem too conservative for this purpose.

We would basically run our nondeterministic type checker, have it produce some concrete types, and produce Haskell code that's guaranteed to be correctly typed.