From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user Subject: Re: procedure-source availability Date: Mon, 1 Oct 2012 18:31:11 +0200 Message-ID: References: <506910C0.7060108@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1349109214 4594 80.91.229.3 (1 Oct 2012 16:33:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Oct 2012 16:33:34 +0000 (UTC) Cc: guile-user@gnu.org To: Mark H Weaver Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Oct 01 18:33:39 2012 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TIity-00027u-ME for guile-user@m.gmane.org; Mon, 01 Oct 2012 18:31:26 +0200 Original-Received: from localhost ([::1]:43036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIitt-00078M-3s for guile-user@m.gmane.org; Mon, 01 Oct 2012 12:31:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIito-00078F-Ah for guile-user@gnu.org; Mon, 01 Oct 2012 12:31:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TIitl-00016k-A8 for guile-user@gnu.org; Mon, 01 Oct 2012 12:31:16 -0400 Original-Received: from mail-lb0-f169.google.com ([209.85.217.169]:53446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIitl-00016I-39 for guile-user@gnu.org; Mon, 01 Oct 2012 12:31:13 -0400 Original-Received: by lbok6 with SMTP id k6so4544413lbo.0 for ; Mon, 01 Oct 2012 09:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2pmprCOwmXwgVZtfCdGGc4VrI3Pm2hO56jpklyYsmrI=; b=kHkaNNZfQkk/U1R8o3Eye16FiUUKrIi1OKyWUD6Ezc0SBigWae15Ry6qb15PyniW0G rAm9OwoXQ/c6EiPbQrspGrErZlEDY0Ma0HMtui8ByPnhfqo8Bh0a4TrH3QFgKoqxANMi GyRUcEXOaxK5tPhHaKTZHb0i56ySj/o0nx/NyqiItDi5TlM3tnemPgMOHC11a7Reumrs U7VzzsApA54JcSl+3v8v3yWkhfHsHfThxMZQ+bWD89IR5PCegImhY3IO7xljmiL+BHBh IfaEOTmk5/GMqzeiZjKng5s2G3lmHCGPYP9ABGlnWTUPW4Igj5n08zC3E5RBGxwRKLuR whEQ== Original-Received: by 10.112.83.73 with SMTP id o9mr550824lby.128.1349109071967; Mon, 01 Oct 2012 09:31:11 -0700 (PDT) Original-Received: by 10.152.20.3 with HTTP; Mon, 1 Oct 2012 09:31:11 -0700 (PDT) In-Reply-To: <506910C0.7060108@netris.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.217.169 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:9603 Archived-At: >> 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