@mflatt Assuming the module currently being expanded is, in fact, located somewhere on disk, is there any reliable way to get its path on the filesystem? (variable-reference->resolved-module-path (#%variable-reference)) seems to reliably return a resolved module path with a path? in it when used at phase 0 (I assume because it comes from the value of current-module-declare-name when the module is actually evaluated), but at phase 1, it just returns the symbolic name of the module. I suppose I can use syntax-source on some piece of syntax and hope that the reader sticks the right path in there, but I’m wondering if there’s any other way.

Seeing the RacketCon 2019 keynote choice made me realize how many dumb questions I have about Rust and the Racket FFI. Like: 1. Can Rust produce C shared libs, that Racket’s FFI could use, today? 2. Could Rust produce something “richer” (more knowledge about object lifetimes or whatever, waves hands) that an enhanced Racket FFI could utilize, to make things safer, faster, or both?

1. Yes

1. I think so 2. probably not ?

1. probably? but it’s not obvious what that would be.

I was under the impression that lifetimes were erased so the runtime wouldn’t have much insight into that. Although @greg did say “enhanced Racket FFI” so…

I was imagining that you’d do something with the static information ahead-of-time

I don’t think there’s a good way to do that. Can I ask what use you had in mind?

The use I had is a hack, anyway, so it isn’t a big deal, I was just wondering if there was an easier way. It isn’t a good/valid use case. :)