Arc Forum | why restrict [] function syntax to one argument?

Arc Forum

why restrict [] function syntax to one argument?

2 points by hkBst 6136 days ago | 4 comments

I really like the new [] function syntax, but it seems to me that it could easily be extended to allow any number of parameters and even an arbitrary number. Observe:

[f _ 1] ::= (fn (_) (f _ 1)) ; this is all that works now, IIANM

[f _0 _1 2] ::= (fn (_0 _1) (f _0 _1 2))

simply demand that all identifiers starting with an underscore are arguments to be passed. We need one more special identifier to allow arbitray number of arguments:

[f _0 2 _1 ...] ::= (fn (_0 _1 . ...) (apply f _0 2 _1 ...))

4 points by are 6136 days ago | link

This is also discussed in this thread:

http://arclanguage.org/item?id=1227

-----

1 point by are 6136 days ago | link

[This is my comment re-posted from that thread. I hate zero-based indexing.]

In this expression:

[+ _1 _2 _3]

... the interpreter already knows that _2 is the second anonymous parameter to the function literal, without parsing the "2" token.

So you could instead have:

[+ _ _ _]

... and specify the index only if you actually want to use the parameter outside of the function literal (and there, _ would still be shorthand for _1).

And BTW, this whole thing should work with rest parameters, so that in:

[+ _ . _]

... _2 will denote a list.

-----

4 points by hkBst 6136 days ago | link

Using [+ _ _ _] with the same meaning as [+ _1 _2 _3] would be confusing I'd say. [+ _ _ _] should mean the same as [+ _1 _1 _1] if it is allowed at all.

(= x2 [+ _ _])

Explicit numbering will make sure the arguments stay in the correct order so my earlier remark of allowing any underscore-beginning string is probably wrong.

-----

1 point by maxwell 6135 days ago | link

Could do

  [+ _ __ ___]

But, that would probably get pretty insane pretty quickly...

-----