@dan.ml.901 Probably (current-load-relative-directory dir). For belt+suspenders, maybe also (current-directory dir).

Hmm, although that would probably work for "b.rkt", not sure for "a/b.rkt".

If you’re dynamic-requiring a file that has those paths, then I don’t think a parameter will work, because the process of loading the file will shadow the parameter settings. But you can read-syntax the file content, then the current-load-relative-directory parameter parameter will affect eval of the syntax object. See also with-module-reading-parameterization and check-module-form.

Oh right, I’ve used c-l-r-d e.g. in racket-mode with things like module->namespace.

What about parameterizing current-eval to be a function that parameterizes current-load-relative-directory around a call to the previous current-eval? Is that a clever way to let other things still use dynamic-require, or, a horrible hack?

I wouldn’t recommend that. :slightly_smiling_face:

yeah, I’ll be dynamic-requiring files that have those paths (which in turn require in other files that have those paths … and so on.

is using read-syntax on the contents of the root file similar to dynamic-require? I’ll still need to do something to extract the require-spec I need ((submod (file "root.rkt") <identifier>)).

Use read-syntax plus eval with both current-load-relative-directory (to control path resolution) and current-module-declare-name (to control the declared module name) set. Then you can dynamic-require with submod around the name that you used in current-module-declare-name.

ok, I’ll give that a try

hmm that goes into some sort of infinite loop in the read-syntax or the eval

unless I’m using currentmodule-declare-name incorrectly: (define p (path->complete-path ip)) (define module-itself (make-resolved-module-path p)) (parameterize ([current-load-relative-directory (current-directory)] [current-module-declare-name module-itself]) (eval (read-syntax p)) ) (where ip is a relative path passed in)

yeah, (read-syntax p) never returns…….

read-syntax takes an extra argument before the port. (It’s trying to read from stdin.)

:flushed: heh…

next issue, that read-syntax errors out with module-name::1: read: #lang not enabled in the current context

The syntax/modread module has with-module-reading-parameterization, which calls a thunk in a context where #lang is enabled

hmm… that get’s #lang, but module and #%app aren’t bound now

although my #lang rebinds module, so I’m not sure what’s going on

Use check-module-form to make module have the right binding.

The bindings of your language apply inside a module that uses the language, but you need module as really a module to get started.

That got the correct bindings, but brought me full circle…

I use that mechanism to eval “a.rkt”, which requires “dir/b.rkt”, which requires “dir/c.rkt”. It fails during the require of “dir/c.rkt” because it’s using the path “dir/dir/c.rkt”

so the parameters get lost one require in

my syntax in “dir/b.rkt” boils down to (require (file "dir/c.rkt"))

Another way to do this would be to change the syntax I’m using to generate the (require (file "dir/c.rkt")) to generate a full path to “c.rkt”. The challenge then would how to pass the root directory into that syntax or to have that syntax expand to a reference to the root path (breaking hygiene in the process)

unfortunately the only way I know how to do that is to write the path to a file and read the file in the syntax to grab the path — there’re no parameters kept across the compilation boundaries (AFAICT)

I’m not really clear on what you’re trying to do, but it’s starting to sound like you want to install a collection, and then you can refer to the collection without using an absolute path. Another possibility is that you want to more completely take control over module-path resolution by using (lib ...) paths that don’t refer to an installed collection and setting current-module-name-resolver to find the would-be collection yourself. That’s not usually a good option, because relying on a custom module name resolver doesn’t play well with tools like raco make. But it can work out if you’re at a point where those tools don’t apply. For example, raco exe generates an executable that sets current-module-name-resolver, and it’s ok because tools like raco make don’t apply to an already-constructed executable.

is it possible to have a language specific collection?

doing a (require (lib "dir/c")) would be nice if couldn’t accidentally grab a “dir/c” in just any collection. to be clearer, my files are #lang fracas so the actual file in this case is dir/c.frc.

but, yes, the (lib ...) mechanism is close to what I’m trying to do… I just want a separate “namespace” for my fracas collection(s)

and maintaining raco make would be nice, but not strictly necessary

When (require (file "dir/c")) appears in a #lang fracas module, where do you want “c.frc” be found. Always relative to the enclosing module, or relative to the “fracas” collection, or something else?

relative to the fracas collection

e.g. its full path will be: /Users/me/src/all-my-fracas-files/dir/c.rkt

so the “collection”, as it were, for fracas files is /Users/me/src/all-my-fracas-files

Would it make from #lang fracas to provide a different require that expands something like (require "dir/c") to (require (lib "fracas/dir/c.frc"))?

(where the first require is the fracas one and the second require is the racket one)

yes, I am using a “fracas” version of require that I’ve named import

that expands to (require (file "dir/c.frc"))

changing that seems the like right approach….