On 10/28/2016 08:21 PM, David Storrs wrote: > Is it possible to take (e.g.) a procedure object and decompose it back > into its original source code?
I don't believe this is possible without murky unsafe programming, but... > One (bad) idea that came to mind was to simply shove some Racket code > into a TEXT field in the database, then eval it when the time comes. ... this isn't actually so bad. From what you write, I think you're already seeing the potential pitfalls: what should be in scope of the code to be eval'd? > Now, this is horrible for a lot of reasons (security and error > handling being two of them) Security will be a problem no matter what, but I don't see that error handling gives undue difficulty! What am I missing? > suppose I already had a function that did what I needed and I > wanted to use that Instead of storing a list-representing-code-to-eval, you could store - the name of a module - the name of a function - a list of argument values and use `dynamic-require` in your task runner to find the given function: > (dynamic-require 'racket/list 'filter-map) #<procedure:filter-map> and then `apply` with the arguments... Erlang uses essentially this approach in many places where actually passing a closure around would be problematic (e.g.: code upgrades; serialization to databases; etc). Erlang terminology is to call the triple of module name, function name, and arguments an "MFA". Cheers, Tony -- 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. For more options, visit https://groups.google.com/d/optout.
