From: Mark H Weaver <mhw@netris.org>
To: Panicz Maciej Godek <godek.maciek@gmail.com>
Cc: guile-user@gnu.org
Subject: Re: procedure-source availability
Date: Sun, 30 Sep 2012 23:40:48 -0400 [thread overview]
Message-ID: <506910C0.7060108@netris.org> (raw)
In-Reply-To: <CAMFYt2bcgKKym9yTwy24sm0RCmKxLhaVLJ_QBXenk1NSWOcxLA@mail.gmail.com>
On 09/30/2012 04:11 PM, Panicz Maciej Godek wrote:
> 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 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?"
Regards,
Mark
next prev parent reply other threads:[~2012-10-01 3:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-23 19:05 procedure-source availability Panicz Maciej Godek
2012-09-30 20:11 ` Panicz Maciej Godek
2012-10-01 3:40 ` Mark H Weaver [this message]
2012-10-01 16:31 ` Panicz Maciej Godek
2012-10-02 14:06 ` Ludovic Courtès
2012-10-02 19:29 ` Panicz Maciej Godek
2012-10-03 1:03 ` Daniel Hartwig
2012-10-03 16:27 ` Panicz Maciej Godek
2012-10-04 19:40 ` Ludovic Courtès
2012-10-07 0:07 ` Panicz Maciej Godek
2012-10-07 20:36 ` Ludovic Courtès
2012-10-08 20:11 ` Panicz Maciej Godek
2012-10-08 17:57 ` Mark H Weaver
2012-10-04 16:16 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=506910C0.7060108@netris.org \
--to=mhw@netris.org \
--cc=godek.maciek@gmail.com \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).