This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.
On Fri, 26 Mar 1999, Marc Feeley wrote: > > So, in conclusion, I don't think leanness and simplicity is > > sacrificed by making SRFI 0 more elaborate. I think making SRFI 0 > > more elaborate is necessary to make it sufficiently useful. > > At this point I think we really need more input from others and > particularly implementors. As I have said before SRFI-0 is at the > heart of the SRFI process so we need to have something that has > widespread acceptance. I completely agree that SRFI-0 is the kernel of SRFI's success. From an implementor's point of view, I assume all of the participants here will implement whatever is adopted. However, I want to emphasize that widespread acceptance goes beyond implementation and into _use_. If implementors and programmers feel that SRFI-0 is too weak, they will augment it and deprecate its usage in all but the most portability- sensitive applications. And if that happens, SRFI-0 will have missed its opportunity, to the detriment of the process (but not fatal). For myself, in its original form, I would rarely use SRFI-0 because of its everything's-there premise. This is expensive (imagine 1000 SRFIs that have to be loaded) and weak (conflicting SRFIs). > My views can be bent if I see that enough > people want a particular form (multiway conditional, support for > "and", "or", "not", etc). > > So I send a plea to everyone: if you have a view on this subject now > is the time to voice it. As we've discussed before, I think the original SRFI-0 is too limited to be widely useful. In our previous discussion, I was convinced that the problems I saw would be handled by external means (such as command-line options). I can live with that, but don't like it. I definitely think a richer mechanism would be nicer. The problem of nesting if-implements to achieve ad-hoc complex tests is a real one, and the `cond' style and the conjunct/disjunct both address this well. My impression of the point of SRFIs is to standardize implementations of useful features. If users have to write macros to implement 'or' and 'and' on top of if-implements, then we've sort of missed the target. If those macros are in another SRFI, then everybody will be compelled to use if-implements to include their own re-implementation of those macros in case that SRFI is not implemented. As a programmer, I want the richest possible set of features to be available without having to think about it. For RScheme at least, it does not appear to be noticably more difficult to implement the modified SRFI-0 (although I haven't implemented the READER-SYNTAX part yet). As for other implementations, SRFI-0 does not require a dynamically loadable module system, so I don't see it being infeasible for other systems. The text gives a compelling argument for a minimalist implementation. In any case, a lot of this thinking is mostly speculation -- I haven't used any similar systems. CPP is not internally extensible, m4 operates in a totally different realm, and Lisp #+/#- operates much earlier (although its probably the closest in flavor). It's difficult to predict the consequences of design choices at this point. I don't have a good handle on what SRFIs are going to look like (though there are a few, now) and how programs are going to want to use SRFI-0 to introspect on their environment. (My best working example of using SRFI-0 is in RScheme's cross-compiler. The same source code needs to run both in various preceding versions of RScheme as well as in its own version; using either form of SRFI-0 to manage those differences has been very nice so far.) In summary, I would encourage the incorporation of the modifications to SRFI-0. -- Donovan Kolbly ( d.kolbly@xxxxxxxxxxx ( http://www.rscheme.org/~donovan/ P.S. I'd love to finish my implementation before the discussion is over, though. I often find little gotchas in the course of actual implementation! I don't know how other implementors work, but I would encourage others to do the same if they haven't already.