This page is part of the web mail archives of SRFI 22 from before July 7th, 2015. The new archives for SRFI 22 contain all messages, not just those from before July 7th, 2015.
>>>>> "David" == David Rush <kumo@xxxxxxxxxxxxx> writes: David> sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx (Michael Sperber [Mr. Preprocessor]) writes: >> >>>>> "David" == David Rush <kumo@xxxxxxxxxxxxx> writes: David> I just don't see how forcing them all to use a single name in 'exec' David> space will help anything. David> And I still don't. Say I've already installed Scsh 0.6, which comes David> with the brand new SRFI-22 support and poerted my GWZ application to David> take advantage of the SRFI-22 compliant installation David> capabilities. I've wrapped eveything up in cond-expands, and I'm David> pretty confident that it's "portable". David> Joe Bloggs now D/Ls GWZ and installs it on his SRFI-22 system, which David> is Gambit. How likely is it to work? Well, if I have *really* done my David> homework, maybe pretty good. A more likely scenario is that I haven't David> actually run it under Gambit because there are too many David> implementations to have covered all of them in my testing. Whoops! David> there is an incompatibility. So I have to go and put the Scheme David> implementation specific stuff back into my configure.in, and I have David> gained nothing out of the SRFI-22 exercise except the standard David> parameter passing. I got your point. However, as long as the feature sets supported by scsh and Gambit are as divergent as they are now, there's nothing I can think of which will solve the problem. Neither will autoconf: it'll just give up on GWZ if the Scheme implementation at hand won't provide what you need. On the other hand, I conjecture SRFI 7 *does* provide you with the ability to do what you might otherwise do with autoconf. David> none of R5RS, SRFI-0, or SRFI-7 provides David> enough functionality to do significant scripting. >> >> I disagree with that from practical experience. David> To be fair, you *can* write highly portable code with just SRFI-0, I David> can't speak to SRFI-7, I don't use it and I haven't seen David> widespread support for it SRFI 7 does much better with this since it doesn't require implementations to preload all the functionality conceivable required by an autoconf script. I do agree that it's not easy to choose a single Scheme implementation for, say, scm-srfi-7, as long as there isn't a total order among the SRFI sets supported by implementations. But, once again, I don't think there's anything you can do about that. I do hope that we'll eventually have Scheme implementations which support reasonably large numbers of SRFIs, and that will improve the situation considerably. Much the same problem exists with other languages with multiple implementations and feature sets which vary among them. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla