specifying extra compiled collection paths with "info.rkt"?

[Matthew Butterick]

The docs for `compile-collection-zos` [1] say that "all files with the extension ".rkt", ".ss", or ".scm" in a collection are compiled" and that within "info.rkt", one can specify paths to omit with `compile-omit-paths`.

Is there way to go the opposite direction — specify *extra* files that should be compiled — because they are bytecode-able, but don't use the three magic extensions?




[1] http://pkg-build.racket-lang.org/doc/raco/API_for_Raw_Compilation.html?q=compile-collection-zos#%28def._%28%28lib._compiler%2Fcompiler..rkt%29._compile-collection-zos%29%29

[Matthew Flatt]

It looks like there's not a way currently, although I think it would
make sense to add one.

For file extensions generally, I think there should be an "info.rkt"
field to add extensions that are recognized by all tools that apply to
all collections. That's a larger project, but it's on my near-term list
of things to do.

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Matthew Butterick]

I've been bumping into variants of this problem — namely, difficulty using special source extensions — across the Racket ecosystem. In addition to this one,

[2] Adding file types to `raco test`

[3] Persuading DrRacket to handle special source-file extensions 

Is the underlying problem that I'm fighting the Racket gravitational field? Should I just dump my file extensions and use 'rkt'? 

I haven't done it yet because I've figured that others who have deployed DSLs with Racket have used special file extensions, and thus there must be an approved way of handling it. But maybe I'm the one who's doing it wrong. (I try to do something wrong every day. I usually succeed.)

[2] https://groups.google.com/d/msg/racket-users/9e7Eqg2-PdE/636NjwhMq3cJ

[3] https://github.com/mbutterick/pollen/issues/34

[Matthew Flatt]

At Fri, 21 Aug 2015 12:49:50 -0700, Matthew Butterick wrote:
> I've been bumping into variants of this problem — namely, difficulty using
> special source extensions — across the Racket ecosystem.

Yes. The intent of an "info.rkt" field to add extensions (i.e., the
larger project I have in mind) is to make the whole ecosystem adapt
correctly.

> Is the underlying problem that I'm fighting the Racket gravitational field?

Yes...

> Should I just dump my file extensions and use 'rkt'?

No, not as long as you're willing to push the envelope here.

> I haven't done it yet because I've figured that others who have deployed
> DSLs with Racket have used special file extensions, and thus there must be
> an approved way of handling it.

I think no one has really tried to use other extensions, so far --- at
least not enough to run into all the problems.

[Matthew Butterick]

> No, not as long as you're willing to push the envelope here.

Goes without saying.

FWIW the Pollen file extensions are not purely cosmetic. The Pollen renderer consumes Pollen source files and uses the extension (pm, pmd, pp, etc) to determine what kind of rendering is necessary. Of course this could be signaled from within the source file, but then I'd have the bootstrapping cost of having to load a file to find out how to render it, and then reload it to do the actual rendering. Whereas reading a file extension is simple and cheap.

[Matthew Flatt]

I've pushed changes so that the set of module suffixes is extensible
through a `module-suffixes` definition in a collection's "info.rkt".
Adding a new suffix affects compilation and testing in all collections.
(The suffixes ".rkt", ".scrbl", ".ss", and ".scm" remain hard-wired
in the set.)

Module suffixes are recognized by `raco setup`, `raco pkg` (via `raco
setup`), `raco test`, and DrRacket (in the file dialog, for example).

Previously, I had refrained from adding ".ss" or ".scm" support to
`raco test`. Making `raco test` different seems worse than perpetuating
the old suffixes, so ".ss" and ".scm" are now recognized by `raco test`
like everything else. In collections that have ".ss" and ".scm" files,
test configurations may have to be adjusted.


For tools that need to recognize suffixes, there's a new
`compiler/module-suffix` library.

There was already a function, `extract-base-filename/ss`, that was
intended long ago to be a central point of control for module suffixes,
but it was awkward and not general enough. Its implementation now uses
`compiler/module-suffix`.