I'm unsure how to express this problem precisely. Thus, I give some examples.
In Racket, a stx module in syntax module can be imported like
(require syntax/stx)
If I make something related to syntax, and named it a, can I make others import it like (require syntax/a)?
If could, how to do that?
The collection syntax lives here:
https://github.com/racket/racket/tree/master/racket/collects/syntax
So you'd have to lobby to get your module a included in this collection.
Yes, take a look at multi-collection package. Here’s an example multi-collection package:
https://github.com/lexi-lambda/racket-collections/tree/master/collections-lib
The main thing is that in info.rkt, collection must be defined as 'multi.
Since the directory for the package contains data/collection.rkt, you can write (require data/collection) to require the module.
I think a single collection package would work too, if you use syntax as collection and then just have a file a.rkt in that package.
Single/Multi-Collection is orthogonal to Single/Multi-Package, this comment goes into more detail:
I guess @sorawee's would also correct, but I have trouble with multi-collection in mindset.
@simonls's suggestion is correct, one can write the following "info.rkt"
(define collection "syntax")
Then it would simply seem the package as syntax, the most interesting part is the main.rkt left here will not affect existing code, so the original import part still works.
I don't know what main.rkt you are referring to, the one from the original package?
From my experiments a while back, it seemed as if only one of the packages can contain a main.rkt that corresponds to a particular collection-path syntax or syntax/parse etc..
If the packages have files with the same name I always got errors, so it seems be "append-only" where you need to be careful to avoid conflicts.
For your addition I would try to only have a info.rkt and a a.rkt, but no main.rkt.
Yes, for example, let's have a directory a-ext trying to extend module a.
Having a-ext/main.rkt is fine(but I only check if it's empty), this is because from my experience(imprecisely), missing main.rkt cannot get compiled?
I don't understand what you mean by check if it's empty, or why you want another main.rkt there.
Are empty main.rkt files handled differently?
The way I see it collection a needs to be resolved to one package that contains main.rkt, if multiple packages have this file, I have seen errors in the past about conflicts/ambiguity, I am not sure what tool/step was complaining about that (I think it was raco setup).
Well I tried to do it again now, and it doesn't complain about the two main.rkt, so now I am not exactly sure what the issue was. Or if racket tooling behaves different with newer versions. But my define-attributes package only has a main.rkt in its -lib package and seems to work.
Because I can't reproduce my previous experiences anymore, I am not entirely sure what is the best thing to do, so I can't recommend confidently, so I guess do what works for you and test.
If I re-encounter the issue I will write a comment.