Re: Re: Re: Re: [PATCH 0/4] Add import builtin

[Koichi Murase]

2024年5月5日(日) 13:36 Matheus Afonso Martins Moreira <matheus@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.