-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inline annotations #453
Comments
That is a great idea! A thought: To start quickly (and avoid implementing a parser), we could just make a few ## pash_stateless could be a `nop` function where
## its first argument indicates the following command's inputs,
## and the second argument indicates the following command's outputs.
pash_stateless stdin stdout grep ...
## or
pash_pure args[:] stdout sort ... |
This is a great idea. My only (minor) worry is that if this script is not executed by PaSh, but rather by bash or zsh, it would break. A cool feature of annotations (both as JSON or comments) is that they live "on the side", not interfering with the normal execution of the script (a script that could, for example, be |
That is true, however, it could be easily solved by sourcing a If parsing is simple, we should go straight to it :) |
This is a great idea! (Reading your message I also realized you're talking about the simplest way to get started whereas I was talking about something closer to the final design — so I fully agree with you!) |
I see two options that keep compliance: (1) use environment variables, e.g., |
In the same vein like this, we could configure other PaSh related stuff too like this (like |
Yes, agreed! I think the |
There are cases when a user might want to provide an annotation for a custom command or even override (force) a behavior on an existing command. In these cases, writing a full JSON in a custom directory is inconvenient. A more convenient approach would be to provide an inline annotation, which PaSh could read and expand appropriately during its pre-processing stage:
Most annotations will fall under a few distinct categories, and thus expressiveness can be optimized towards the common case—after all, developers can always fall back to the JSON for the full expressive power of the annotation subsystem. This infrastructure and associated annotation economy may accelerate research in annotations.
The text was updated successfully, but these errors were encountered: