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: Wed, 3 Oct 2012 18:27:19 +0200 Message-ID: References: <506910C0.7060108@netris.org> <87y5jp9de5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1349281696 31088 80.91.229.3 (3 Oct 2012 16:28:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Oct 2012 16:28:16 +0000 (UTC) Cc: guile-user@gnu.org To: Daniel Hartwig Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Oct 03 18:28:20 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 1TJRnI-0005TO-OT for guile-user@m.gmane.org; Wed, 03 Oct 2012 18:27:32 +0200 Original-Received: from localhost ([::1]:59214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJRnD-00068Z-2b for guile-user@m.gmane.org; Wed, 03 Oct 2012 12:27:27 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJRn8-00068I-2r for guile-user@gnu.org; Wed, 03 Oct 2012 12:27:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJRn6-0002AC-T3 for guile-user@gnu.org; Wed, 03 Oct 2012 12:27:21 -0400 Original-Received: from mail-lb0-f169.google.com ([209.85.217.169]:59834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJRn6-0002A2-Kx for guile-user@gnu.org; Wed, 03 Oct 2012 12:27:20 -0400 Original-Received: by lbok6 with SMTP id k6so6857895lbo.0 for ; Wed, 03 Oct 2012 09:27:19 -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:content-transfer-encoding; bh=IwECnfWREk93pio9d9JTzitVd5hd/Co62TYEQAYJVk4=; b=wEpSKNs7V+6Jz55dmgHNE+yo0lNT+YpqNXAwHiEfgqP1HSKwLMjYdeBv8i3CZAbE4A Xx2KYfTgVsrFjRchhZbRXdMADvkZ/MQI7fS2VXxkSszeiBgBAJG6w6IFuf3o86X+dDom QYZuwxMPcC4VRF/R1j/wCYpx9TIRyS3M8FRls5gjdi7ZOPO7oWk8xqxV2Ra5HpbMH8nk SVReZUMX3yb2QmYnJGJ76Lei8tLTciPdYXDMGgo5Nda3VnDprpXeTP9laDaQEVL6Cqcz k6H3BHUTIt82yPnqalJBOjS3m4qWSKIeNM5p/o5jugRhi3GfEinVX/p3H2qd+raGH90B uIgg== Original-Received: by 10.112.87.161 with SMTP id az1mr1826888lbb.99.1349281639374; Wed, 03 Oct 2012 09:27:19 -0700 (PDT) Original-Received: by 10.152.20.3 with HTTP; Wed, 3 Oct 2012 09:27:19 -0700 (PDT) In-Reply-To: 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:9608 Archived-At: > On 3 October 2012 03:29, Panicz Maciej Godek wro= te: >> Well, the idea for now is that the associated .spec file containing >> the state of GUI is loaded on startup, and the state of the >> interpreter is dumped to that file on exit (or at GUI's request). >> Viewing the file will obviously be an option (for the curious user), >> but any modifications would probably be overwritten eventually (unless >> the file is write-protected). > > You may be interested to see how Smalltalk handles this kind of thing. > IIRC it dumps the complete VM state to disk and reloads. Even > pre-packaged programs are simply VM dumps. I recall someone having the idea of adding smalltalk-like images to guile. I'd love to see such feature one day, but if guile is supposed to be an extension language, I think the C interface would need to be redesigned, because there would be a need to somehow dump the smobs from the heap to re-load them later. I don't know much about the implementation of the GOOPS objects, but I suspect that they would also require some means of serialization > To deconstruct and then > reconstruct the running state of a system is quite a complex task. I would use the word 'interesting' instead :) And if it works, the advantage is that the result can be modified by humans= . > Keep your own record of source information, etc. when your objects are > instantiated. Associate this with each using object properties (or > similar construct). This way you have any required environment and > precisely the source which generated the object, the user can inspect > this if interested and it can be used to create new instances. Well, this is more or less the way I do it. There is a well-defined hierarchy of objects which can be dumped. But I want the system to remain flexible, so that the user will be able to create his or her own methods and functions (especially that anonymous functions are so common in scheme), and therefore obtaining procedure names is not enough. > As someone mentioned earlier, the way macros are expanded there is no > single point to define (internal to guile) what is the =93source=94 of a > procedure. However, your system can define this as it has a clear > point of object instantiation. As I said, I don't want to loose flexibility. If I could rename lambda, lik= e (define primitive-lambda lambda) then I could easily implement this functionality myself (making 'self' a reserved keyword) (define-syntax lambda (syntax-rules () ((_ args body ...) (let ((self (primitive-lambda args body ...))) (set-procedure-property! self 'source (quote (primitive-lambda args body ...))) self)))) > I have not worked on such a system myself, so am poking around in the > dark here. Good luck :-) :) thanks