Re: procedure-source availability

[Panicz Maciej Godek]

>> 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