|
|
|
|
|
|
by klibertp
30 days ago
|
|
|
I had a bit of back-and-forth with ChatGPT about the possible implementations[1] - it shows how little I know about Red, unfortunately, but we came to this representation: shell [
var: [cmd1 arg --switch arg2]
[cmd2 :var]
]
as a general shape of the DSL. The need for a separator goes away (and simplifies the grammar a lot) if you require commands to be nested blocks. :var works for interpolation, because it's loaded as get-word! - trying to cram $var there wouldn't work (that's a syntax for `money!` - only digits are accepted after `$`), but if you want A shell, not BASH specifically, I think you can get away with some syntactic changes. I checked some of the things the model proposed in the REPL, and they mostly seem to work. Subshells and piping would probably require more work in this setup, but it should be doable.Again: really interesting language and seemingly a good fit for an internal shell DSL. It's also trivial to make files written in this DSL execute as scripts. I might have jumped the gun a little with my "why would you" question at the start :) Personally, I would still seriously consider Io, but that's just a familiarity bias: I spent a year hacking Io internals, while I know little about Red. [1] https://chatgpt.com/share/6a469cbb-1754-83eb-94b8-14bef67735... |
|
|
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:
in red DSL 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:
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:
since we know that var: takes one argument it is clear that only one shell expression can follow. whereas would pass both cmds as arguments to ls. if i didn't want that maybe i would write: or 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.