Why `fn() {}`?

[bates64]

Why do we use

foo => fn(bar, baz) {
  # code #
}

rather than, for example

foo => (bar, baz) {
  # this is shorter! #
}

It's something I've been thinking about it and calling fn and then passing variable definitions... it just seems to me like calling a function to create one seems a bit dodgey - it doesn't do what is expected.

[towerofnix]

fn(args) {code} seems a bit more explicit, but there are lots of times when I want to use fn as a parameter or variable.. discussion needed! :P

I get it looks kind of like a function call. Hmm..

[bates64]

I have two ideas:

# 1
foo => (bar, baz) {
  # code code code #
}

# 2
foo => {
  (bar, baz) # hell if we can; ommit the brackets alltogether!
  # code code code #
}

Thoughts?

[towerofnix]

I prefer #1 there.

[bates64]

Also I think typed arguments should exist, builtin? For example:

foo => (bar@str) {
  print('yay')
}

foo(123) # foo(...): Argument 1 must be a string

[towerofnix]

Also I think typed arguments should exist, builtin?

I kind of dislike using static typing..

If you need a string, change the input to a string. (Wait, we don't have a function for that? Oops..) If you really need some fancy prototype thingy, check if it's of that class manually -- that's how I do it..

if (!(x instanceof FancyClass)) {
  throw new Error('Argument must be instance of FancyClass');
}

EDIT: Plus static typing belongs in a different issue!

[bates64]

I guess so :) Although then we need some sort of type() function in Tulun!

[towerofnix]

Apparently people like this.

foo => (bar): *(bar, 2);
baz => (bar) { return(*(bar, 3)); };

[bates64]

And also this @liam4.

# single argument, ommit brackets (may be hard to implement?) #
foo => bar {...};

# no arguments, ommit brackets altogether #
foo => {...};

[towerofnix]

single argument, ommit brackets (may be hard to implement?)

Probably not hard to implement. Not sure I like it though.

no arguments, ommit brackets altogether

Oops, yeah, that too.

[bates64]

Probably not hard to implement. Not sure I like it though.

Same here. Just implement the others first? :package: