What sorts of changes are people interested in?

[jpco]

So over the last few years, I've built up a small hoard of changes to es.

Some of them are pretty uncontroversial, like better readline integration and a method for shrinking the generated binary, or pretty small, like replacing in the C code "nThunk" with "nLambda" with no parameters (with no change to behavior). Some are just weird personal preference, like any time the parser finds a case of {{}} it deduplicates the braces down to {}.

Some are more debatable whether they're good ideas, like adding arithmetic syntax (which I basically just stole from xs, though the implementation itself is mine)

; let (x = 2) { echo `($x + 2); echo `($x * 4); echo `($x / 3.) }
4
8
0.66667

or a new => operator, letting you rewrite

; echo <={%count <={result one two three four}}
4

into the more-legible-to-me

; result one two three four => %count => echo
4

I have one set of changes which are even more radical, where I made a new set of es: functions. In this setup, I put function lookup and path searching into initial.es:

es:whatis = $&keeplexicalbinding @ cmd rest {
  $&if {~ $(fn-^$cmd) ()} {
    if {~ $cmd /* || ~ $cmd ./* || ~ $cmd ../*} {
      result %run $cmd $cmd
    } {~ $fn-%pathsearch ()} {
      result ()
    } {
      %pathsearch $cmd
    }
  } {
    $&result $(fn-^$cmd)
  }
}

and was able to get most of the logic in main() into es script language as well (see https://github.com/jpco/es-shell-mirror/blob/es-main/builtin/runtime.es#L241). I also was able to redefine both $&batchloop and $&dot in pure es, which is pretty cool.

Anyway -- I'd be happy to make PRs for just about any of this stuff, but rebasing and cleaning the changes up takes some effort (as would reviewing it all), so I'd like to know ahead of time which, if any, of this is interesting to anyone else. What do folks think?

[wryun]

Minor fix-ups/tweaks 👍. Actually, even if no-one one reviews them, I'm happy to merge if I don't get to reviewing them within a month, given that at least you've been using them for real for a while.

More radical, I'm a bit unsure. Because I'm not really the owner of es, rather I just nominated myself as someone who cares enough es to want a decent place to accumulate patches, I lean towards conservatism, and for me part of the charm of es is leaning heavily on standard utilities so I'm not sold on adding arithmetic. But <={ has always looked ugly to me, and I like the readability of =>, even if I find its behaviour a little surprising (xargs like, I guess?). Something like =| feels more natural to me, so you could do result blah =| cat (i.e. piping the result - err, unless I've missed some existing easy way to do that...). And then => would simply be a redirect of the result...

To be honest, I'm not entirely sure how competent I am to review these kind of changes anyway. @memreflect and @mwgamera have actually spent time poking round in es internals, whereas I'm almost entirely a casual user.

[jpco]

=> is indeed xargs-like. It desugars into:

; echo {a => b => c}
{%pass {a} {b $-} {c $-}}

where %pass is defined in initial.es as

fn-%pass = $&noreturn @ first rest {
  local (- = <={$first})
    for (cmd = $rest) - = <=$cmd
}

This would be a great use case for user-definable syntax :)

[mwgamera]

Bug fixes are always welcome. As are internal improvements, like the reduction of the initial.es dump you just submitted, and probably most of those you consider uncontroversial.
While I understand people wanting to experiment with syntax, I started to use es because I liked it the way it is and personally I'm not interested in any new syntax being introduced to it, although some backward-compatible tweaks like allowing = in words are nice to have. But in particular I would oppose something like echo `($x + 2) because that would break some scripts. I think you mean echo `(expr $x + 2) which already works :)

[jpco]

I think most people would agree (I might even be among them) that the arithmetic is fairly superfluous. It also proved to be a surprisingly invasive change to make work how I wanted -- I had to add a few new tree types, and ended up with a lot of assertion failures and segfaults due to missing cases in switch statements. Not pretty.

I also agree in general that syntax changes are flashy and fun to make but should have a high bar to actually pull in. I was honestly pretty surprised to find match had been added.

How about something that feels more "edge-casey" to me -- how conservatively should we approach how code is externalized?

A quick example is this:

; let (a = b; c = {let (a = b) d = f}) let (e = {x}) echo $e
# wryun/es-shell vs. jpco/es-shell-mirror
%closure(a=b;c='{let(a=b)d=f}'){x}
%closure (a = b; c = {let (a = b) d = f}) {x}

I know these code representations are a big mess beyond 100-ish characters anyway, but I find the increased white space and less-aggressive quoting produce much more readable output. It's certainly not invisible to users, though.

[jpco]

Don't mind that the example here makes no sense. I just needed to print out some %closures and lets.

[memreflect]

Some of them are pretty uncontroversial, like better readline integration and a method for shrinking the generated binary, or pretty small, like replacing in the C code "nThunk" with "nLambda" with no parameters (with no change to behavior).

"nLambda" would imply an argument is accepted, which is not true in the case of something like {cat} foo.
"nLambda" also more accurately describes @ [args] {...}.
"Thunk" is a more-technically-correct term as it means a function/procedure that accepts no arguments.
If i were to rename it anyway, i'd probably name it something else like "nCode" instead.
But i have my own weird personal preferences just like you, so the name matters very little to me.

Some are just weird personal preference, like any time the parser finds a case of {{}} it deduplicates the braces down to {}.

That would certainly prevent someone from thinking {{1 2} {3 4}} in combination with the ~~ operator is how you can get around the lack of nested lists when it is actually treated as a string (as far as i can tell from some quick experimentation anyway).
For example:

; x = <={~~ {{1 2} {3 4}} '{'*'}'}
; y = <={~~ $x '{'*'}'}
; printf '%s\n' $x $y
{1 2} {3 4}
1 2} {3 4

Some are more debatable whether they're good ideas, like adding arithmetic syntax (which I basically just stole from xs, though the implementation itself is mine)

; let (x = 2) { echo `($x + 2); echo `($x * 4); echo `($x / 3.) }
4
8
0.66667

I like the idea of using C's built-in arithmetic operations instead of calling out to expr or awk, but i'd be more in favor of a new $&math primitive or a built-in that returns the calculation result similar to fish's math built-in rather than abusing the ` character that is currently reserved for splatting the contents of standard output after being split on $ifs.

or a new => operator, letting you rewrite

; echo <={%count <={result one two three four}}
4

into the more-legible-to-me

; result one two three four => %count => echo
4

It desugars into:

; echo {a => b => c}
{%pass {a} {b $-} {c $-}}

where %pass is defined in initial.es as

fn-%pass = $&noreturn @ first rest {
  local (- = <={$first})
    for (cmd = $rest) - = <=$cmd
}

This has potential for confusion, but i certainly enjoy how composable it looks; that's the biggest reason why i love using xargs.
It even reminds me a bit of Haskell, a functional language, which means it could fit nicely with the functional spirit of es as well.
I implemented fn-%pass as described, but it seems like it works only when you use it with a command that is a single word, like %count or echo:

;   # result hello world => echo -n
; let (a = {result hello world}
       b = {echo -n})
   %pass {$a} {$b $-}
;

Removing the braces surrounding echo -n to make it a list of 2 items will work in this particular case, but you get a syntax error when you replace -n with a file redirection (e.g. result hello world => echo >foo should be turned into echo >foo hello world instead of {echo >foo} hello world).

Overall, I agree with your final statement in a general sense.
I've been a bit too busy lately to work on any improvements of my own, understand the GC better, etc., but it's definitely "pretty cool" to see some discussion about improvements to es. 👍

[jpco]

Enough people seem intrigued about => that I'm going to cook up a PR so it can be discussed in more detail. I personally think it's a neat mechanism that meshes well with es' list-typed variables and rich return values. => is also invalid syntax today, which is nice.

Oh, also, one of the first things I did was change $$x(2) to no longer parse the same as $($x(2)). I completely forgot why I did that until I saw it's discussed in the old mailing list!