This page is part of the web mail archives of SRFI discuss from before July 7th, 2015. The new archives for SRFI discuss contain all messages, not just those from before July 7th, 2015.
At Mon, 19 Jul 2004 12:52:15 -0700, Schol-R-LEA;2 wrote: > > I have been giving some thought as to some possible future SRFIs, and would > like some feedback on the ideas. You'll probably get a better response on comp.lang.scheme, this list is more for discussion about the SRFI process itself. And a wishlist is of limited use; it's more productive to choose one thing and try to get a SRFI done on it. Even a withdrawn SRFI can be a good reference and learning experience for the community. And if you can't manage a reference implementation yourself, you could consider petitioning someone who's written such a library to write a SRFI :) > * iterators and functionals library (see my previous posting) SRFI-42 is a superset of this, but simple while/until loops and when/unless are useful enough that they're already included in many implementations. But I don't think you'll get much support on a FOR loop - either use SRFI-42 or go all they way and write a CL LOOP SRFI. > * Soundex word-matching functions This is cute and many Schemes have it, but I don't really see the point in it. I can't imagine anyone choosing this over a universal hash these days. > * a simple object system (AFAICT, the last proposal didn't garner much > interest, though) If we get a SRFI for inheritable records, with or without multiple inheritance, we can build on top of it a separate, orthogonal method dispatch SRFI (or several to choose from), which is more likely to get support than a single, all-in-one OO system proposal. > * automatic test scripting Already lots of portable test libraries. > * basic timing and profiling Lots of these, none portable. > * SQL bindings Preferably in 3 tiers: 1) backend, 2) general DBI-like interface, 3) more Scheme-like interface so you don't have to do manual string compositions to build complex queries. SchemeQL is an interesting start but as a macro is not composable. > * compression/decompression library with-input-from-compressed-file :) > * cryptography library I think most Schemes have MD5, and there's a portable implementation, so this would be easy. > * TCP/IP bindings and Socket support Or just a POSIX SRFI. > * OpenGL bindings Several Schemes already have this, we just need a standard interface. And syntactic sugar. > * basic windowing-system bindings Choose one (like Gtk which is already supported by several Schemes) and standardize the API. We're a long way off from a universal windowing API, unless you want to directly adopt CLIM. -- Alex