Using CreateGlueToC without a shell

[AlaskanEmily]

I'm trying to understand why using CreateGlueToC requires a shell (as it's behind a #if (!defined(PF_NO_INIT)) && (!defined(PF_NO_SHELL))). This seems like a fully embedded usage couldn't also have exposed C/C++ functions. Is there a reason this is the case?

[philburk]

Good question.

I think the CreateGlueToC() function is only needed when compiling the initial custom C code.
Once it is compiled then you should be able to make a TURNKEY dictionary, or a static dictionary,
that can still execute the custom code.

The second compilation of the pForth kernel should be able to use PF_NO_SHELL and then run the turnkey dictionary.

[AlaskanEmily]

OK. I had not realized that the C functions were described by the dictionary.

My original idea was to use pforth embedded in a program where extra C functions are not actually known at compile time. A series of plugins would be dlopen'ed/LoadLibrary'ed, and then a list of functions would be enumerated and added at program start. Does this mean that situation require the dictionary to be recreated whenever the set of plugins changed?

[philburk]

A series of plugins would be dlopen'ed/LoadLibrary'ed,

You could use the custom C functions to call dlopen, dlsym, etc.
You could also have a custom C function that pulled the parameters off the stack and then called the raw function pointers.
You could do all this without dictionary headers.

and then a list of functions would be enumerated and added at program start.

You could define an AUTO.INIT function that called the plugin loader.