From: "Oleg A. Paraschenko" <olpa@datahansa.com>
Cc: guile-user@gnu.org
Subject: Re: attempt to make a transparent binding
Date: Wed, 8 Dec 2004 10:21:27 +0300 [thread overview]
Message-ID: <20041208102127.122d7c02.olpa@datahansa.com> (raw)
In-Reply-To: <xfyhdmzl4mx.fsf@csserver.evansville.edu>
Hello Stephen,
thank you for comments.
On 06 Dec 2004 11:26:30 -0600
Stephen Compall <s11@member.fsf.org> wrote:
> "Oleg A. Paraschenko" <olpa@datahansa.com> writes:
>
> > First, the data in memory are big enough, and full instantiation
> > of lists wastes resources, especially because I use only small part
> > of the data. Instead, I'd like to have lazy instantiation. Let
> > "memory->list" returns a special type of pair in which car and cdr
> > are instantiated on demand. Is it possible?
>
> This is what Scheme's "promises" are for. However, I do not know
> Guile's promise support, as I've never looked at that part of the
> source, and have never needed them myself.
Nice suggestion. I've completely forgotten about Scheme promises.
They can't help me because I can't insert "force"s to the existing code,
but anyway now I have several ideas.
>
> > The second. Having Scheme data, I'd like to get the origin of this
> > data in the C program. Currently I think about mapping from SCMs to
> > C structures in C-Guile glue, but I'm afraid this is bad for garbage
> > collection.
>
> I can't think of any other way. If you were using smobs, the natural
> thing would be to use a slot for a pointer back to the C struct.
> However, you aren't.
>
> As for garbage collection, you could drop the SCMs in a gc protected
> guardian, and remove objects you can pull from the guardian every time
> you look in your table.
>
> The other solution, if you are really worried about resource usage, is
> to eliminate duplication by changing the internal representation of
> your program to use SCMs. Then you could scm_permanent_object a
> variable containing a list of current SCMs that may only be live in C.
> Further transformation could open up the possibility of writing new
> parts of the program in Scheme, or rewriting buggy sections :)
Thank you, I'll try to understand it.
>
> --
> Stephen Compall or s11 or sirian
>
> It's not reality or how you perceive things that's important -- it's
> what you're taking for it...
>
--
Oleg
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
prev parent reply other threads:[~2004-12-08 7:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-06 6:15 attempt to make a transparent binding Oleg A. Paraschenko
2004-12-06 17:26 ` Stephen Compall
2004-12-08 7:21 ` Oleg A. Paraschenko [this message]
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=20041208102127.122d7c02.olpa@datahansa.com \
--to=olpa@datahansa.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).