## Paranthesis functions

If you want to discuss about Oforth...

### Paranthesis functions

I'm not so much a fan of using functions with parenthesis, the good thing is in oforth I can leave them out, is this something that is looked on as hard to read?
To clearify what I mean

Code: Select all
` [1,2,3] #. swap apply `

Code: Select all
` [1,2,3] apply(#.) `

or

Code: Select all
` : add { + } `

Code: Select all
` : add(a,b) { a b + } `

I'm not completely sure, on the one hand the parenthesis some times makes it easier to follow the code, but more often for me, it becomes a bit much nail clip salad, with { [ ( and ) ] } all over the place, then for my eyes at least, code with less () becomes easier to read. I'm a bit unsure.
sotolf

Posts: 55
Joined: 30 Jul 2015 15:53

### Re: Paranthesis functions

Hello,

There are two kind of parenthesis :
1) Parenthesis when you call a function or a method
2) Parenthesis when you declare a function or a method.

1) When you call a function or a method, parenthesis are just sugar syntax.

You can write :
#. [1, 2, 3] apply
or
[ 1, 2, 3 ] apply(#.)

This is mostly a coding style preference and, here, you know that #apply need one parameter, so this is the same.

But what if I write :
Code: Select all
`#. [ 1, 2, 3 ] myMethod`

Do #myMethod will consume #. or is it just a method on lists ? You don't know if you don't know how #myMethod works.

If I write,
Code: Select all
`[1, 2, 3] myMethod(#.) `

you have one more information without reading myMethod : you can assume that #myMethod will consume #. and you can follow the code.

But, like I said, this is mostly a coding style preference and people who come from Forth will always write
#. [ 1, 2, 3 ] myMethod

2) When you declare a function or a method
Here, this is not just sugar syntax. If you declare parameters, each parameter will be removed from the stack.

Of course, if you use those parameters only once, you don't need to declare them, but then, all Forther will tell you that you must specify the stack impact for readability.

For instance :
Code: Select all
`// add : ( x x -- x + y ): add { + }`

But, let's say that you write a function that compute : (a + b) / sqrt(a^2 + b^2)

Code: Select all
`: f(a, b) { a b + a sq b sq + sqrt / }`

Here (at least for me), I would not think to write this function without parameters. It could be something like that :
Code: Select all
`: g    // ( b a -- x )   { over over + tor sq swap sq + sqrt / }`

If I come 6 months later, I think I could understand f better than g. But perhap's "true" forthers will prefer g...

Or this function, that compute complexs product (this is just a theorical example, in reality, you would write a Complex class) :
Code: Select all
`// z*     ( d c b a -- re im ): z*(a, b, c, d) { a c * b d * - a d * b c * + }`

Writing this without parameters will add so many stack juggling that I will never think about writing it (and I don't write it here )

Those parameters also allow to avoid the need for combinators. And, for performances, f is faster than g.

Let's take a last example : factorial. You could write :

Code: Select all
`: fact1 { 1 swap loop: i [ i * ] }: fact2(n) { 1 n loop: i [ i * ] }>1000 fact1 .`

Forthers will probably write #fact1. Non forthers will probably write #fact2. There is no difference (well, fact2 will be just a little faster than fact1, but nothing to worry about).
Here I could write both...

All in all, I would say that this is mostly prrgramming style, unless not using parameter leads to too many stack juggling...

Franck.
Franck

Posts: 155
Joined: 29 Oct 2014 19:01

### Re: Paranthesis functions

Ah, okay thank you for the nice explanation Makes sense to me, and yeah, I do agree that for some chosen words where there would be a lot of stack shuffling use of variables makes it a lot cleaner. Good to know thank you.
sotolf

Posts: 55
Joined: 30 Jul 2015 15:53