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.