Where exactly would that call go?

Right before (register-type-name name) I think.

I’m considering a tool that would leave behind “turds” (term of art) like .dep and .zo files.

[These would be “xref” files describing locations of definitions in a .rkt file, as well locations of references in that file to definitions in other files. [Although especially the latter might benefit from being put in say a sqlite db, it’s not necessary for the former, and it might be fine for the latter to exist in “turd files” initially or in addition to the db. TBD.]]

Anyway the TL;DR is: What is the policy and/or people’s preferences for turd files?

Should I dump them in compiled?

Should I make a fresh directory as does DrRacket — is that better because it’s separate, or worse because it’s separate and therefore e.g. one more thing to clean &c?

Should I let the user specify some root folder, and mirror the whole directory tree under that?

Something else?

(I recently watched Joe Gibbs Politz on Jean Yang’s PLTalk Twitch. A viewer called .pyc files “turds”. So I blame them.)

If they are required, I prefer they get left in a folder so they can be .gitignored with a single line. But, if they are ephemeral, then ideally they’d just be put in /tmp and never seen.

My 2p

I think they should go in compiled

I’d put them in compiled, because compiled is already excluded via .gitignore and similar.

If you want to be extra-configurable, then you could make the local sensitive to current-compile-file-roots so the files can be put outside the tree (but then you have a search path to deal with).

Thanks for the feedback!

@mflatt I vaguely recalled some configurability, thanks for jogging my memory wrt current-compile-file-roots.

@mflatt Sorry small follow-up question about that. Both current-compile-file-roots and use-compiled-file-paths are plural. Which is straightforward for loading — here’s a list of places to try until found.

But for a creator, writing such a file, what is a reasonable way to use these list-valued parameters? Just take car? (That seems fine for the default values, where the lists contain single values. But idk in what scenarios people might configure these to be lists.)

for example what does raco make do?

raco make uses the car of both, just as you say, if the file is out of date.

no idea if you’ve made any choices on file format yet, but the language server protocol actually has a standard format for source code indexing information. Maybe that’s useful? Might also just be a distraction. https://microsoft.github.io/language-server-protocol/specifications/lsif/0.4.0/specification/\|https://microsoft.github.io/language-server-protocol/specifications/lsif/0.4.0/specification/

Say that I have (require modpath), is there a way for a macro to retrieve the bindings imported from modpath at phase level 0?

Relevant Rhombus issue: https://github.com/racket/rhombus-brainstorming/issues/120

Does module->exports give you what you need?

It looks like module->exports just returns symbols. I need the actual bindings.

Ah. You could get the symbols and then dynamic-require them.

Using dynamic-require for this use case would be overkill.

How so?

Oh, sorry. I think I understand. You’ve already required the module.

Not sure if a require transformer + expand-import can help.

@shu—hung I was able to use a require transformer, expand-import, and set! to extract the bindings I needed.

@kellysmith12.21 Could you post the code?

Oh, it looks like I made a mistake. Although it appears to work, something’s not right. I’ll back up and explain what I’m trying to do, in general.

I’m trying to implement the sort of namespaces that you see in other languages, where you write ns.foo or ns::foo to access the foo binding from the namespace ns.

I have a simple implementation that works, so I wanted to try to take module bindings from a require and put them in a namespace, like import mod as Foo in Python.

I’d use (require (prefix-in Foo: mod))

For preventing name clashes, prefix-in is fine, but the namespaces I implemented allow you to locally “open” the namespace, so that the prefix is unnecessary.

It’s not a very useful feature, I just became excited since I had something that almost worked.

Thanks everyone for the suggestions :smile: