Replies: 2 comments 1 reply
-
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
New idea: no more difference between single and double quotes. Instead, we just have a |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
We could also have some of that functionality by having format string that would look something like this:
That way you could still have the option to use that to have more seamless concats. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have been thinking a lot about this and I wanted to organize my thoughts on the matter into one discussion, so here it is.
Preamble
One of the fundamental reasons that I created this project is that I had quite a few concerns about POSIX and POSIX-adjacent syntax (read: Bash syntax and its predecessors/derivatives) and I felt that it could be improved. Contemplating this, I came to the realization that Bash syntax is terrible because of at least one major reason: the language aimed to provide functionalities in such a way that they are convenient to use in both scripting and in interactive sessions, and I believe that in doing so, it failed at both objectives.
Scripting & Interactive Features
Realizing this, I planned to separate the interactive "language" and the scripting language from each other; additionally, instead of implementing a custom scripting language, which seems to be the prevailing maneuver (see Fish, Nushell, etc.), I would use one of the many excellent general-purpose scripting languages that already exist as the "native" language for shells scripts. This left me with an interesting dilemma: what should the limitations of the interactive language be? Where should I draw the line to say "scripting is to be used beyond this point"?
The main feature typically found in scripting languages which I knew I did not want to implement was control flow. CLI users almost never need to use
if,while,switch, and so on. The logical operators&&and||do provide a modicum of control flow which I find to be acceptable. But are substitutions important? What about variable access? Should everything be a string or should we implement some sort of typing system? I'm really not sure. This is one of the main aspects I wanted to get feedback on.Syntax
There is a lot of baggage attached to POSIX syntax. I don't think POSIX is the only standard responsible for this, either. Here is a mostly-exhaustive list of the syntactical pain points which I will be referring to in this section.
Some of these features seem to be mostly relegated to shells, though many have taken root in some form in other software. Though I think these syntax features could be drastically improved, I do also recognize that if we are to write this shell with new users in mind, there could be a disconnect between the syntax they learn for the shell and the syntax which is generally accepted in other programs. Put more succinctly, I don't want to set people off on the wrong track. However, for more experienced users, there seems to be a lot of merit to breaking from conventions which were not particularly well-thought-out.
Without further rambling, I'd like to list a few ideas which I have considered adding, all of which relate to syntax but some of which are not syntax features themselves.
Reverse Escapes
The thing that irks me about escapes and special characters is that the
'\'character serves two contradictory purposes: firstly, it can "escape" any syntactical significance of the character immediately following it, and secondly, it can imbue said character with special significance, such as is the case with'\n'and'\t'. It may be a good idea to separate these two, though which characters I will use as a replacement, I am not quite sure. The obvious ploy would be to use'/', but unfortunately it is already used for paths, so I don't think it would be good to give it syntactical significance. A better idea would be something like'['and']', as these characters are not used in natural language grammar. I am open to ideas, though.Style Codes
ANSI sequences are poorly-documented, hard to remember and type, and aren't even a real standard, for the most part. Because of this, I thought it would be nice if we could have a shorthand system for these codes using some simple syntax, similar to how Minecraft uses the
§(or often&) for colorizing chat messages.Redirect Postdefinitions
Redirect syntax seems simple enough, until you get into some of the more complex operations, where it becomes relatively difficult to read. I thought we could have some way to postfix a chain of commands with the redirects you wish to use, using some sort of placeholder system, similar to the
format!()macro. I have no idea how this would look, but feel free to give me ideas.Modal Input
This is by far the most interesting idea, in my opinion. If one of our goals is to make a mini-language which is tailored entirely to interactive use-cases, what is to stop us from implementing features which are bound to interactive sessions in order to streamline the experience?
The idea of modal input is that, instead of writing quotes around everything, and using escapes and special syntax for certain keys, you could instead use a keybind to toggle/switch modes, where one mode is used for syntax-aware input and another is used for literal input. The literal mode could interpret
ENTERkeypresses as line breaks, andTABkeypresses as tabs, and so on and so forth. There could also be keybinds which allowed you to auto-escape input, such asSHIFT+SPACEand such. Color/style formatting could serve as optional indicators of literal and syntax-aware portions of the line of input.I'm not entirely sure the exact form this would take, but it's an interesting idea nonetheless.
Conclusion
Please let me know what you think. Thanks for reading through this, if you've gotten this far.
Beta Was this translation helpful? Give feedback.
All reactions