Can you expand on that? How does no parens make it harder to pass around first class functions? In Gluon (and in Haskell, Purecsript, Idris, etc), you just pass around the function name. If you have "inc x = 1 + x" and you want to pass that to map, you just pass it by name: "map inc [1, 2, 3]"
What could be simpler?
It's certainly ambiguous to outsiders, which is kind of the point of the discussion. Simpler would be something like Python: map(inc, [1, 2, 3]). No ambiguity.
So `map inc [1,2,3]` is the same as `(map inc) [1,2,3]`.
This is consistent with the fact that -> is right associative.
So in Haskell, we usually say
map :: (a -> b) -> [a] -> [b]
Which is usually interpreted as 'If you give me a function which can turn a's into b's, and then you give me a list of a's, I can give you a list of b's.'
But it is exactly equivalent if we write the type of map like this:
map :: (a -> b) -> ([a] -> [b])
Which I like to read as 'If you give me a function which can turn a's into b's, I can give you a function which turns a list of a's into a list of b's.
It's certainly the case that ML-style languages have a syntax that can be unfamiliar to outsiders, but I would disagree that the syntax is ambiguous. Indeed, Standard ML (another functional language) is one of the few languages to be formally specified.
Maths is more type-dependent in the absence of parentheses. E.g. sin cos⁻¹ x = sin(cos⁻¹(x)), but A cos⁻¹ x = A × cos⁻¹(x).
By "ambiguous" I mean to people looking at the code. Obviously it's unambiguous and well-defined to the computer.
While it's been over a decade since I first learnt this style of functional languages, I don't remember being confused by application syntax. It also helps that function application binds more tightly than anything else.
I don't think it's any great indictment that it is not immediately understandable to someone who does not know the rule. There will be lots of other things someone will not be able to understand in a Gluon program, unless they know Gluon. It's perfectly reasonable to expect someone to learn a programming language before they write code in it.
Yes, mathematical notation is also heavily overloaded, often abbreviated or "abused" and full of "puns".
There have been some attempts to "fix" this. Lambda calculus (the basis of most functional languages) could be seen as an attempt to do this. A more recent example is https://en.wikipedia.org/wiki/Structure_and_Interpretation_o...
That is a lot like saying: in the Python expression "5 - 4 - 1", how does the language know to subtract 4 from 5 first, and then subtract 1 from the result, rather than subtracting the 1 first?
The answer is: precedence rules. It's not ambiguous, though you might not know which order applies if you aren't familiar with the language. The same could be said of the syntax of any language, except perhaps for those in the Lisp family.
Functional languages generally don't try to be familiar to programmers who are used to other paradigms, because that compromises the elegance of the language (for example, mandatory parentheses for function calls and currying are an ugly mix). But once you learn a language in the ML family (Haskell, OCaml, etc.), they all have the same kind of familiarity that a Java programmer feels when they look at C#.
I understand that other languages make different choices regarding syntax and readability. This particular choice, while not inherently a bad choice, makes things more difficult for most people, and led to eximius's comment at the start of the thread:
> It makes code much more difficult to read
I agree that the "f x y z" syntax can look confusing/unfamiliar to people who haven't seen it before, whereas everyone knows how subtraction works. But it's worth learning because currying is an elegant way to simplify a language and make it more uniform: a function is just a map from a single argument to a single result. To compose functions, you only need the output type of the first function to match the input type of the other function. You can build a general function composition function that takes two functions and returns their composition. There is no arity to worry about. Parentheses should be used for grouping and not be overloaded to also indicate function calls.
Personally I'm really not a fan of relying on operator precedence. Even in that Python example I would write it `(5 - 4) - 1` to disambiguate. I have a few issues:
- Firstly, parsing combinations with varying precedence is something that computers are good at but people not so much, so I see no reason to force readers to juggle this sort of stuff.
- Second, mathematical precedence rules are overly complicated. Trying to support them can make a language overly complicated. Languages like Smalltalk prefer to remain simple, even if that "breaks" standard mathematical expressions https://en.wikipedia.org/wiki/Smalltalk#Expressions
- Finally, arithmetic is a tiny part of a programming language. There's no "standard" way to extend operator precedence to include, say, 3D rendering operations, or parser combinators, or attaching event handlers, etc. All we can do is give each operator a number, at which point we're just exacerbating the "humans aren't good at precedence tables" problem.
This has also been discussed elsewhere, e.g. at http://wiki.c2.com/?OperatorPrecedenceConsideredHarmful
PS: I prefer the `f a b c` function call syntax to `f(a, b, c)`, but prefer s-expressions to both. Scheme is really nice, but I don't want to live without currying and laziness by default. I have high hopes for https://lexi-lambda.github.io/hackett :)
For example, how do you read this?
f -4
In languages where there can be functions with no arguments, if referring to the function without parentheses calls it, it can be inconvenient to get a reference to the function itself.
From your other post: "In both Gluon and Haskell, functions without arguments can be represented as functions over the unit type: f: () -> SomeType"
Isn't `f` a constant here too?, how is this different than getChar? (I get I don't understand something here but not sure what)
(Though yes, `f` also is a constant... it's just a constant that happens to be a function, which `getChar` is not.)
http://hackage.haskell.org/package/base-4.11.1.0/docs/Prelud...
It represents an interaction with the outside world that results in a Char when you perform it. It isn't a function because in Haskell functions must be pure (with no side effects).
data MyFun a = MyFun (() -> Char)
f: () -> SomeType
f ()
(Note: This is (basically) useless in Haskell, since laziness makes this have the same semantics as a constant:
f :: SomeType
Depending on how dense the code is, it isn't that bad. But it is another barrier to understanding.