William ML Leslie <william.leslie....@gmail.com> writes: > For most entry-points, there is no extension. When you install your > program, you normally install it as /usr/bin/foo, rather than > /usr/bin/foo.[ss|scm|py|js|whatever]. This is the motivation for > guile-foo symlinks or --lang options. I favour the symlinks slightly, > because not all languages are going to work with guile's extended > mesh-wow system, and indirection via env already costs you one > argument.
Yes, and in the hoped future when Guile runs Python better and faster than any other implementation, we certainly need the symlinks so that someone can do # cd /usr/bin && rm python && ln -s guile-python python to let Guile run all existing Python programs on their system. Then, clearly, "guile-python" needs to handle all the command line arguments that are traditional for Python - not the traditional Guile arguments - and munge them into a suitable startup incantation/sequence for Guile. And then there are two detailed arguments which both suggest handling "guile-python" within the main Guile executable, instead of in an accompanying shell script. Firstly it's more flexible to transform guile-python arguments directly into Guile startup code, instead of a two step transformation first to traditional Guile arguments and then to code. (What if there isn't an appropriate traditional Guile argument?) Secondly it feels more maintainable and integrated to have that logic within the main Guile code, instead of in a shell script to one side. I think that means the necessary support should be added to compile-shell-switches in (ice-9 command-line), and to the C code in script.c that calls that, to allow compile-shell-switches to set up for different languages according to $0. Regards, Neil