Code generation options for a self-made compiler

[Dmitry Pavlov]

Hello,

I posted this question once, nobody answered, this is a second try.
I believe there should be a solution because the problem seems rather common.

See, I have a DSL compiler implemented in Racket as a #lang, syntax-parse etc.
Like most compilers, it can emit somewhat diifferent code from the same input program depending on user's needs.
I am looking for a way to specify those needs to the compiler.

Specifically, I have a backend for C code generation and another backend for generating Racket syntax objects. I have an option to emit numerical code with 64-bit or 80-bit floating point numbers.

DrRacket has some GUI engine for compiler parameters (debugging, populate "compiled" directories etc), but I do not know how to use them in raco make, let alone bring my own options to DrRacket or raco make.

With C, everyone is happy with macros and built-in options, e. g.

gcc -O3 -DREAL=double -DDATABASE=POSTGRES prog.c


The best idea for Rackey I have so far is to use good old environment varibles, e. g.

REAL=double BACKEND=Racket raco make myprog.mylang

But it has its obvious drawbacks. What do I do instead?

Best regards,

Dmitry

[Matthew Butterick]

+ use the `raco-commands` key in "info.rkt" to create new `raco myprog ···` commands

+ use `racket/cmdline` to parse the input options to these commands.

[Matthew Flatt]

I don't have a great answer for this situation, either.


If the compilation mode makes sense as a global configuration of an
installation, then one possibility would be to add to
"etc/config.rktd". Editing that file is less convenient in some ways
than command-line arguments, but it's nicer in other ways, since it
makes it less likely that mismatches will result from failing to
configure every compilation and execution the same way.


I can elaborate on the possibility of imitating DrRacket's compilation
modes, although I'm not sure it's a good idea for your case.

DrRacket sets `use-compiled-file-paths` based on the GUI-selected mode,
adding a mode-specific subdirectory before the default subdirectory,
and then uses `make-compilation-manager-load/use-compiled-handler` to
get the effect of `raco make`. Crucially, though, DrRacket also sets
`current-path->mode` to decide, for each module, whether to write to
the mode-specific subdirectory or the default subdirectory; otherwise,
too many installed modules would be compiled to a mode-specific
subdirectory, while DrRacket wants only your files (based on a
heuristic for which files are yours) to be compiled in a mode-specific
way.

So, you could do something like that, and maybe even have your C-code
generation depend on the value of `use-compiled-file-paths`. But then
you also need to set `use-compiled-file-paths` before running your
program; one possible obstacle is that there's not currently a `racket`
command-line argument to do that.


If you don't care about having results of multiple compilation modes
coexist --- which seems likely --- then Matthew Butterick's suggestion
to create a variant of `raco make` makes sense to me, although it does
seem heavyweight and not composable. Your tool would use
`make-compilation-manager-load/use-compiled-handler`, but not need to
set `use-compiled-file-paths`. It could accept extra options as a way
to avoid environment variables and communicate some other way to the
code generator, but I'm not sure what the better way would be.

> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/1E315A92-E90E-45F5-99C6-94AF25F3
> 25B3%40iaaras.ru.

[Dmitry Pavlov]

Matthew,

Thank you and Matthew Butterick for advice. I was offline for a while.

I did not know about raco-commands. I think this is a reasonable
compromise for my task. I am not concerned about co-existence of files
produced by the compiler in different modes.

I am not sure I got the idea about DrRacket, though. You wrote:

> Your tool would use `make-compilation-manager-load/use-compiled-handler`

In what way my tool would use that?
To be clear, I care about my own options (C/Racket code and
64-bit/80-bit reals) rather than the options that DrRacket currently
provides to user.

In "Language->Choose language" I see different options provided to me
depending on whether I choose "The Racket Language" or "Teaching
Languages" or "Other Languages". So it gives me and idea that there is
some flexible mechanism for options setting underneath.

If I am mistaken, that is not critical -- I can program in DrRacket with
some "default" options for my language and use the non-default options
when starting from command line.

Best regards,

Dmitry

[Matthew Flatt]

At Tue, 20 Aug 2019 17:53:45 +0300, Dmitry Pavlov wrote:
> > Your tool would use `make-compilation-manager-load/use-compiled-handler`
>
> In what way my tool would use that?

I think you probably don't want to go this way. But if you want to
support multiple build variants within the same tree, you could use the
"compiled" subpath to effectively select among those variants.

> To be clear, I care about my own options (C/Racket code and
> 64-bit/80-bit reals) rather than the options that DrRacket currently
> provides to user.

Right. I meant only that you might do something similar to what
DrRacket does, but with your own "compiled" subpaths instead of
subpaths like "compiled/drracket/errortrace".


Matthew