Andy Wingo <wi...@pobox.com> writes: > Hello David, > > Let us focus on solutions. > > If the this realm does have a coin, it is good-will. All participants > start with ample deposits, but yours is draining fast. Please listen to > what people are saying; they are trying to help you.
Lilypond already has an ugly inefficient hack in it that will keep it working in regard of the closure department largely independent of whatever Guile development chooses to come up with next. > On Tue 13 Dec 2011 14:56, David Kastrup <d...@gnu.org> writes: > >>> I wonder if we could provide some sort of current-bindings syntactic >>> form, also. It would require psyntax hooks, but it could work. >> >> I can't help the impression that a dependable and documented >> long-term strategy and corresponding commitment would at the current >> point of time be more important than brain-storming about short-lived >> hacks. > > Um... what? It sounds like `current-bindings' is the thing you need. It will at least be a year before any solution that does not work with Guile 1.8 will be accepted into Lilypond. Any effort spent on something that is not likely to survive that long because nobody will have ever used it by the time Lilypond would bother picking it up, is going to be wasted. And additional cause for bad blood. And since we are not talking about time-critical code paths in Lilypond, we'll be able to kludge around the consequences of Guile sacrificing its introspective qualities. I am not worried about Lilypond. I can work with any size of crowbar. I am worried about Guile. > But, um... I guess what I want to say is that you are making it > pretty hard to work with you. Since we are working on different projects, that is not a problem. Take a look at <URL:http://www.gnu.org/s/guile/>. It states: Successful and long-lived examples of Free Software projects that use Guile are TeXmacs, LilyPond, and GnuCash. If you take a look at <URL:http://www.texmacs.org/tmweb/about/todo.en.html>, you'll find 3.Scheme interface 3.1.General Scheme plug-in Internally present Guile as a plug-in, which could later be replaced by another Scheme implementation. in their list of things to do. For GNUCash, you have <URL:http://wiki.gnucash.org/wiki/Roadmap#Scheme_minimization> Scheme minimization There are some parts of GnuCash that make a round-trip into scheme code for no really good reason. The developers would like to throw out those parts of Scheme. Reports Right now reports are scheme scripts that programatically generate HTML. Scheme is impenetrable to most programmers. Expecting users to be able to write reports in Scheme is completely unreasonable. The ideal solution should have three modules: Record selection: Ideally graphical with an SQL-like "advanced" option Layout: The original item here suggested an HTML template; that could be the "advanced" option, with a simple table/graph being the default Style: CSS. It's built into WebKit, we should use it. Javascript: WebKit supports javascript so complicated interactivity can be added. Example: ability to expand/collapse levels of the account hierarchy in a report. This could be extended with Javascript interfaces to the API so that all of the report code is written in Javascript instead of Scheme. Any report module will still need some sort of scripting language to "calculate the numbers". Currently we have Scheme for this, but the developers would like to get away from that. Python might be a better option. So of your three listed showcase applications, the two others are trying to get away from Guile and/or Scheme. And it does not look like performance is the reason. So I don't think that throwing out _distinguishing_ selling points of Guile is necessarily doing you a favor. And the transparency with which it integrates with its language environment and the fact that one can continue to use its evaluator and debugger even for the application for which it serves as an extension language, certainly is a selling point. Even if documentation and commitment to interfaces are not doing their share. There is a reason that pure Scheme compilers like Chicken and Stalin don't see widespread employment, and that reason is that the introspective and interactive character of the Lisp-like languages is lost to a good degree, and the performance gain does not in itself suffice to compete with classical compiled languages and their usually more human-readable code and concepts. -- David Kastrup
