Re: procedure-source availability

[Panicz Maciej Godek <godek.maciek@gmail.com>]

> On 3 October 2012 03:29, Panicz Maciej Godek <godek.maciek@gmail.com> wrote:
>> 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 “source” 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, like
(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