[PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

Hello all,

Any objections to adding ".guile.sls" and ".sls" to Guile's default
%load-extensions?  Ian Price tells me that this naming convention is
commonly followed for R6RS libraries and implementations, e.g. Racket,
Mosh, Ikarus, and Ypsilon.  It would facilitate easy use of R6RS
libraries without having to rename the files.  I'm inclined to go along.

What do you think?

    Mark



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions --]
[-- Type: text/x-diff, Size: 1074 bytes --]

From fb87359d058e0810158019cbd958f60fcabcb9bd Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Sat, 3 Nov 2012 23:11:46 -0400
Subject: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions.

* libguile/load.c (scm_init_load): Add ".guile.sls" and ".sls" to
  the default %load-extensions.
---
 libguile/load.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libguile/load.c b/libguile/load.c
index af2ca45..1a03a87 100644
--- a/libguile/load.c
+++ b/libguile/load.c
@@ -1031,7 +1031,9 @@ scm_init_load ()
   scm_loc_load_path = SCM_VARIABLE_LOC (scm_c_define ("%load-path", SCM_EOL));
   scm_loc_load_extensions
     = SCM_VARIABLE_LOC (scm_c_define ("%load-extensions",
-				      scm_list_2 (scm_from_locale_string (".scm"),
+				      scm_list_4 (scm_from_locale_string (".scm"),
+						  scm_from_locale_string (".guile.sls"),
+						  scm_from_locale_string (".sls"),
 						  scm_nullstr)));
   scm_loc_load_compiled_path
     = SCM_VARIABLE_LOC (scm_c_define ("%load-compiled-path", SCM_EOL));
-- 
1.7.10.4

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

If it's semi-standard, we should probably support it too.

However, a Google search reveals the following other uses of .sls:
  - A list of images for a slideshow ("sls" stands for "slideshow script")
  - The backup files for some program callled Litespeed
  - ScriptLab Scripts (seems to be an image generation program)
  - Configuration files for the Salt infrastructure management tool

So we probably shouldn't use it ourselves. (Plus, I personally think it's
uglier than .scm, but that's not a strong argument.)

Noah



On Sat, Nov 3, 2012 at 11:31 PM, Mark H Weaver <mhw@netris.org> wrote:

> Hello all,
>
> Any objections to adding ".guile.sls" and ".sls" to Guile's default
> %load-extensions?  Ian Price tells me that this naming convention is
> commonly followed for R6RS libraries and implementations, e.g. Racket,
> Mosh, Ikarus, and Ypsilon.  It would facilitate easy use of R6RS
> libraries without having to rename the files.  I'm inclined to go along.
>
> What do you think?
>
>     Mark
>
>
>

[-- Attachment #2: Type: text/html, Size: 1579 bytes --]

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> Any objections to adding ".guile.sls" and ".sls" to Guile's default
> %load-extensions?

OK for .sls, but why .guile.sls?

Ludo’.

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Andreas Rottmann]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> Any objections to adding ".guile.sls" and ".sls" to Guile's default
>> %load-extensions?
>
> OK for .sls, but why .guile.sls?
>
This is used for compatibility libraries, for instance:

   % ls spells/filesys/
   compat.guile.sls   compat.larceny.sls  compat.mzscheme.sls
   compat.ikarus.sls  compat.mosh.sls     compat.ypsilon.sls

Only guile will have .guile.sls in its %load-extensions, so it will find
the correct library, in this case corresponding to the library name
`(spells filesys compat)'.

Other R6RS implementations, if the adhere to this convention, will only
consider "their" specific file, as they'd only look for
spells/filesys/compat.sls and
spells/filesys/compat.<IMPLEMENTATION>.sls.  If there's a portable
implementation of that library, it will be under
spells/filesys/compat.sls, and be used (only) if there's no
implementation-specific file. So it's important that the ".guile.sls"
extension is considered *before* ".sls".

For performance reasons, it *might* make sense to not enable this
behavior by default, but provide a command-line switch; however,
enabling this behavior is *already* possible using command-line switches
("-x .guile.sls -x .sls"), so I don't know...

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Ludovic Courtès]

Hi!

Andreas Rottmann <a.rottmann@gmx.at> skribis:

> For performance reasons, it *might* make sense to not enable this
> behavior by default, but provide a command-line switch; however,
> enabling this behavior is *already* possible using command-line switches
> ("-x .guile.sls -x .sls"), so I don't know...

Right.  We’d endup stat’ing two more files for each module, right?

How much of a hindrance is it to *not* have these in the default
extension list?

Ludo’.

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Andreas Rottmann]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> Andreas Rottmann <a.rottmann@gmx.at> skribis:
>
>> For performance reasons, it *might* make sense to not enable this
>> behavior by default, but provide a command-line switch; however,
>> enabling this behavior is *already* possible using command-line switches
>> ("-x .guile.sls -x .sls"), so I don't know...
>
> Right.  We’d endup stat’ing two more files for each module, right?
>
Indeed.

> How much of a hindrance is it to *not* have these in the default
> extension list?
>
Not a hindrance, just an annoyance, IMHO.  Maybe a reasonable compromise
would be to add an --r6rs switch, to add these extensions, as well as
turn on any R6RS-compatiblity reader options, so the script being
executed can use the R6RS syntax we already support, even when it is
disabled by default (cf. my latest patch). On the other hand, these
extensions are not part of R6RS and orthogonal to whether the script to
be run uses R6RS syntax incompatible with the default reader options.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Ludovic Courtès]

Hi,

Andreas Rottmann <a.rottmann@gmx.at> skribis:

> Not a hindrance, just an annoyance, IMHO.  Maybe a reasonable compromise
> would be to add an --r6rs switch, to add these extensions, as well as
> turn on any R6RS-compatiblity reader options, so the script being
> executed can use the R6RS syntax we already support, even when it is
> disabled by default (cf. my latest patch). On the other hand, these
> extensions are not part of R6RS and orthogonal to whether the script to
> be run uses R6RS syntax incompatible with the default reader options.

Yes, but still, a single --r6rs switch seems like a good tradeoff.

Would you like to submit a patch?  :-)

Ludo’.

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:
> Andreas Rottmann <a.rottmann@gmx.at> skribis:
>
>> Not a hindrance, just an annoyance, IMHO.  Maybe a reasonable compromise
>> would be to add an --r6rs switch, to add these extensions, as well as
>> turn on any R6RS-compatiblity reader options, so the script being
>> executed can use the R6RS syntax we already support, even when it is
>> disabled by default (cf. my latest patch). On the other hand, these
>> extensions are not part of R6RS and orthogonal to whether the script to
>> be run uses R6RS syntax incompatible with the default reader options.
>
> Yes, but still, a single --r6rs switch seems like a good tradeoff.

I don't think the command-line switch is a good solution.  The problem
is that even if the main program is not written in R6RS, and even if the
main program does not use any R6RS libraries directly, this option might
still be needed.

Consider this thought experiment: My non-R6RS program uses a non-R6RS
library in Guildhall, so I don't bother with the --r6rs option.
Sometime later, some library (that I use only indirectly) gets upgraded,
and the new version now uses an R6RS library.  Suddenly my program stops
working because I don't have the --r6rs option.

In other words, this policy would force the top-level program to have
knowledge about every module that is ever loaded in their program,
directly or indirectly, now or in the future.

Since it is not realistically possible for a program that uses guildhall
packages to have such global knowledge, it would effectively force all
users to add --r6rs.

I see only two sane options:

* Add these load extensions by default, to enable users and Guildhall
  repository maintainers to easily import R6RS libraries as-is.

* Reject the dominant R6RS library naming convention, and force users
  and guildhall repository maintainers to rename the files to .scm and
  move *.guile.sls to *.scm.

I can live with either of these options, but given the existence of
guildhall, I see no good compromise position.  IMO, we need to make a
decision to either fully embrace or fully reject the R6RS library naming
convention.

     Mark

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Ludovic Courtès]

Hi!

Mark H Weaver <mhw@netris.org> skribis:

> I don't think the command-line switch is a good solution.  The problem
> is that even if the main program is not written in R6RS, and even if the
> main program does not use any R6RS libraries directly, this option might
> still be needed.

Right, good point.

> I see only two sane options:
>
> * Add these load extensions by default, to enable users and Guildhall
>   repository maintainers to easily import R6RS libraries as-is.
>
> * Reject the dominant R6RS library naming convention, and force users
>   and guildhall repository maintainers to rename the files to .scm and
>   move *.guile.sls to *.scm.
>
> I can live with either of these options, but given the existence of
> guildhall, I see no good compromise position.  IMO, we need to make a
> decision to either fully embrace or fully reject the R6RS library naming
> convention.

Yes, makes sense.

Looking at your initial patch, the two extensions were actually searched

My current inclination would be to fully reject it, then.  The problem
is that we’d be adding two stats for each file.

Currently there are two stat(2) for each entry in $GUILE_LOAD_PATH:

stat("/home/ludo/.local/share/guile/site/2.0/ice-9/control.scm", 0x7fff1f4aec20) = -1 ENOENT (No such file or directory)
stat("/home/ludo/.local/share/guile/site/2.0/ice-9/control", 0x7fff1f4aec20) = -1 ENOENT (No such file or directory)
stat("/home/ludo/soft/share/guile/site/2.0/ice-9/control.scm", 0x7fff1f4aec20) = -1 ENOENT (No such file or directory)
stat("/home/ludo/soft/share/guile/site/2.0/ice-9/control", 0x7fff1f4aec20) = -1 ENOENT (No such file or directory)
stat("/home/ludo/soft/share/guile/2.0/ice-9/control.scm", {st_mode=S_IFREG|0644, st_size=2961, ...}) = 0

(I’m not sure if searching for a file name with no extension is
intentional.  Ideas?)

That would double that.

This is likely to become noticeable with large $GUILE_LOAD_PATH values
and/or numerous module loads.

WDYT?

Ludo’.

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[nalaginrut]

hey guys! Should we consider add our specified name, like: .gl or
just .guile?


On Mon, 2012-11-05 at 22:15 +0100, Ludovic Courtès wrote:
> Hi!
> 
> Mark H Weaver <mhw@netris.org> skribis:
> 
> > I don't think the command-line switch is a good solution.  The problem
> > is that even if the main program is not written in R6RS, and even if the
> > main program does not use any R6RS libraries directly, this option might
> > still be needed.
> 
> Right, good point.
> 
> > I see only two sane options:
> >
> > * Add these load extensions by default, to enable users and Guildhall
> >   repository maintainers to easily import R6RS libraries as-is.
> >
> > * Reject the dominant R6RS library naming convention, and force users
> >   and guildhall repository maintainers to rename the files to .scm and
> >   move *.guile.sls to *.scm.
> >
> > I can live with either of these options, but given the existence of
> > guildhall, I see no good compromise position.  IMO, we need to make a
> > decision to either fully embrace or fully reject the R6RS library naming
> > convention.
> 
> Yes, makes sense.
> 
> Looking at your initial patch, the two extensions were actually searched
> 
> My current inclination would be to fully reject it, then.  The problem
> is that we’d be adding two stats for each file.
> 
> Currently there are two stat(2) for each entry in $GUILE_LOAD_PATH:
> 
> stat("/home/ludo/.local/share/guile/site/2.0/ice-9/control.scm", 0x7fff1f4aec20) = -1 ENOENT (No such file or directory)
> stat("/home/ludo/.local/share/guile/site/2.0/ice-9/control", 0x7fff1f4aec20) = -1 ENOENT (No such file or directory)
> stat("/home/ludo/soft/share/guile/site/2.0/ice-9/control.scm", 0x7fff1f4aec20) = -1 ENOENT (No such file or directory)
> stat("/home/ludo/soft/share/guile/site/2.0/ice-9/control", 0x7fff1f4aec20) = -1 ENOENT (No such file or directory)
> stat("/home/ludo/soft/share/guile/2.0/ice-9/control.scm", {st_mode=S_IFREG|0644, st_size=2961, ...}) = 0
> 
> (I’m not sure if searching for a file name with no extension is
> intentional.  Ideas?)
> 
> That would double that.
> 
> This is likely to become noticeable with large $GUILE_LOAD_PATH values
> and/or numerous module loads.
> 
> WDYT?
> 
> Ludo’.
> 

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Ian Price]

nalaginrut <nalaginrut@gmail.com> writes:

> hey guys! Should we consider add our specified name, like: .gl or
> just .guile?

Please don't

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Ian Price]

ludo@gnu.org (Ludovic Courtès) writes:

>> * Reject the dominant R6RS library naming convention, and force users
>>   and guildhall repository maintainers to rename the files to .scm and
>>   move *.guile.sls to *.scm.

Based on Mark's prompting, I have already done this for a number of
existing guildhall packages. In many cases it was pretty simple, in two
particular cases, less so.

> That would double that.
>
> This is likely to become noticeable with large $GUILE_LOAD_PATH values
> and/or numerous module loads.

Hopefully, one of the advantages of using the guildhall would be to
shorten that path. Since libraries would usually be installed in guile's
site directory, or guildhalls one.

> WDYT?
I'd prefer it was added, but I can live with it not being included. At
Mark's request, I have changed existing uses of it in guildhall
packages, so that 2.0.5 users don't need to do anything.

R7RS will probably want its own incompatible convention anyway...

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:
> My current inclination would be to fully reject it, then.

Okay.

> Currently there are two stat(2) for each entry in $GUILE_LOAD_PATH:
[...]
> That would double that.
>
> This is likely to become noticeable with large $GUILE_LOAD_PATH values
> and/or numerous module loads.

Yes, I worried about this too.  Even now, the number of stat calls is
unfortunate, especially for people who extend their %load-path.

For Guile 2.2, it might be worthwhile to consider ways to reduce the
expense of loading modules, and if so, maybe we can revisit this
question later.

One option would be to return to Aubrey Jaffer's model (used in SCM),
where a catalog of modules and their locations is maintained and must be
explicitly rebuilt when software is installed.  Optionally, if the user
attempted to load a module not found in the catalog, we could fall back
to an explicit search, and if successful, issue a warning with a
reminder to rebuild the catalog.

Alternatively, on systems that support inotify (or something like it),
we could construct this catalog during initialization and efficiently
keep it up-to-date by receiving notifications when changes are made to
the relevant directories, or when %load-path is changed.

> (I’m not sure if searching for a file name with no extension is
> intentional.  Ideas?)

I looked into this.  Guile has searched for file names with no extension
since its initial import into VCS in 1996 (0f2d19dd).  Initially, names
with no extension were searched _before_ *.scm, and this logic was
hard-coded into the search procedure (try-module-autoload in
boot-9.scm).  Jim Blandy introduced the '%load-extensions' variable with
default value ("" ".scm") later in 1996 (26544b96), and Mikael Djurfeldt
reversed the order to (".scm" "") in 1999 (0a74e31d).  It has been that
way ever since.

     Mark

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Ludovic Courtès]

Hi!

Mark H Weaver <mhw@netris.org> skribis:

> One option would be to return to Aubrey Jaffer's model (used in SCM),
> where a catalog of modules and their locations is maintained

Hmm, I never really liked that.  And it’s quite an uncommon model.

>> (I’m not sure if searching for a file name with no extension is
>> intentional.  Ideas?)
>
> I looked into this.  Guile has searched for file names with no extension
> since its initial import into VCS in 1996 (0f2d19dd).  Initially, names
> with no extension were searched _before_ *.scm, and this logic was
> hard-coded into the search procedure (try-module-autoload in
> boot-9.scm).  Jim Blandy introduced the '%load-extensions' variable with
> default value ("" ".scm") later in 1996 (26544b96), and Mikael Djurfeldt
> reversed the order to (".scm" "") in 1999 (0a74e31d).  It has been that
> way ever since.

Woow, thanks for digging it up.  Now we should find out what these guys
had in mind *before* Guile was first put under version control.  ;-)

Anyway, I still don’t know what to do with .sls.  But the fact that R7
may come up with its own extension makes me think that maybe we should
just forget about that extension, as everyone will eventually do.   Hmm?

Ludo’.

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Alex Shinn]

On Thu, Nov 8, 2012 at 5:28 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi!
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> One option would be to return to Aubrey Jaffer's model (used in SCM),
>> where a catalog of modules and their locations is maintained
>
> Hmm, I never really liked that.  And it’s quite an uncommon model.
>
>>> (I’m not sure if searching for a file name with no extension is
>>> intentional.  Ideas?)
>>
>> I looked into this.  Guile has searched for file names with no extension
>> since its initial import into VCS in 1996 (0f2d19dd).  Initially, names
>> with no extension were searched _before_ *.scm, and this logic was
>> hard-coded into the search procedure (try-module-autoload in
>> boot-9.scm).  Jim Blandy introduced the '%load-extensions' variable with
>> default value ("" ".scm") later in 1996 (26544b96), and Mikael Djurfeldt
>> reversed the order to (".scm" "") in 1999 (0a74e31d).  It has been that
>> way ever since.
>
> Woow, thanks for digging it up.  Now we should find out what these guys
> had in mind *before* Guile was first put under version control.  ;-)
>
> Anyway, I still don’t know what to do with .sls.  But the fact that R7
> may come up with its own extension makes me think that maybe we should
> just forget about that extension, as everyone will eventually do.   Hmm?

FYI, there is currently no convention, and the design of
Snow (the library sharing network) does not require any
specific extension (you create and work with packages
which are self-describing via meta-info).

However, for third-party tools it may be convenient to
have a common convention.  Currently Chibi uses .sld
(Scheme Library Definition) to distinguish from R6RS.
These can inline the entire library definition, or use
include files (again, since you specify the filename any
extension will do, and Chibi uses the traditional .scm).

-- 
Alex

Re: [PATCH] Add ".guile.sls" and ".sls" to the default %load-extensions

[Andreas Rottmann]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> One option would be to return to Aubrey Jaffer's model (used in SCM),
>> where a catalog of modules and their locations is maintained
>
> Hmm, I never really liked that.  And it’s quite an uncommon model.
>
>>> (I’m not sure if searching for a file name with no extension is
>>> intentional.  Ideas?)
>>
>> I looked into this.  Guile has searched for file names with no extension
>> since its initial import into VCS in 1996 (0f2d19dd).  Initially, names
>> with no extension were searched _before_ *.scm, and this logic was
>> hard-coded into the search procedure (try-module-autoload in
>> boot-9.scm).  Jim Blandy introduced the '%load-extensions' variable with
>> default value ("" ".scm") later in 1996 (26544b96), and Mikael Djurfeldt
>> reversed the order to (".scm" "") in 1999 (0a74e31d).  It has been that
>> way ever since.
>
> Woow, thanks for digging it up.  Now we should find out what these guys
> had in mind *before* Guile was first put under version control.  ;-)
>
> Anyway, I still don’t know what to do with .sls.  But the fact that R7
> may come up with its own extension makes me think that maybe we should
> just forget about that extension, as everyone will eventually do.   Hmm?
>
Putting my dorodango hat on, Guile currently provides all mechanisms to
make use of the .sls convention.  A potential --r6rs option seems like a
misnomer to me, due that it would implement an informal convention, not
something really specified in R6RS.

If such an option (maybe under another name) would be added, it would be
effectively just an abbreviation for the right -x command-line options.
Thus it is insignificant to dorodango, since it has to install a
launcher shell script for each program anyway, and whether that shell
script can become a few characters shorter doesn't matter.

What is (relatedly) *indeed* lacking is a way to make native libraries
take precedence to the third-party libraries installed by dorodango.
This would be addressed by making the $GUILE_LOAD_PATH (and
$GUILE_LOAD_COMPILED_PATH) mechanism to not only prepend, but also
append to the compiled-in load path, as implemented by the patch I
posted [0].

[0] http://lists.gnu.org/archive/html/guile-devel/2012-11/msg00056.html
-- 
Andreas Rottmann -- <http://rotty.xx.vu/>