Guile 1.4.1.118 available
release notes: Yay, autoconf! thi NEWS excerpt: - 1.4.1.118 | 2008-07-16 - bugfix: guile.m4 macro GUILE_TOOLS_PROG handles missing program This macro used to erroneously set the shell-variable to a null string in the case where the requested program was unavailable. - some guile.m4 macros use config.cache - GUILE_FLAGS - GUILE_SITE_DIR - GUILE_LIBSITE_DIR - GUILE_TOOLS_PROG These macros now use AC_CACHE_CHECK, so subsequent invocations of the configure script execute faster (if -C is specified). tarball, online docs, etc, in dir: http://www.gnuvola.org/software/guile/ atom feed: http://www.gnuvola.org/NEWS.xml.gz public git repo: http://www.gnuvola.org/wip/ (g14)
Re: Closure?
On Tue 15 Jul 2008 09:59, [EMAIL PROTECTED] (Ludovic Courtès) writes: > "Neil Jerram" <[EMAIL PROTECTED]> writes: > >> I agree. I can't see a reason why we might want to remove >> `the-environment' and `local-eval', even if Guile's internal >> representation of environments changes, because the ideas that there >> _is_ a lexical environment inside a lambda (or a let ...), and that >> one can evaluate with respect to these environments, are absolutely >> fundamental in Scheme. > > Agreed. I just said the *representation* of closures could change. You can determine exactly what should be in the lexical environments at compile-time; thus you can allocate a fixed structure of variables to hold the lexicals. I suppose that in theory, you might be able to implement an augmentable `the-environment' in guile-vm, but I do not plan on doing so myself. Or maybe so, I do have some old code I want to get back to at some point... http://ambient.2y.net/soundscrape/docs/tutorial/a-few-notes-on-music/a-new-vocabulary/ Andy -- http://wingolog.org/
Re: Closure?
Hey, Andy Wingo <[EMAIL PROTECTED]> writes: > You can determine exactly what should be in the lexical environments at > compile-time; thus you can allocate a fixed structure of variables to > hold the lexicals. In addition, one expects constant-time access to local variables (aka. "ilocs"), which the current list-based closure representation fails to achieve (see `scm_ilookup ()'). Thanks, Ludovic.
