Hi guiler, Hi Daniel. I lost this thread in my mail application, sorry, so I try to continue this way instead.
* This feature for scheme is mainly for macro writers which knows what they are doing and which only guard state varibles not seen to the application programmer. This is how I use this feature in guile-log so it will not change how most people need to reason about scheme, the beuty remains. It makes insanly difficult tasks possible and simple things works as before. * I really like guile to cater for advanced users. Not only noobs. Although we should hide this feature really deep and put some serious warnings in the documentatin about the use. I actually hate using set! and if you look at e.g. guile-syntax-parse you will see that I rewrote everything with let loops, e.g. I really prefere that way of looping. I do understand your worry to let people loose on writing set! heavy code - that is not scheme. I also ported common lisp code to scheme and It was a horrible experience to see all set! ing in the code and I just had to rewrite quite a lot of the common lisp with rewriting the loops. But then a new version comes out and you are smoked. * If we are serious about combining emacs-lisp with guile we should really aim to have this feature added with deep support. The reason is that using set! in lisp world is a style of programming and is very common. For this reason I don't expect much emacs-lisp to combine well with undo redo additions via prompts. This hearts me really hard because it would be so cool to be able and schime in to a emacs-lisp project, add a few lines of code and show of a well functioning redo and undo addition to the complex emacs lisp code - this would be a really good selling point for guile-emacs and as I said, I hate that we don't have a nice support for it. * The proposed semantics piggy packs ontop of fluids sematics so everything we have done incorporating fluids carry over directly to special variables. And the extra stuff is really not that much. E.g. the maintainance burden is probably much less that your perception of it. * We need 2 extra VM op's if we are serious ablut implementing this though but they are simply essentially a copy paste of the fluid code so one could factor out the code somewhat. Another possibility is to add an option to the current fluid vm ops. * If you don't redo and undo nothing in the way scheme works changes it's only when you undo and redo stuff that the semantics becomes important. I really think that this is an important addition of guile and it would really be a dissapointment not having it's support considering the great gain you can get via optimizations with really not much extra work in guile. Also I think that I managed to get the semantics and implementation in a really beutiful state where a lot of effort have been in making it mix well and be consistant in what it does and actually get it into a state where it _is_ much simpler to reason about the code considering other way's of implementing the optimisations. Albait more difficult than before. Have fun /Stefan
