[Top][All Lists]

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

Re: scm_local_eval is not available in Guile V2.

From: Ian Hulin
Subject: Re: scm_local_eval is not available in Guile V2.
Date: Wed, 16 Nov 2011 14:50:59 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

Hi David,
On 16/11/11 11:01, David Kastrup wrote:
> David Kastrup <address@hidden> writes:
>> David Kastrup <address@hidden> writes:
>>> Ian Hulin <address@hidden> writes:
>>>> Hi all,
>>>> The latest git now dies on my V2 Guile system with 
>>>> .../lily/ error 'scm_local_eval' was not
>>>> declared in this scope.
>>> Related.  #{ ... #} is evaluated in the lexical context of the 
>>> surrounding function.  Is there anything that made Guile a
>>> flexible tool left in Guile V2?  "compilation" gives us all the
>>> disadvantages and rigidity of C at a fraction of its speed, it
>>> seems.
>>> I'll have to see whether I can come up with something working
>>> even half as nicely.  Probably will have to be rather close to
>>> the kludge we had before.
>> Ok, I have a scheme for doing this in a likely V2-compatible way.
>> Not really pretty, though.  I just compile all # and $
>> expressions in #{ #} into anonymous lambda functions at compile
>> time of #{ ... #}, and when the content of #{ ... #} is actually
>> parsed for real, I call the lambda functions in sequence for
>> getting the corresponding values.  There may be a possible
>> alternative implementation using continuations, but I have my
>> doubts about the efficiency or even viability of doing this with
>> V2.
>> But it does not make sense to do this change on current master
>> before some additional changes now in countdown are in.  So
>> you'll be a few more days without working setup.  Sorry for
>> that.
> <URL:>
> Accompanying patch is relative to staging currently.  This should
> get you going again.  I don't particularly like this approach, and
> it is more complex and error-prone, and likely slower than the
> original version.  But without access to procedure-environments, I
> see no simpler way out here.
Thank you very much for getting on to this so quickly. I started
having a look at the Guile V1.8.7 code to see if we could "borrow" it
to put in our code base, but it looks like they've done some janitor
work with the code in addition to changing the name of the underlying
internal routine from scm-i-eval to eval.

However, it may be work asking if the Guile team would be up to
supplying an unsupported (from their end) version which we could
stitch in to our code-base.

Andy and Ludo were quite helpful with providing us with a back-ported
module-export-all! when ly_make_module was in danger of breaking.

Would it be worth asking on guile-user about a private copy of a
ported scm_local_eval?



reply via email to

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