At Tue, 25 Jul 2017 19:08:02 -0700 (PDT), Thomas Dickerson wrote:
> On Tuesday, July 25, 2017 at 5:52:45 PM UTC-4, Shu-Hung You wrote:>
> > As we can see,
> `scheme_namespace_require(scheme_intern_symbol("racket/base"));`
> > is actually missing from your setup program. This line requires racket
> > base and the usual #%app bindings. It's probably needed even if you're
> > loading your own DSL -- I suspect at some point racket/base will
> > install the right `load` function to make things work, and that this
> > will also affect loading custom #langs.
>
> You appear to be correct, but it strikes me as really odd that
> (a) In a language which prides itself on metaprogramming, the interpreter
> namespace needs to be manually bootstrapped with a specific module.
> (b) That the form the error takes is not an error with the requires/provides
> in the `main.rkt` for my #lang, but as an error in a module which is using it.
I think the root problem is that you're thinking of `load` as
`dynamic-require`, but those are different. The `load` function,
including its C wrapper `scheme_load`, loads a top-level sequence of
forms in the top-level environment. For that to work, the top-level
environment needs to be populated with bindings.
You don't have to populate the top-level environment with
`racket/base`. You could instead use
scheme_namespace_require(scheme_intern_symbol("my-lang"))
where "my-lang" is your language's main module to populate the
environment from there. Still, this isn't really the right direction.
Meanwhile, since the top-level environment was empty, the message
didn't come from the inside of a module. There was no
`#%top-interaction` or `module` binding in the top-level environment,
so nothing in "gpsm-test.gpsm" was parsed as a module. Instead, the
error was attributed to a top-level form in "gpsm-test.gpsm" that could
not be given any meaning in the current top-level environment.
Overall, I think you want to `scheme_dynamic_require` instead of
`scheme_load`, just as Shu-Hung suggests. Using
`scheme_dynamic_require` corresponds to what `racket` does where you
provide it a file on the command line, and it avoids the top-level
environment and `load`.
I can see how the "Inside Racket" example lead you astray by showing a
traditional REPL, where `eval` and `load` come into play, and I'll look
at ways to improve the docs. But if your goal is to run modules, then
you can avoid all that trouble.
Going back to the original message on `++lib`, to add a little to
Shu-Hung's reply:
> I noticed some oddities when using `raco ctool`. For example, the
> documentation claims that a module specified for embedding with ++lib will
> embed all of its dependencies, but my #lang's reader submodule needed to be
> explicitly specified with its own ++lib argument.
A language implementation normally would not depend on that language's
reader. If you have
#lang racket
'hello
(module reader racket)
then the enclosing module doesn't import the `reader` submodule, so it
doesn't depend on it. (If you compile and load that module, then the
`reader` submodule isn't event loaded.)
So, if I understand the situation you're describing, that's why the
reader submodule didn't get pulled along when embedding the outer
module.
--
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
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
