So, basically, I was wondering how one could go about requiring modules in 
/usr/share/racket/collects from the embedded interpreter.

My current program links against a base.c file generated with raco ctool 
base.c ++lib racket/base and simply runs REPL, it's essentially copied from 
the Racket documentation that provides the same example:
int interpreter_run(Scheme_Env* env, int argc, char* argv[])
    // set default collects path 
    // declare racket/base modules

    // require racket/base namespace

    // require REPL symbols
    Scheme_Object* symbols[2];
    symbols[0] = scheme_intern_symbol("racket/base");
    symbols[1] = scheme_intern_symbol("read-eval-print-loop");

    // dynamically require function from racket/base
    Scheme_Object* func = scheme_dynamic_require(2, symbols);
    // invoke REPL
    scheme_apply(func, 0, nullptr);
    return EXIT_SUCCESS;

However, I have a few questions about this. Must all modules that one wants 
to require be stated when doing the previous raco command (++lib)?
I'm not certain about the effect of doing *scheme_set_collects_path* 
actually has in relation to how collections are required.

For example, from my REPL example:

> > $ ./racketeer                                                           
> > (find-system-path 'collects-dir)
> #<path:/usr/share/racket/collects>

Evidently it successfully sets the collection path.
However, the context trace of attempting to require anything else from the 
REPL example seems to completely omit this.


> > $ 
> ./racketeer                                                                
> > (require racket/base)
> > (require racket/gui)
> stdin::32: collection not found
>   for module path: racket/gui
>   collection: "racket"
>   *in collection directories:*
>   context...:
>    show-collection-err
>    standard-module-name-resolver
>    /usr/share/racket/collects/racket/private/misc.rkt:88:7
> > (find-system-path 'collects-dir)
> #<path:/usr/share/racket/collects>

It fails to require racket/gui and doesn't show any collection directories 
at all. Is 'collects-dir completely separate from what the interpreter 
actually uses to load modules from collections? If so, would I need to 
register a proper collections directory prior to scheme_main_setup? From 
what I can tell, it can only successfully (require racket/base) because it 
was - for lack of accurate terminology - *compiled in* via raco's ++lib 
option. Would that be a correct assumption to make? 

My overall intention is to be able to do what racket's REPL can do from 
command line, given a folder structure like this:

> > $ tree 
> something                                                                     
> something
> ├── compiled
> │   ├── main_rkt.dep
> │   ├── main_rkt.zo
> │   ├── other_rkt.dep
> │   └── other_rkt.zo
> ├── main.rkt
> └── other.rkt

Racket, from command line, ran from that the containing folder, can 
(require something):

> $ 
> racket                                                                     
> Welcome to Racket v6.12.
> > (require something)
> > (useless-func)
> Useless function

Yet, my REPL example can't do this but I suspect there's probably existent 
scheme_* functions to do this (I seen one call something like 
scheme_set_cmd and people pass argv[0] to it).
I just think it'd be useful to be able to dynamically require modules the 
embedded interpreter but I can't seem to get it to work at all. I've 
dabbled with things like dynamic-require and such, but due to my blatant 
lack of understanding of how modules and collections are meant to work, 
it's all just fell flat.

Any clarification on anything I've posted about would be much appreciated 
as I'm currently going around in circles and manually purging files 
generated by raco in a futile attempt to understand what's happening. 
Out of interest, is it even possible to embed the Racket interpreter for 
the purposes of interoperability? I've not seen anyone do it and the 
documentation for scheme_* functions is sparing, to say the least. It seems 
to me the only way to achieve interoperability would be to wrap C that 
utilises native IPC to communicate with the intended application and then 
load and execute the wrapper.

Sorry if my question is terribly unstructured or makes false assumptions or 
assertions, I only started digging into Racket - and Lisp dialects overall 
- recently.
As I say, any clarification on anything I've brought up would be much 


You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to