Is there anyway for us to look up symbols of one module like Python dir(object) to look up the attributes (methods and attributes)

[APIPLM]

Is there anyway for us to look up symbols in REPL in one module(,m r5rs) ,and like Python dir(object) to look up the attributes (methods and attributes)? Seem like there is an egg apropos to help out. But as I installed it. It is more like emacs-symbolist to look up symbols present in the currently running REPL session. For instance, call-with-port is in the module r7rs in chicken implementation, But after import r7rs, whichever module (,m r5rs or ,m r7rs)are you in, they always check with symbols by ,a call-with-port in the module r7rs .

[jcubic]

I'm not sure about other Scheme implementations but in LIPS (my scheme) I've added apropos, dir, and help also the user has access to internals and the environments are first-class objects. I've added this because I always liked how Python exposes everything to the user.

But I'm not sure how much possible is to add those to a compiler, a lot of scheme implementation just compile the code on the fly and then evaluate the results and don't expose internals.

[APIPLM]

egg apropos is so cool. but in the environment like r5rs,r6rs to look up the symbols, that is not what it can do.
If that. Is possible that in geiser? I guess that it is also maybe a lot work to do in geiser for that. Maybe the easy way to have r5rs environment is that building the image of docker with the r5rs source.

[lassik]

Geiser can only do it if the Scheme implementation can do it.

• Chez Scheme has (library-exports '(rnrs bytevectors))
• Gauche: see Module introspection in the manual
• Other implementations probably have something too, but there's nothing standard.

[lassik]

The Chez Scheme API is decent. It would be good to standardize in a SRFI.

@jcubic is right that when compiling Scheme code, the compiler may throw away the information needed to query the libraries, but in the REPL it should work in all Scheme implementations.

[APIPLM]

Other implementations probably have something too, but there's nothing standard.

That is why I said that building the docker image with source code with an additional module to looking up symbols for the modules in the implementations is reality now. Having a SRFI to standardize would be great.

[lassik]

Maybe the easy way to have r5rs environment is that building the image of docker with the r5rs source.

Few Scheme implementations provide a R5RS mode with nothing extra. Most of them add:

• a module system
• exception handling
• keywords
• etc.

I don't know which implementation is closest to R5RS with nothing else.

[lassik]

That is why I said that building the docker image with source code with an additional module to looking up symbols for the modules in the implementations is reality now. Having a SRFI to standardize would be great.

An easier way to do that might be to parse the source code of the implementation. Scheme code is easy to parse.

[lassik]

Here's a dir() for Chibi and Gauche.

[APIPLM]

thanks

[APIPLM]

Yes. That is a correct implementation for people to go with. In Chicken, from toplevel module perspective, the user in REPL to evaluate an expression, which invoke the procedures, and the .so file with that procedures as an exported procedures should be loaded first. That means that we are in loading binary so file to execute. From this point, there is not a way for us to look up these symbols (specially procedures) any more from Toplevel module perspective as these dependence symbols in binary so file.Although,we can strings *.so to look up the symbols, that is another story. I supposed the concept of Toplevel module in Chicken is similar to .el file of elisp in Emacs. What the user in Chicken to do programming in toplevel module (scm scripts) actually like the user do programming in the .el file of elisp in Emacs. She/he can look up the symbols as the script have been built, and the exported symbols of all those dependence scripts as well. then they can be built into one image. So from this point, I think that it won one point. The Chicken sound like need it, too. The egg apropos in Chicken mostly like Diagnosis tool, after loading one *.so file by (import (chicken name) , and the symbols in the loaded so files are available in the current session.

[lassik]

SRFI 17 and 28 are built into Chicken. They don't have their own source files (or .so files) because they just re-export procedures from other libraries. Search for srfi-17 and srfi-28 in modules.scm and you will find the definitions.

[APIPLM]

One more thing is that in Python3, there is one module inspect , which import the source of the module( import the third-party module , NOT built-in module), then look up inside the methods and class of the module. I mean that we can implement this approach in the third-party eggs in chicken and other implementation as well if it is necessary.

[APIPLM]

For instance, In Chicken ,we can inspect the source code of exported symbols in the module of the egg

[jcubic]

in Python, it's easy because AFAIK in Python everything is the first-class citizen including modules, classes, and meta classes. In Scheme, you will need to write a static code analyzer unless implementation provides a mechanism for inspecting things.

[lassik]

Every Scheme REPL knows about all the libraries and what they export. We just don't have a standard API to ask the REPL about those things.

[lassik]

AFAIK Scheme libraries are not first-class objects in most implementations, but they could be. RnRS allows that.

[APIPLM]

@jcubic static code analyzer, like JS, c and c#, they have this concept, which is that before you submit the source code to the repo, those source code should be passed by scanning tool for static code analyzer. But in Scheme, sound like that there is not this concept, you wrote scheme code, which is all kind of forms, those forms is accepted by the compiler, then that is.
@lassik Scheme REPL know about the libraries and what they export, like you did the source file in your repo . And also in Chicken, the .lib/chicken/11 lib folder also have the modules.db and types.db files for built-in modules list and the exported symbols. Sound like in Scheme, it is like C-styles, which is one module (one .so file ) with its exported functions. For the internal functions, it is an other story in term of inspecting internal functions in one module.

[APIPLM]

I was thinking about the boundary, which is that for instance, the spiffy egg has dependence on srfi-1, and also Chicken built-in mini-srfi-1.scm. It sounds like have two revision of srfi-1, Do we need two revision implementations for srfi-1?

[lassik]

There are two levels:

• The library/module level (in Scheme, the words "library" and "module" mean the same thing). For example, (import (srfi 1)) imports the (srfi 1) library. The Scheme forms (library ...), (define-library ...), and (module ...) make libraries.

• The package level (in Chicken, packages are called "eggs"). A package is a collection of libraries. Packages tell the Scheme implementation where import can find libraries.

Chez Scheme has APIs like library-list and library-exports, which work on the library/module level. These could be standardized Scheme-wide in a SRFI.

The package level isn't as easy to standardize, but we should try anyway.

[lassik]

spiffy.egg says (dependencies ... srfi-1 ...) which probably means that it requires the srfi-1 egg. But that could be changed to any other egg that provides a working (srfi 1) library.

[APIPLM]

Sound like that in order to support library-list and library-exports in library/module level, it needs to open the more APIs in the low level. In Chez Scheme, it has like this (define (scheme? x) (eq? (#%$sgetprop x '*scheme* #f) x)), $getprop like the c level function. it is from the primvars.ms file in the ./ChezScheme/mats source.

In the package level, Maybe phpDocumentor is the way to go, which that the source code as the input to generate the document for the people to look up .The package level is in the document level. Although, in library/module, they still can look up the modules/functionalities,methods/classes in REPL. But that is for the debug and performance.