guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Anything better for delayed lexical evaluation than (lambda () ...)?


From: David Kastrup
Subject: Re: Anything better for delayed lexical evaluation than (lambda () ...)?
Date: Wed, 14 Dec 2011 11:27:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Andy Wingo <address@hidden> writes:

> On Wed 14 Dec 2011 08:50, Mark H Weaver <address@hidden> writes:
>
>> I have successfully implemented the (capture-lexical-environment)
>> special form in the evaluator, and also primitive-local-eval.
>
> I dunno, Mark.  That's a neat hack, but why should we have it in Guile?
> It can't compile.  It's not for efficiency, because if you wanted more
> efficiency, you would compile.

Most of the multi-list commands in srfi-1 have awful performance
implications once you give them more than a single list.  And you can
usually create more efficient equivalent code manually for most
non-generic uses of them.  So they are obviously not in there for
efficiency, but rather feature completeness and user friendliness.

> So what is it for?  It has a cost, so it needs to justify itself.

It is a trade-off.  The reason to include it in Guile rather than
providing it as an external package is because it depends on internals
of Guile, and thus needs to be maintained along with it.

Is the expected cost of maintenance worth the gain in Guile's
attractiveness?  A more thorough solution that would actually cooperate
with the compiler would likely be more attractive, and more prone to
maintenance.

But it would also likely serve to hold open the architecture for future
developments or plugins that could be interesting for integrating Guile
into other language systems like Emacs Lisp (which is only very slowly
moving towards lexical bindings) or Lua or other binding-intensive
systems.  Language interfaces that are not strictly ad-hoc and
closed-door would certainly help in keeping Guile interesting for
applications where the respective maintainers don't have to count on the
continued cooperation of Guile developers, but merely on the continued
existence of published interfaces.

I can't judge the best trade-off point here.  Nor how complex it would
be to actually work with the compiler, and be reasonably confident that
it will continue to work without too much hassle in future.

But an outside package meddling with undocumented internals is not safe
to rely on at all.  It can break at any point of time with no active
Guile developer being in a position where he would feel compelled to fix
it for the sake of Guile.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]