the | notation

[osher]

I have a bad feeling about that in the | fn a,r,g,s | form, as expressions get more complicated - when you meet a | - you cannot tell if it opens or closes.

I know you're out of paired chars ( () = args, [] = index, {} = blocks, <> tuples), and I can see you decided not to overload notation semantics - mk... I can see how that could be useful. And on the same breath - | is overloaded to open and close that special function form...

But you don't have to use a pair from the math-semantics world:
It could be any two characters, one opens, the other closes. Say that | opens - chose any character for close. e.g. - | fn a,r,g,s @. I see that $ is still free (but I also am not a fan of this char... takes me back to my early darker days in perlscript and perl).

You can always use a two char notation - e.g. |. fn a,r,g,s .|, but I'm sure we don't want to go there for a semantic we expect to be very common. Plus - if we do - any other math-semantic pair would do much better than |.

[getify]

I appreciate the concern you share... I initially was quite reluctant to go this direction. But I definitely didn't want ( ) to be overloaded between "args list to infix function call form" and "s-expression call form". And as you pointed out, [ ], { }, and even < > are already sufficiently taken for other uses, so I wanted to avoid them, too.

I had contemplated unbalanced options, like [| ], etc. But I was under the impression from discussions in JS land that people really hate unbalanced opening/closing tags. I dunno why, but there was strong pushback when I suggested it for JS Records/Tuples.

I even considered \ / (or / \). I ended up using a variation of the / delimiting for pattern matching. I still might switch the pair of pattern matching tags from ?/ /? to ?/ \?.

One thing to note is, two | | adjacent to each other (either whitespace or not) must either be two+ opening tags OR two+ closing tags. That is, | | can never be an opening-closing pair or a closing-opening juxtaposition, as neither are legal. I think that does reduce the confusion of | being opening and closing.

I also kinda like that ||| packed together seems easier to count (IMO) than (((.

I'm weary for |. .| or other options like that, mostly because I think people may dislike the multi-character choice enough. But they have to put up with ?/ /? for pattern matching, so... maybe that concern isn't too much.

One thing to be aware of with a multi-character tag pair is, the character on the "inside" really shouldn't be a character that's already an operator, since there will be a lot of |* 1,2,3| kinds of expressions, with minimal whitespace, and it could get really confusing to see |.'* 1,2,3.| -- where the leading . is part of the delimiter, the ' prime is reversing the arg order, and * is the operator function itself. Moreover, the trailing . could be ambiguous with the final argument (numeric literal or identifier).

Similarly, if we put the non | on the outside, it can't be ambiguous with operators that could be executing against the overall expression. .| |. could have ambiguity with . on either side of the expression.

If we did a multi-character tag pair, here are some options I can think of that likely avoid ambiguity

• [| |]
• |[ ]|
• |/ \| (disadvantage that it looks like it's "escaping" that final |)
• |) (| kinda ugly, but is unambiguous
• |` `| (backticks) -- I'm planning for regexes to be in backticks, so this could be ambiguous
• |$ $| -- a funny nod to "S-expressions with the $

Thanks for bringing this up. I'm certainly open to exploring it, not set in stone yet. But I don't want to juggle too much of what I've already designed for the other features, so we do have a few constraints to consider.

[osher]

I really like this to work. I have not seen anything refreshing for a long while.

Thinking about the speed in which you write and the amount of features you're capable of - I suggest you try to rank operators/notations by usability, and save the single-character forms for the features you expect to be most useful, as opposed to the order of writing.

Consider also reserving places for the future

[getify]

Compare:

 | + 1, 2, 3 |
 $ + 1, 2, 3 |
$| + 1, 2, 3 |

Of these three options, which do you prefer best?

[osher]

I like the 2nd. I'm not sure if $ .. | or | .. $. lets try, but lets try something more complicated

$ log $ + 6, 12 ||;
$ $' - | 1, 6 |;
$ $ + 6 | 12 |;

$ $defn(x,y) ^x + y| 6, 12|;

How about
$ $ + 1| 2, 3 |
$ $ defn(x,y) ^x + y | 6, 12 |;
$ $ defn(x,y) ^x + y | $ + 1, 2, 3 | , $ * $ + 1, 2, 3 |, 2 | |;

$ $ defn(x,y) ^x + y | $ + 1, 2, 3 | , $ * $ + 1, 2, $ + 1, 2 | |, 2 | |;

I see how that works. The | kind'a implies - value may be curried here - i.e. - piped here from the right...

compare that to

| | defn(x,y) ^x + y | | + 1, 2, 3 | , | *  | + 1, 2, | + 1, 2 | |, 2 | |;
 /\                   /\                                       /\     /\
  open              close                                     close    close 
  open              open                                      close    close

panic mode... I pity the contributors that should work on the parser

How would that look in multi-line?

$
    $ defn(x,y) ^x + y | 
    $ + 1, 2, 3 | , 
    $ 
        *  
        $ 
           + 
           1,
           2, 
           $ + 1, 2 | 
        |,
        2
    |
|;

mm. I wanted to propose ~, but I see you already added use for it...
well. keystroak effort - they're mostly equivalent, where $ is ever slightly easier.

[getify]

I think you have perfectly valid points, and I appreciate you staying engaged to work through this.

My concern at this point is, this kind of minimal-whitespace style:

$'- 1,2,3|

// vs:

|'- 1,2,3|

Specifically, the beginning of a evaluation-expression is very likely to have one or more operator characters in it, and I want the beginning of the tag to be as visually distinct from the rest of those operators as possible.

That's why I like | so much, since it's tall, straight, and doesn't really look like any of the other operators (except possibly [ depending on your font).

So if we instead go the |+ 1,2,3$ (or worse |+ q,r,S$ route, now we have the same problem at the end, which is that the final character in the argument list might happen to not be very visually distinct from the $, and therefore it might be easier to miss. Again, here, the | stands out from most any other character.

These are the reasons that I landed (reluctantly) on | | when I had decided that [ ], < >, and ( ) were taken for other reasons.

But again, I do get why, in some of your examples, it's going to also be confusing.

How objectionable would (| .. |) or [| .. |] be, do you think?

[getify]

Also, it just occurred to me... (| .. |) would be syntactically valid where | .. | was, just with optional parens around it. Which would mean anywhere that | .. | was creating visual confusion, (| .. |) could always be used by the author to clarify the visual ambiguity, and the parser wouldn't care.

Is that a possible compromise, to have it be | .. | strictly, but then document and point out that (| .. |) is perfectly valid and sometimes advisable?

I dunno, maybe the optionality of it is not good enough. Just thinking out loud here.

[getify]

I've been brewing on this quite a bit over the last couple of weeks.

I decided to write up a section in the README to address your concerns head-on, and explore the compromise option I mentioned previously.

This is not perfect, I admit. But given all the various options and constraints, I think it's good enough.

[getify]

+@osher

UPDATE: I just landed a change that drops the |-based optional-lisp form entirely. It was proving "too weird" for those who were trying to understand Foi.

The main capabilities intended to be enabled by the previous lisp form have been accommodated by new features:

• operator-as-function form (i.e., (+)(1,2,3,4,5)
• partial-application form (i.e., foo| 1, , 3 |)
• prime operator (postfix) for arg reversal (i.e., foo'(1,2,3))

These 3 can of course all be mixed.