Function Syntax

[keean]

One of the first things we need to do is decide on a function syntax, for application and definition.

[keean]

I don't think we want something too weird and new, so we should follow the conventions of existing language families. Do we want to follow the functional style which makes variable and function assignment similar (and maybe support partial application):

x = 1
f x = x
g x y = (x, y)

or do we want something from the 'C' family:

int x = 1
int f(int x) = x
(A, B) f<A,B>(A x, B y) = (x, y)

or something like Rust (without the types for inference):

let x = 1
fn f(x) { x }
fn g(x, y) { (x, y) }

Or perhaps python like:

x = 1
def f(x):
    ...
def g(x, y):
    ...

[shelby3]

@keean wrote:

Do we want to follow the functional style which makes variable and function assignment similar (and maybe support partial application):

x = 1
f x = x
g x y = (x, y)

I have argued here, here, here, and here to not to adopt that syntax.

Also that syntax is more ameniable to global type inference, because it otherwise requires a duplicate line to declare the type of the function.

Insurmountable negative factor is that vast majority of the world's programmers will be unfamiliar with it (unnatural, not second nature, fights their ingrained second nature), because it is too different from the most popular languages, JavaScript, Java, C, and C++.

I argued it raises the cognitive load too much both at declaration and at the call site, because it requires computing too many factors (inference, precedence, declaration site types and arity).

From the author of the acclaimed Learn You A Haskel:

I failed to learn Haskell approximately 2 times before finally grasping it because it all just seemed too weird to me and I didn't get it.

@keean wrote:

However I do think you have a point about people not used to the style.

You seem to have agreed?

Btw, partial application can be done with the other syntax styles. I will explain later.

[keean]

@shelby3 I agree I just want to capture everything relevant here.

I also remember we wanted something like Python style indenting rather than curley brackets.

Do we want to have a keyword like 'def' or 'fn' for function definitions?

[keean]

I actually quite like Rust's syntax for definitions, rather than Python or TypeScript. One problem is with combining TypeScript style signatures with Python style indenting:

inc(x : Int) : Int :
    ...

The problem here is we might want to leave out types:

dec(x) :
   ...

It makes it impossible to tell whether the return type is missing. Whereas with Rust style:

inc(x : Int) -> Int :
    ...

[shelby3]

@keean wrote:

The problem here is we might want to leave out types:

I was just about to post a similar point. We can't use the C/Java-style of type precedes instance name:

int x = 1
int f(int x) = x

Also I wouldn't want some verbose gaudy type as the prefix any way.

I wrote that 2 days ago:

If non-exported function signatures can be inferred, then a syntax with optional type annotations would seem better.

Agreed. Thus we need the suffixed : type and not the C/Java prefixed type declaration.

Haskell puts the optional types on a separate line instead which I think is unfamiliar, consumes extra lines and violates DNRY, which I don't like (then afaik all the types have to be provided, not the option of just some of them).

[shelby3]

@keean wrote:

Do we want to have a keyword like def or fn for function definitions?

Since yesterday, I've been trying to think if there is a way we don't have to prefix the function declaration (aka definition) with fn or def (because I hate noise, unless it aids readability). I was going to work on the LL(k) parser grammar so we can prove it is a context-free grammar (CFG), which is very important. Also I want consistency with declaring methods in the body of typeclass definitions. So if we need to prefix with fn or def for local functions, then we should do same for methods, but I hate that boilerplate.

I've been thinking about all these issues too. 😉

Inside the body of the typeclass declarations we certainly don't need the prefix on methods. But for functions declared inside the body of another function, we would have a grammar conflict with function calls. One way to get around that is to force a space between the function name and ( for declarations (e.g. f (x...)) and that whitespace not allowed for function calls/application (e.g. f(x...)). I may have other ideas. Let me think about it for a while.

The grammar is really a holistic design and we can't design it piecemeal and be sure to not have CFG conflicts.

Feedback?

[shelby3]

@keean wrote:

I also remember we wanted something like Python style indenting rather than curley brackets.

---

inc(x : Int) : Int :
   ...

The problem here is we might want to leave out types:

dec(x) :
  ...

It makes it impossible to tell whether the return type is missing

I don't like the alternative syntax with an arrow inc(x : Int) -> Int :. It is inconsistent! Consistency is very important. And that trailing : is very confusing no matter what we do.

In the LL(k) grammar I was working on in May, I devised a solution which eliminates the need for the trailing : to indicate the start of an indented code block.

I presumed we will enforce a standard indent as agreed by @SimonMeskens.

The rule is that if the following line is indented by the standard amount, then it is a new code block. If it is indented more than the standard amount, then it is the continuation of the prior line.

I realize that enforcing indenting spacing is something that programmers will disagree on because they all have their preferential amount (and some want tabs and others want spaces), but this is open source and consistency (for readability) is more important than allowing people that freedom to make code unreadable for others (such as when the tabs don't line up!).

Btw, I am hoping we decide for 2 spaces indent to conserve horizontal space for deeply indented blocks? I notice from your examples, that you like more spaces when you indent (4 or 5?), but the really skilled programmers I've seen use 2 spaces, because 2 spaces is enough and also it helps align at the tail of the if on the line above:

if x
  something
else
  something else

Three spaces uses 50% more horizontal space and it aligns with the x which is confusing or consistent depending on the way one thinks about it:

if x
   something
else
   something else

Any block indenting greater than 3 spaces is going to piss off some programmers. Any programmers who think they need 4 spaces for block indenting are amateurish. Our eyes can't easily detect it at 3 spaces, and I find 2 is enough (and I am blind in one eye and blurred in the other eye).

What is your opinion? I could tolerate 3 but I don't think it is ideal. But 4 makes me not happy:

if x
    something
else
    something else

And 5 is ridiculous:

if x
     something
else
     something else

Most of my coding life I used 3 spaces, but when I saw that expert coders were using 2 spaces, I realized I didn't need 3.

[SimonMeskens]

What about the wildly popular arrow syntax? It's familiar, due to being included in JavaScript, TypeScript, Java and C# and it's quite concise (unlike using a keyword like def or fn). I'm using indents, but this would work with curlies or anything else too (I personally prefer required indentation). In Coffeescript, return is optional, but I really don't like that. What I do like is optional return for one liners. I kinda like the conciseness of not having to use brackets, but I agree that it makes the language rather dense to read and hard to get into. I agree with earlier sentiment that semi-colons are evil. You pay a penalty for all your code for that one time where you need them, usually to make your code less readable. I picked a thin arrow (->) instead of a fat arrow (=>), which is used more often, because I think the fat arrow is visually quite busy.

Block lamda (daft sample to pad it out a bit):

inc(x: Int): Int ->
  let y = x + 1
  return y

Notice that absence of type on y means the compiler implicitly assigns type, not that y is untyped.

Now, the problem arises for me, when you want to type curried functions or just simple lambdas. What do we use for indicating a type goes from one to the other? TypeScript for example uses the fat arrow for both, this is syntactically very confusing. I think for this reason, we could also replace the arrow with double colon. I personally think double colon is the nicest separator, but it's slightly less popular.

I'll introduce something else I like too: using := for assignment, like in Pascal. The reason being that this gels nicely with :: (both are a type of assignment, one assigns code, one assigns a value) and because it allows you to use = for comparison, as == for comparisons is visually busy and comparisons already tend to be the busiest syntax. I might even go as far as to suggest and and or for logical operators to further fix that.

filter(list: List of Item, pred: Item -> bool): List of Item ::
  let out := List(Item)
  for(item of list)
    if(pred(item))
      out.add(item)
  return out

filter(myList, x => x = 5)

Notice that we might as well just drop the ::, as with forced indent, it's clear that the block indicates a function body.

inc(x: Int): Int
  return x + 1

I kept the code quite imperative for now, to not assume too much yet. If we do get rid of brackets, I might prefer something like this I think? Still keeping brackets for calls maybe? Starting to get alien. Still less confusing than Haskell though.

filter
  list: List of Item
  pred: Item -> bool
  return List of Item
=>
  let out := List(Item)
  for item of list
    if pred(item) and not item.empty
      out.add(item)
  return out

filter(myList, x => x = 5)

[shelby3]

@SimonMeskens wrote:

What about the wildly popular arrow syntax? It's familiar, due to being included in JavaScript, TypeScript, Java and C# and it's quite concise (unlike using a keyword like def or fn).

inc(x: Int): Int ->
  let y = x + 1
  return y

That solves the : at end to start a new block, but I offered also an enforced indenting style as a solution instead, which removes that noisy arrow.

Your suggestion won't work for eliminating the def or fn as I explained where I offered inc ( with the space between inc and ( instead, because we need efficient LL(k) left-to-right parsing with minimal constant maximum number 'k' of tokens lookahead, but yours is an unknown variable unbounded number of tokens lookahead (for the parser to differentiate it from a function call, as parser has to reach a : to distinguish from function call, and : is optional on each argument for non-top-level functions).

I potentially like your idea of consistency between the syntax of anonymous lambda functions and regular function implementations (but maybe they shouldn't be equated since one is not a singleton, is not named, and other is a named, singleton?), but you've rendered the new block syntax inconsistent with if as follows (and I'm not sure which consistency should be our the priority choice?):

if x
  something

Also this would be inconsistent with -> to start new block:

if x:
  something

[SimonMeskens]

That seems fair enough, was just offering some ideas. Personally, I really like homoiconic languages, but I'm not sure how feasible that is for this one. Here's a good article on it:

https://blogs.oracle.com/blue/entry/homoiconic_languages

[shelby3]

I am very sleepy so I hope the following is coherent.

On further thought, I must overrule my prior suggestion for an enforced number of spaces for indenting. As much as I would like to have this consistency, I don't think it will be popular because any choice will offend most people who don't like that choice. Number of spaces for indenting is a personal preference.

I looked at the grammar I wrote in May and now I remember how I solved this problem and maximized consistency.

First we must consider that these and if-else will also optionally be used without a code block and also that if-else will replace the ternary operator to simplify the language (more consistency) and because the if x: or if (x) at the start has lesser chance of precedence errors than "string" + x ?. Also I force a code block for nested if (as shown below).

So I suggest that if (x) is superior to if x: because the : when a new code block doesn't follow (i.e. what follows is on same line), then it could make be confused with a type annotation (or even a cast if we ever used that : Type format for casts). Also the : is more invisible when crowded.

if (x)
  true
else
  false

if x:
  true
else
  false

if (x) true else false
if x: true else false

if (x)
  if (y)       // may not put this at end of prior line, because it is a nested `if`
    true
  else
    false
else
  if (y)       // may not put this at end of prior line, because it is a nested `if`
    false
  else
    true

So if we choose if (x), then consistency with function definitions is lost in terms of the character that separates the code block, or code on same line. Thus I am comfortable with @SimonMeskens' idea except I favor the fat arrow (=>) because JavaScript and Scala use it and it looks more like an assignment symbol (=) so we can consistently use the same symbol for code block, one line function code (see below), and lambda (aka arrow) functions. Also afaik -> has typically been used for type signatures and not anonymous (unnamed) lambda functions, although Java 8 uses ->. The following definition now looks like assigning a lambda function to the function name, which is actually how JavaScript does it for { inc : (x) => return x + 1 }.

inc = (x: Int): Int =>
  let y = x + 1
  return y

inc = (x: Int): Int => return x + 1

Notice above instead of def, fn, or my hokey space idea, I used an = to differentiate from a function call inc(x...) needing only k = 2 tokens of lookahead (note inc no matter many characters is one token returned by the lexer to the parser). It is not shorter than def or fn, but it is more consistent with the usage of lambda functions, because we assign the unnamed lambda function to the function name.

Some people suggest to reverse the direction of the arrow?

[SimonMeskens]

That seems pretty clear to me 👍

[keean]

Some interesting ideas, I quite like the uniform assignment syntax. Haskell and other functional languages define functions as:

x = 1
f x = 1

It just means you need an LR parser. So I don't see a problem with:

x = 1
f(x) = x

I would suggest using '=' consistently. However I also like the anonymous function syntax and using normal assignment:

f = (x) => 
    x

That looks odd for something like the identity statement.

I would suggest the block begins if there is nothing on the same line after the '=>' .

I think block indent depth should be set by the indent of the first line. Line continuations would be any kind indented more than this.

However there would be problems where there is a block and a line continuation like:

set_callback((x) => 
        print(x)
        x + 1
    ) // Must be at least as indented as the original, but less than the block indent.

What about optionally naming the anonymous function to help debugging. JS allows this:

set_callback(move_right(x) => x + 1)

I think these forms will require an LR parser, but I am okay with that.

[keean]

Should we allow no brackets for a single argument function?

f = x => x + 1