i looked through that chat log. unfortunately over my slow connection it is painful to read. i had to manually copy it one section at a time because it would not load the whole thing at once and kept discarding and reloading sections that are out of view (that's why the slow connection made it painful, anyways, end rant)
i haven't read all of it in detail yet, but i get the gist, and in particular the conclusion. thank you.
i would go for something a little different, possibly a bit more complex DSL:
basically one key syntax feature i would like to have is the ability to run shell commands or red expressions and use their string output as an argument to another shell command:
like in bash:
cmd1 arg1 $(cmd2 someargs) arg3 $(cmd3) ...
in red DSL shell [cmd1 arg1 [cmd2 someargs] arg3 [cmd3] ...]
the string output that cmd2 someargs and cmd3 return are passed as arguments for cmd1in addition to that every field in the DSL should also be replaceable with a red expression:
mycmd: "command"
shell [:mycmd arg1 :[1 + 3]]
i put the colon there to mark red expressions, but ideally the DSL should figure out on its own whether something is a shell command or a red expression. the two should not be distinct. something along the lines of: let's try if it is red code first, and if not, then it must be shell (since lookups for shell commands are more expensive)that means we need a different separator for a sequence of shell commands. either ; or a line break. unless the command is nested in a red expression:
var: [cmd1 arg --switch arg2] [cmd2 :var]
since we know that var: takes one argument it is clear that only one shell expression can follow. whereas ls -l [cmd1] [cmd2]
would pass both cmds as arguments to ls. if i didn't want that maybe i would write: [ls -l [cmd1]] [cmd2]
or ls -l [cmd1]
cmd2
or some other separator.but if we allow any red expression then the first syntax would automatically be supported. we could not get rid of it even if we wanted to. whereas any other separator would require special consideration.
lastly, in an actual shell/repl shell [ ... ] would be wrapped around every line, so i would not have to write it every time.
these are just some thoughts. handling stderr and return values still needs consideration as well as high level data types. one of the limitations of todays shells is that commands can only pass strings, but i would like for commands to be able to return lists, structs, etc. elvish, nushell and others are exploring that space. one approach is that shell commands can return json that can be converted to native objects. some kind of wrapper for that would be interesting.
i am not actively trying to create a new shell, but i am exploring languages for their potential to design a shell language without having to reinvent the whole syntax from scratch.
red's ability to create powerful DSLs without having to parse everything manually is very interesting here. lisp is the only other language with the same ability that i am familiar with. (TCL too, but TCL doesn't have strong datatypes and that disqualifies it for me) . i think even in smalltalk this would be more difficult than red or lisp.