Re: [racket-users] Code generation options for a self-made compiler
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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20190822150100.25C53650159%40mail-svr1.cs.utah.edu.
Re: [racket-users] Code generation options for a self-made compiler
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 On 08/15/2019 11:03 AM, Matthew Flatt wrote: 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. At Mon, 12 Aug 2019 17:34:34 +0300, Dmitry Pavlov wrote: 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 -- 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+unsubscr...@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. -- 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+unsubscr...@googlegroups.com. To view this discussion o
Re: [racket-users] Code generation options for a self-made compiler
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. At Mon, 12 Aug 2019 17:34:34 +0300, Dmitry Pavlov wrote: > 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 > > -- > 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+unsubscr...@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. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5d5511d4.1c69fb81.4a779.1158SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
Re: [racket-users] Code generation options for a self-made compiler
+ 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. > On 12 Aug 19, at 7:34 AM, Dmitry Pavlov wrote: > > 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? -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/952086D8-F4D1-4CDD-AB4F-1367295B9F87%40mbtype.com.
[racket-users] Code generation options for a self-made compiler
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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/1E315A92-E90E-45F5-99C6-94AF25F325B3%40iaaras.ru.
