Rationale behind the module paths in definition of the module

Rationale behind the module paths in definition of the module

[Alpha Omega]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I am wondering, what is the advantage of having both the definition of 
the module and the invocation depending
on the module path?

One would think that the path in invocation [i mean  `(use-modules (a 
path to module))' macro invocation],
would be enough. This way, I could differentiate between the modules 
residing under different paths, but
having the same name.

However, hard-wiring a path , e.g,  `(define-module (hard-wired path to 
module))' prevents me from easily moving the
module code around (for example, during `make install').


-----BEGIN PGP SIGNATURE-----
Version: OpenPGP.js v0.5.1
Comment: http://openpgpjs.org

wsBcBAEBCAAQBQJUrk67CRC6Cm7u/wM3RwAAZo4H/0/A05fbuGV/vIAaLMNr
TzuOplLMFQ9eRJZqqwgizcwU/NB/V4IKNwN12Ge+WrgGDFRUkT3x4lqv5xW9
iUlVeC2Y/OWXvs8fzhDUGju7PY8kRYA+f8WkxpOApkJXE9GNfZkhNBeTcRrN
xdUZH32ufbfoknbQxEELgaAJaXmSiaaIcQY+J6wOdwlGAdg4tvuWfuGrJhLi
0YZlNeYv9Rg2m8izQ0llnVH34fVBORp+yfR3kpCPqaOOdUbSnJdlS0sx1XU/
uXtUidwDJvmoVD6ZVusLUjqgsoHKHGqCGtCohK2M3OA8Z8cKLdfUdpn1xGKs
uRFQFjpq2PrmhVCnR2O0LRU=
=JPXp
-----END PGP SIGNATURE-----

Re: Rationale behind the module paths in definition of the module

[Ludovic Courtès]

When a program contains:

  (use-modules (foo bar))

Guile searches for a file named foo/bar.scm (or foo/bar) in its search
path.  The search path is defined by the user, using the GUILE_LOAD_PATH
environment variable etc. (info "(guile) Load Paths").

So the source file of that module, foo/bar.scm, can be moved around on
the file system, as long as GUILE_LOAD_PATH is adjusted to list the
directory that contains this file.

Does that answer your question?

Ludo’.

Re: Rationale behind the module paths in definition of the module

[Alpha Omega]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-01-08 10:17, ludo@gnu.org wrote:
> When a program contains:
> 
>   (use-modules (foo bar))
> 
> Guile searches for a file named foo/bar.scm (or foo/bar) in its search
> path.  The search path is defined by the user, using the 
> GUILE_LOAD_PATH
> environment variable etc. (info "(guile) Load Paths").
> 
> So the source file of that module, foo/bar.scm, can be moved around on
> the file system, as long as GUILE_LOAD_PATH is adjusted to list the
> directory that contains this file.
> 
> Does that answer your question?
> 
> Ludo’.

Hi Ludo',

Sure, I am aware of that.
I am just curious about the decision to embed path info in the module 
file itself.
Perhaps there is something obvious I am missing about its advantages.
It did happen before :) .

The way I see it, without too much in depth consideration, the following
would be preferable,

(my-define-module (x) ...)   ;location agnostic -- the module code does 
not need to know where it is
...
...
...

and then

(my-use-modules (a b c x)) ;client module is the one that has to know 
about
                            ;the location [residing in 
$(SOME_USER_SITE_DIR_ADDED_TO_LOAD_PATH)/a/b/c]

Or, if you want, what is wrong with the CPP approach #include 
<some/.../dir/header.h> and
no hardcoded location info in the header.h itself?


All the best.

A0

-----BEGIN PGP SIGNATURE-----
Version: OpenPGP.js v0.5.1
Comment: http://openpgpjs.org

wsBcBAEBCAAQBQJUrmYZCRC6Cm7u/wM3RwAAGiQH/A5Kh8qqaJY9x3paVgvx
7lqdfUK4stKA9pzjIdD6aCNeru9av+7l785tkkXb5hsSzE1krb3LZJ1JZM1B
RSHMVnEOcqnJF/7WsP6Kf7gwBLGEte2Ndvxd+VramzB1V97oYsLfp+jZv2M8
QQKVitKcquh8uB11PAlpe5Pnl23GF+j5GBLmPNvyE2G8aGNJu+VCsb+JYMSB
iJFxWyrfZq2rFKDYJ+1QLVqQEVR75hU0v0StVO5B4mGtfkPtsPGUIXgL4sNI
H9Ptkpn7yg/5BYeUV5mkugXi1IJ/GM7+xbc1Gyr0cPP6+IN3w2JWjRHpBjVB
Htvs59Z336CdYUOi/0tytBg=
=tUBG
-----END PGP SIGNATURE-----

Re: Rationale behind the module paths in definition of the module

[Taylan Ulrich Bayırlı/Kammer]

Alpha Omega <cape.wrath@openmailbox.org> writes:

> I am just curious about the decision to embed path info in the module 
> file itself.

The '(foo bar baz)' is not path info, it's the name of the module. :-)

The filesystem path mimics the components of the module name.

Taylan

Re: Rationale behind the module paths in definition of the module

[Amirouche Boubekki]

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

I find this surprising too. IMO, it's not useful to declare the file a
module at all.

Similarly having to "export" or "re-export" procedures and variables is not
helpful. Having everything exported by default makes development easier,
even if it can lead to name clash, imports can be renamed. Indeed It's a
detail -- that aligns with how other languages work with modules. That's
said, this can be worked out a project basis by defining some macros.

It's not my top priority "bug", having better traceback would be much more
helpful. I started to look at it without success yet.

On Thu Jan 08 2015 at 12:48:46 PM Taylan Ulrich Bayırlı/Kammer <
taylanbayirli@gmail.com> wrote:

> Alpha Omega <cape.wrath@openmailbox.org> writes:
>
> > I am just curious about the decision to embed path info in the module
> > file itself.
>
> The '(foo bar baz)' is not path info, it's the name of the module. :-)
>
> The filesystem path mimics the components of the module name.
>
> Taylan
>
>

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

Re: Rationale behind the module paths in definition of the module

[Taylan Ulrich Bayırlı/Kammer]

Amirouche Boubekki <amirouche.boubekki@gmail.com> writes:

> I find this surprising too. IMO, it's not useful to declare the file a
> module at all. 

You can have single-name-component modules '(foo)' in corresponding
files foo.scm if you want stand-alone files/modules.

> Similarly having to "export" or "re-export" procedures and variables
> is not helpful. Having everything exported by default makes
> development easier, even if it can lead to name clash, imports can be
> renamed. Indeed It's a detail -- that aligns with how other languages
> work with modules. That's said, this can be worked out a project basis
> by defining some macros.

That sounds like a bad idea.  A top-level definition is not necessarily
part of a public API.  Even C has a solution to this! :-)

Taylan

Re: Rationale behind the module paths in definition of the module

[Alpha Omega]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/01/15 14:46, Taylan Ulrich Bayırlı/Kammer wrote:
> Amirouche Boubekki <amirouche.boubekki@gmail.com> writes:
> 
>> I find this surprising too. IMO, it's not useful to declare the
>> file a module at all.
> 
> You can have single-name-component modules '(foo)' in
> corresponding files foo.scm if you want stand-alone files/modules.
> 
>> Similarly having to "export" or "re-export" procedures and
>> variables is not helpful. Having everything exported by default
>> makes development easier, even if it can lead to name clash,
>> imports can be renamed. Indeed It's a detail -- that aligns with
>> how other languages work with modules. That's said, this can be
>> worked out a project basis by defining some macros.
> 
> That sounds like a bad idea.  A top-level definition is not
> necessarily part of a public API.  Even C has a solution to this!
> :-)
> 
> Taylan
> 

Ok, after reading up a bit on this, i understood the Guile naming
approach is
analogous to the r6rs library standard. Which is fine :) . Oh, and i
love the
possibility to fine grain the import/exporting of names. The module
system
is very similar to that found in the new Fortran varieties, I wonder
where the
inspiration was drawn from in both cases.

A0

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUsQP/AAoJELoKbu7/AzdHF/gH/1UyD0fFvm+k8orrSavwQrNp
eOlGqnzzXj3mL7qjYxcfhP7RCWYqPOelIkOm+0XFG3CjtYBshMs6beYCDnuDJzEv
FYOSgGqYFKA1ETTPO6oquwW7BAd7RxtsVlm4tbVozdFuCFZU6iRrGo7ZKd9xtJS8
PTtm1svDZgg9UALY6NTMnwSwkdU3TFlIb9ln8HTntbqC7RG/H503Wxvau1uyBtgS
dQdeb0Saak7/Ym4JFucTKmRJj3mzoulrYZAzvOfqULg4ctd++lyEGCNoShKSLKmG
NqLdKgFcbRB7202azYBYuFUjY0gns+cwp6PZ/uLhbDKtjH9sB10rpvEwHYO5Hec=
=CjOL
-----END PGP SIGNATURE-----