2024年5月5日(日) 13:36 Matheus Afonso Martins Moreira <math...@matheusmoreira.com>: > > If your purpose is just to solve a small inconvenience of the `source' > > builtin mixing the namespaces of local scripts, "libraries", and > > executables, I think the suggested `source -i' or `source -l' would be > > fine. I think no additional reasoning is needed. > > That is my purpose!
OK. > My solution to the file extensions problem for example is to > just not have file extensions at all, This is not normal. I think that is the source of your problem. Even though it is not strict, executable files (including shell scripts intended to be executed in a separate process) in PATH usually do not have the filename extensions. On the other hand, the scripts files intended to be sourced would typically have a filename extension of .sh or .bash (or even double extensions such as `.theme.sh,' `.plugin.sh', and `.alias.sh' depending on the type of the module. In this way, the namespace of the script files to be sourced and executable files are "roughly" separated. Of course, it is not strict and users can still have an executable script with a filename extension. In some cases, we would have a set of script files to be sourced without extensions, but those script files are usually intended to be managed by a specific module manager/loader that resolves the path by itself (such as /examples/functions/autoload and bash-completion _comp_load). Nevertheless, this makes the proposed change less convincing more or less..Do you think you submitted the patch if you would have had script files with filename extensions from the beginning? If you followed the typical arrangement of script files to be sourced, the problem you faced shouldn't have been that serious. > > However, in that case, I don't see much difference from > > « PATH=<modpath> source » (as far as the module just defines a set of > > functions). > > It's true that the code is more or less the same from the perspective > of module managers. However, building this into bash does provide > a subtle benefit: separation between executable and module paths. > > Chet Ramey outlined it in his email: > > No need to ensure that they'll not attempt to run external commands. > The builtin is therefore less limited than a pure PATH solution. Yes, but that's implied my phrase ``as far as the module just defines a set of functions''. In case, I note that the functions defined in the sourced script files can call external commands after the sourcing completes because the shell function uses "the value of PATH of the current dynamic context" but not "the value of PATH when the function is defined". Anyway, I agree it is a problem that the sourced script cannot call the external commands if the script wants to do actual processing (such as initializations) instead of just defining a set of functions and variables. Nevertheless, it is technically possible to implement the proper identification of the script file in a shell function with a few dozens of lines, though it wouldn't be a single line implementation. > This would be most useful for a module manager that doesn't resolve > the module path by itself. I still don't think it is useful as I already wrote in the previous reply. I don't think there is a demand to reduce a few lines or a few dozens of lines from the module manager. Also, the benefit in the module manager seems too specific. Not many people try to implement the module manager. The language wouldn't be designed solely for module managers. The module managers could be an important piece of a language, but that's not all the important aspects of a language. If you were a developer of a module manager and faced a serious problem in implementing it, which is impossible to solve with an existing language feature set, the feature request would have been understood. However, you just seem to raise this example as a hypothetical project, which seems hardly convincing. > I agree that a one line of code reduction is underwhelming > but that's not the only reason to include it. The users are the > main beneficiaries. This gives users a simple way to load > modules without using any module managers at all. > From the perspective of the user, it potentially reduces > thousands and thousands of lines of code. I'll reply to it in a corresponding thread by Lawrence. > Still, I did and still do hope that it will make life easier > for the maintainers of the module managers too. If you still hope that, I believe your patches would be blocked until we test the design by the actual implementation of module managers based on it and show it's validity. Furthermore, I think it wouldn't get into Bash because I don't think it's possible to show it. This feature is simply unnecessary for module managers. Sure it might be used to reduce a small amount of code, but it's not an indispensable feature. It's not sufficient to justify the change. > > Would you try to exclude the possibility > > of a module manager in the future of Bash? > > Certainly not! It is not my intention to exclude them. > > I just think that they should all use the same interface. > > My idea is that both interactive users and module authors > would write `import x` in order to bring in a dependency. > Alternatively, they would write `source --library x`. That's strange. If you expect the same interface from the module managers, the module managers cannot have any changes in the behavior from your `import'. That means that the module managers are required to be just a thin wrapper of yours. You are effectively excluding module managers however you rephrase it. If you try to force a single true interface for all the module managers, then again we'll have to start the discussion about the standard module manager of Bash. You need to carry out a survey on the existing module managers, sort out the useful/needed features, form a lowest common multiple of a feature set, and convince people. It would be hard. > They could solve the file extension problem with symlinks: > create extension-less and .sh symbolic links pointing to > the .bash module file. Perhaps that could work. That seems like just a hack, yet a module manager can technically do that as an option. I wouldn't do that for my module manager because we can implement it without using such a thing. The suggested feature seems still merely an unlikely option that a module manager can technically use but wouldn't practically use. > Having uniform interfaces is exactly what allows > the implementation to be swapped out later > without touching existing code. I don't think just having uniform interfaces is enough. What if such a "uniform interface" is not useful for the suggested purpose at all (and I think it is the case for the present suggestion)? If just a uniform interface is enough and do not need to cover existing needs, then the current `source' builtin is actually the uniform interface. > Anyway, that's what I had in mind when I wrote all these emails. > It might turn out that it's impossible to implement things that way. > It could also be that it is possible but simply too painful to do it. > Maybe there are too many existing systems and changing them all > would be a monumental effort. In that case it can't be helped and > I'll just accept it. I'll just be happy that `source --library` was > considered. > I don't have any intention of excluding anyone at all. OK, so the above discussions are actually your consideration in the past. > > If you start to talk about the vision about the Bash language, that > > would certainly raise the bar. You'll have to tell a story about how > > the flag `-i' or the import builtin changes the language in detail > > using a concrete example of an ecosystem and why it is the best > > approach among other different possibilities. > > To that end, I described in this reply the exact use case I have > which inspired this proposal and patch. What you described is just a plan. By "a concrete example", I mean an actual implementation of a module system needed to gauge the "vision" and practices with it. There are many things that can be learned while implementing, testing, and practicing it, including possible problems or conflicts and additional useful features that were not obvious before implementation. I don't think you learn nothing at all in writing codes and using the codes. You also didn't show any comparison with other possibilities, including the design of existing other module managers, etc. If one tells a vision, I expect, for example, the list of known features, the list of known problems, etc. and careful design addressing all the points.
