(use-modules (opencog)) doesn't seem to load scheme files about atomspace

[ngeiswei]

BTW, I've re-added

(load-from-path "utilities.scm")

at the end of opencog.scm. Same thing.

[jswiergo]

Hi. If you use "use-modules" then all variables not exported by the module stay local inside the scope of module. Like a local function variables not visible from outside of the function or private methods in C++.

There are several alternatives:

1. You can export module public variables, for example explicitly add (export stv) inside the utilities.scm or other place within opencog module scope.

2. You can switch into opencog module scope

scheme@(guile-user)> (use-modules (opencog))
scheme@(guile-user)> (define-module (opencog))
$1 = #<directory (opencog) 2409870>
scheme@(opencog)> (stv 1 1)
$2 = (stv 1 0,99999982)
scheme@(opencog)> 

3. Or you can simply use "load-from-path" instead of "use-modules"

scheme@(guile-user)> (load-from-path "opencog.scm")
scheme@(opencog)> (stv 1 1)
$1 = (stv 1 0,99999982)
scheme@(opencog)> 

Maybe this semantics changed between guile versions. Don't know. I checked GNU Guile 2.0.5-deb+1-1.

[linas]

Yes, What Jacek says is right; the current contents of opencog.scm makes an incorrect assumption about exports. The fix would need to be something like (export-everything-in-this-file "utilities.scm") and there must surely be something that already does this, but I don't know where.

[williampma]

An alternative would be to change all "define" in those scm file to "define-public". That should export the functions (mentioned at https://github.com/opencog/atomspace/blob/master/opencog/scm/opencog.scm#L36 )

Might interfere with the cogserver's way to loading however...

[ngeiswei]

As a non scheme expert it seems the right fix is 1. suggested by @jswiergo . I'll proceed unless you have more suggestions.

[ngeiswei]

hmm, core_types.scm uses define-public.

@williampma why do you think using define-public might interfere with the cogserver's way of loading?

Anyway, I still like @jswiergo first suggestion better, it's good to have control over what is public and what is not, and it's better to have that information around the same place in a file.

[ngeiswei]

According to guile's manual define-public is equivalent to export. So if definie-public interferes with cogserver's way of loading so will export (if it's inside the file).

Somehow I can't do

(for-each export <FUN_LIST>)

or

(for-each (lambda (fun) (export fun) <FUN_LIST>)

maybe I'll use define-public instead...

[ngeiswei]

I've come down to the following compromise, in each scheme file that can be used inside a module I define a function that exports all useful symbols and call it in the module definition, for instance I add

(define (export-utilities) (export av stv itv ...))

in utilities.scm. Then add the following in opencog.scm

(export-utilities)

in opencog.scm.

That way I don't create any interference and don't bloat the module definition.

[linas]

Any of these seem reasonable to me. I don't really know what the "best practices" is supposed to be.

[williampma]

Ah, ignore my comment about interference. I just wasn't sure whether define-public will work if the function is not in an module.

[linas]

Closing. The problem as originally described appears to be fixed. I don't quite recall the problem, but using export in a loop seemed to be broken on guile,