GNU bug report logs - #24102
Use guile variable objects as SRFI-111 boxes.

Previous Next

Full log

Message #31 received at 24102 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 24102 <at> debbugs.gnu.org, Glenn Michaels <gmichaels <at> Safe-mail.net>
Subject: Re: bug#24102: Use guile variable objects as SRFI-111 boxes.
Date: Wed, 01 Mar 2017 09:51:29 +0100

On Wed 31 Aug 2016 11:03, Andy Wingo <wingo <at> pobox.com> writes:

> On Thu 18 Aug 2016 18:14, Mark H Weaver <mhw <at> netris.org> writes:
>
>> As I wrote above, the current guile compiler can already do this kind of
>> type inference, although it does not currently do this for boxes.
>> we can already anticipate having native code generation in the
>> next couple of years, and we must keep boxes semantically simple so that
>> our future compiler will be able to generate good code for this very
>> important fundamental type.
>
> For what it's worth, I don't see the optimization argument as weighing
> very heavily on this discussion.  I would rather have fewer fundamental
> data types rather than more, in the next two years or so.  I see the
> mid-term result here being that SRFI-111 boxes are much slower than
> variables.
>
> The highest performance compilation tier we can imagine would include
> adaptive optimization, and when it runs you can know that the variables
> that a bit of code uses are bound or not.  Also in that case we can
> reasonably make any call to variable-unset! deoptimize any code that
> uses variables, forcing it to reoptimize later.  Since variable-unset!
> is quite rare this is no big deal I think.

Following up here :)  So again I think the optimization argument is not
so important; if that were the only consideration then IMO the balance
of things would be that we should apply Glenn's patch.

There is a semantic consideration as well -- box-ref on a box created by
make-box should never throw an exception, and code that uses the
SRFI-111 should be able to rely on this.  We should probably not
introduce a gratuitous incompatibility here.  I propose to add a flag to
variables indicating that certain variables may not be unset.  We can
also consider reversing this, in that only variables with the flag can
be unset; my understanding is that the only user of variable-unset! is
the Elisp language on variables that it creates, so that would be
acceptable too.

Andy

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.