Re: %nil once again
Ken Raeburn wrote: On Jul 19, 2009, at 16:10, Neil Jerram wrote: BTW, I implemented also the function bindings of symbols using this fluid-based dynamic scoping at the moment -- but on second thought, there's no scoping at all for function slots (all are global), is there? No, I don't think there is. `let' can't operate on function slots. Not in the main emacs lisp implementation. However, cl-macs.el provides an "flet" macro that does work on function slots; it uses the "letf" macro which expands to include a use of unwind-protect to do its dirty work. But that's not part of the real "elisp semantics", and so if we don't want to include this as a genuine extension into Guile's compiler, we don't have to use the fluids for function slots. With unwind-protect and friends one can, just like in emacs, implement this functionality, even without a fluid implementation. However, if you agree that this would be a useful feature (dynamic scoping of functions) I can of course implement this as an extension to elisp...? I agree that it might be of use sometimes, but am not convinced it is really "necessary". Yours, Daniel -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri
Re: array handles and non-local exits
Hi Neil, Neil Jerram writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo writes: [...] >>> Array_handle_release is a bad idea. >> >> Fair enough. > > FWIW, I agree (I think with both of you) that `we might need it in > future' is not a good argument, but that API compatibility is. OK. So we can proceed with the removal, leaving a no-op macro when SCM_ENABLE_DEPRECATED == 1. Andy, can you take care of this? :-) > I'm pretty sure it was about allowing C code to efficiently access and > modify uniform vector contents, but at the same time supporting > operations which might require the underlying storage to be > reallocated. > > The latter operations could include enlarging an existing vector, or > copy-on-write. But AFAICT we never implemented either of those ideas, > and the existing code never changes the underlying storage of a > vector. Thanks for the information. Ludo'.
Re: %nil once again
On Jul 20, 2009, at 04:12, Daniel Kraft wrote: No, I don't think there is. `let' can't operate on function slots. Not in the main emacs lisp implementation. However, cl-macs.el provides an "flet" macro that does work on function slots; it uses the "letf" macro which expands to include a use of unwind-protect to do its dirty work. But that's not part of the real "elisp semantics", and so if we don't want to include this as a genuine extension into Guile's compiler, we don't have to use the fluids for function slots. True. With unwind-protect and friends one can, just like in emacs, implement this functionality, even without a fluid implementation. Yes... though it means the elisp implementation wouldn't be able to cleanly support a multithreaded implementation that makes "flet" possible to implement safely. If we want multiple threads, we probably do want thread-safe flet, I would guess. However, if you agree that this would be a useful feature (dynamic scoping of functions) I can of course implement this as an extension to elisp...? I agree that it might be of use sometimes, but am not convinced it is really "necessary". I haven't looked into what it's needed for in great detail, but it does seem to get used in some places (gnus, mh-e, org, vc-rcs, ...). I don't know if we'll get to multithreaded elisp (I kind of hope so) or if we'll care about having a thread-safe flet (???), or thread-safe versions of whatever other interesting things unwind-protect might be getting used for. Ken
Elisp flet construct
Hi all, in the %nil thread a suggestion was brought up to support the `flet' construct (and `flet*' as well, if we choose to do so at all, I favour) in Guile's upcoming elisp implementation that behaves just like a let for function-slot bindings, enabling dynamic scoping for them. It is no "official" elisp construct, but according to what I heard there, can be useful at some times (I guess the use is mainly to locally alter bindings of standard functions for some code executed without a risk of permanently messing things up). So I don't know how you regard addition of "extensions"...? From an implementation point of view, I see both an argument against and in favour of this extension: * As implemented at the moment, it would be fairly easy to add flet/flet* to the compiler. * If we do not implement flet, we can implement the function-slots without indirection via fluids but rather use the Guile symbol bindings directly. This is for sure a simplification especially performance wise, but I can't say how much it really affects. Most bindings in use are, I guess, variables, so we save the fluid-references only in a fraction of cases. Any comments welcome, so we can decide upon this. Thanks, Daniel -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri
Re: %nil once again
Daniel Kraft writes: > Hi, > > I think I got the test-suite as well as a basic macro implementation > (the compiler framework is really cool, that was fairly easy to do); > recursive macros do not yet work, but otherwise it looks fine. > > However, I want to tackle quasi-quotes (besides others) now; and in > Elisp %nil is not only #f of Scheme but also the end-of-list marker (I > guess that's why simply using Scheme's #f for %nil does not work). [...] > It would be cool to teach Guile somehow to treat %nil as the > "standard" end-of-list value, such that both of these queries would > optimally return true. At least, is there some way to construct lists > terminated by %nil using something like the list primitive? Other > things needed would be for instance terminating rest-arguments by %nil > rather than '() and the like. Why not eliminate %nil/#nil and replace it with ... '(). This would allow elisp to reuse all (or at least most) of the Scheme list functions without having to muddy Scheme semantics with special #f/#nil handling, but would require a very tiny elisp specific truth predicate. Since everything should be compiled into an IL instead of Scheme this should be straightforward. This would have the rather nice advantage of removing all special elisp support code from libguile itself (thus cleaning up libguile a bit *and* making the elisp translator a much better example for other language translators since every language can't expect to have special support from libguile). If the Scheme value #f leaked into an elisp lisp/vector/etc. then it should *not* be treated as false to elisp because it is *not* an elisp false value; likewise if '() leaks back into data used by Scheme there is no particular reason to treat that as false and not end of list. This has the slight downside that calling between elisp and Scheme may not be so natural. Any elisp that would call Scheme must know it is calling Scheme (or simply not-elisp) and that it ought to generate Scheme false objects if it is calling a predicate of some sort, and any Scheme calling elisp should know this and use null? to check for a false return value. The only downside I can see to this is that if code were to be ported from elisp to Scheme there would now be code that assumed a '() return as false when #f would be false, but this could be fixed using a predicate like elisp-false? (or null-or-false? or ... something). Having multiple distinct false values is almost as bad as punning false and end of list and so I think the few disadvantages do not outweigh the advantages. -- Leebert: You don't listen to music. Leebert: You listen to the audio equivalent of /dev/urandom
Re: [CM] funny scheme code (fwd)
-- Forwarded message -- Date: Mon, 20 Jul 2009 21:02:38 +0200 (CEST) From: Kjetil S. Matheussen To: Bill Schottstaedt Cc: cmd...@ccrma.stanford.edu, guile-devel-requ...@gnu.org Subject: Re: [CM] funny scheme code On Mon, 20 Jul 2009, Bill Schottstaedt wrote: For some reason, this code strikes me as funny: (let ((j (lambda () 0)) (k 0)) (do ((i (j) (j)) (j (lambda () 1) (lambda () (+ i 1 ((= i 3) k) (set! k (+ k i would you believe 6? Maybe I need a vacation. A slight modifications makes Guile (the one included with fedora 11) crash: [kje...@ttleon bin]$ guile guile> (let ((j (lambda () 0)) ... (k 0)) ... (do ((i (j) ... (j)) ...(l (lambda () ... 1) ... (lambda () ... (+ i 1 ... ((= i 3) k) ... (set! k (+ k i Segmentation fault [kje...@ttleon bin]$ [kje...@ttleon bin]$ [kje...@ttleon bin]$ guile --version Guile 1.8.6 Copyright (c) 1995, 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation Guile may be distributed under the terms of the GNU General Public Licence; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. [kje...@ttleon bin]$ ___ Cmdist mailing list cmd...@ccrma.stanford.edu http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
GNU Guile Hackers Meeting?
Hello! Neil Jerram writes: >> Perhaps we should set up a GNU Guile Hackers Meeting (G²HM) by the time >> 2.0 is released? > > If it works for everyone, why not? To make things more concrete, how about August 22--23? It works for Andy and me. We could meet someplace in the Pyrénées---how nice it must be to discuss Scheme things in the wild. ;-) (Of course this is still subject to discussion depending on the possibilities of everyone.) Thanks, Ludo'.
GNU Guile Hackers Meeting?
Hello! Neil Jerram writes: >> Perhaps we should set up a GNU Guile Hackers Meeting (G²HM) by the time >> 2.0 is released? > > If it works for everyone, why not? To make things more concrete, how about August 22--23? It works for Andy and me. We could meet someplace in the Pyrénées---how nice it must be to discuss Scheme things in the wild. ;-) Of course this is still subject to discussion depending on the possibilities of everyone. Thanks, Ludo'.
Re: GNU Guile Hackers Meeting?
> From: Ludovic Courtès > > Hello! > > Neil Jerram writes: > > >> Perhaps we should set up a GNU Guile Hackers Meeting (G²HM) by the time > >> 2.0 is released? > > > > If it works for everyone, why not? > > To make things more concrete, how about August 22--23? It works for > Andy and me. > > We could meet someplace in the Pyrénées---how nice it must be to discuss > Scheme things in the wild. ;-) Answering this one just for the sake of comedy ;-) I can't make it. I live in Los Angeles, and I have tickets for the Warped Tour punk festival on the 23rd. -Mike
