>> I've found a bug report on savannah, which noted the lack of >> ``procedure-source'' for guile 1.9.11 >> http://savannah.gnu.org/bugs/?30469 >> I wonder if any further decisions were made regarding the maintenance >> of ``procedure-source''. I would find it really useful for my >> application if the sexp containing the lambda expression that was used >> to generate the procedure was stored in it's property list, and I >> don't understand why this isn't currently done. > > > Out of curiosity, why do you need this?
The short answer is: to have more options to explore and play around with. The long answer is that I have been designing a framework for rapid GUI development (and more), sort of a REPL among GUIs. The sources are available on bitbucket's mercurial, if you want to see: hg clone https://bitbucket.org/panicz/slayer (apart from guile 2.0, they require SDL, SDL_image and SDL_ttf to build) One of the key features is to save the current design of the GUI to file. Initially I was thinking about serialization or dumping memory images (like the $_GLOBAL variable in PHP, or like images in smalltalk), but since I didn't find it to be a real option (since guile seemed to be lacking those features), I decided to write a function that outputs the scheme code needed to reconstruct the current state of the environment (or its sufficient approximation). Although closures would still be problematic, it would still be a good step ahead, and even the problem with the closures would perhaps find a solution eventually -- I thought to myself. > The reason I ask is that, in the presence of macros, it is not clear what > you mean by the "procedure-source". > > Do you mean before macro expansion? If so, what use it is to you, since it > may contain user macros that your code cannot understand? Furthermore, many > procedures simply don't exist before macro expansion. For example, a record > type definition expands to several procedure definitions that do not exist > in the original source. > > If you mean after macro expansion (or perhaps in some intermediate state of > macro expansion, e.g. at the point where the macro expander first encounters > the lambda expression), then a normal sexp with the original identifier > names is no longer sufficient. In psyntax, these intermediate forms are > represented as syntax objects, but at the very least you'd need to rename > the identifiers to prevent unintended variable capture. > > It's a very thorny issue, and I suspect that's the reason that > 'procedure-source' no longer works. If we are going to reimplement that > functionality, then we first need to figure out precisely what it _should_ > do in the general case. Which brings me back to the question: "Why do you > need this?" It would certainly seem more elegant if the user had the access to the original source (and if the unexpanded macros are a problem, the function could also store the code or a reference to the code of all the macros that were used at the time of its creation). But if it comes to my application, the expanded code would surely suffice -- the only thing I care about is that the fixed point of the current state is preserved. (Note that the name ``procedure-source'' would then become confusing, and something like ``procedure-code'' or ``procedure-expanded-source'' would seem more appropriate) Best regards M
