From: Neil W. V. D. <ne...@ne...> - 2004-06-08 00:35:36
|
1. In PLT 207's standard SRFI-7 source, I see a reference to "MJ Ray's code for SRFI 0", but no SRFI-0 "cond-expand" anywhere. Was the omission of SRFI-0 intentional? 2. Has anyone *used* the SRFI-7 implementation in PLT? 3. Are SRFI-0/7 feature names for MzScheme-specific extensions defined? I don't see any in "features.ss". |
From: Michael S. <sp...@in...> - 2004-06-11 17:10:51
|
>>>>> "Neil" =3D=3D Neil W Van Dyke <ne...@ne...> writes: Neil> 1. In PLT 207's standard SRFI-7 source, I see a reference to "MJ Ra= y's Neil> code for SRFI 0", but no SRFI-0 "cond-expand" anywhere. Was the Neil> omission of SRFI-0 intentional? Yes; MJ was really implementing SRFI 7 but didn't realize it, which is why the code was moved (at least in spirit). SRFI 0 isn't really implementable in any useful way in PLT Scheme. Neil> 2. Has anyone *used* the SRFI-7 implementation in PLT? Yes; I got plenty of bug reports in the beginning, at least. Neil> 3. Are SRFI-0/7 feature names for MzScheme-specific extensions defi= ned? Neil> I don't see any in "features.ss". No, and for good reason. --=20 Cheers =3D8-} Mike Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla |
From: Neil W. V. D. <ne...@ne...> - 2004-06-11 19:34:27
|
Thanks for the response. > Neil> 3. Are SRFI-0/7 feature names for MzScheme-specific extensions defined? > Neil> I don't see any in "features.ss". > > No, and for good reason. I can only guess at the guiding philosophy; could you elaborate? There are non-SRFI features that my portable code needs to talk about. For example, my current code has to know which of a few TCP APIs to use, and the most pragmatic way is to talk about features such as "Scsh Posix sockets API," (supported by not just Scsh) and "MzScheme 200 (supported to some extent under Gauche). Also, there are cases like Scsh and Scheme48 declining to provide an R5RS-compliant "integer->char". So I need a way of talking about how to get "ascii->char" behavior. And sometimes I just want to know which implementation I'm running on, since I have a priori information about particular ways to do things on that implementation for big wins or to work at all. In fact, this is probably what I need most often: "If we're using Foo Scheme, then do THIS. If Bar Scheme, then THAT. If neither of those, but the implementation supports a Baz API, then do THOSE THINGS. If all else fails, use THESE criminally inefficient R5RS-based procedures." |
From: Michael S. <sp...@in...> - 2004-06-12 06:47:24
|
>>>>> "Neil" =3D=3D Neil W Van Dyke <ne...@ne...> writes: Neil> Thanks for the response. Neil> 3. Are SRFI-0/7 feature names for MzScheme-specific extensions defi= ned? Neil> I don't see any in "features.ss". >>=20 >> No, and for good reason. Neil> I can only guess at the guiding philosophy; could you elaborate? SRFI 7 is for writing portable programs based on specifications shared by multiple implementations. Adding "MzScheme-specific" extensions defeats that goal, and SRFI 7 just isn't good at handling this case. Neil> Also, there are cases like Scsh and Scheme48 declining to provide a= n Neil> R5RS-compliant "integer->char". So I need a way of talking about Neil> how to get "ascii->char" behavior. Ah ... what? R5RS doesn't specify ASCII, and thus Scheme 48 and scsh actually invite you not to write unportable programs by relying on this If you want something like ASCII->CHAR, it seems the way to go about it is to provide a specification (in form of a SRFI, of course :-) ) which you can then use. Neil> And sometimes I just want to know which implementation I'm running = on, Neil> since I have a priori information about particular ways to do thing= s on Neil> that implementation for big wins or to work at all. In fact, this = is Neil> probably what I need most often: "If we're using Foo Scheme, then d= o Neil> THIS. If Bar Scheme, then THAT. If neither of those, but the Neil> implementation supports a Baz API, then do THOSE THINGS. If all el= se Neil> fails, use THESE criminally inefficient R5RS-based procedures." That of, course, is not only unportable now, it's also likely to make a program written and working now fail in the future. I know this situation is frustrating---but the methods are (IMHO) not likely to improve it. Your best bet for writing programs portable between PLT Scheme and Scheme 48 / scsh is to use their respective module systems, and factor out APIs that will work across both. (This is actually a pretty effective approach, and Matthew and I are slowly working on making it easier still.) --=20 Cheers =3D8-} Mike Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla |
From: Neil W. V. D. <ne...@ne...> - 2004-06-12 07:29:44
|
> SRFI 7 is for writing portable programs based on specifications shared > by multiple implementations. Adding "MzScheme-specific" extensions > defeats that goal, and SRFI 7 just isn't good at handling this case. I think "defeats" might depend on whether you are talking technically or politically. Technically, it's just a namespace and syntactic conditionals. > That of, course, is not only unportable now, it's also likely to make > a program written and working now fail in the future. I think I appreciate your point. However, libraries, if useful, would be actively maintained, and therefore could track the changing universe of implementations. There is just not enough person-power available to write excellent SRFIs and implementations of same right now. That reality cannot be forced politically, because there is little leverage, and few agents to influence anyway. Also, in practice, portability abstractions that are expressive and evolutionarily responsive enough to capture all the pertinent information on which crucial implementation/portability decisions might be made in programs-- are often impractical. You start bumping into intractable problems of ontology and decidability, and also get maintenance nightmares of the type you were trying to avoid. I think there should also be no reason, in a language with Scheme's syntactic power, that I can't have a single source code file that captures decisions I have made about how to get it to work well with different extensions of several Scheme implementations. If we want a commoditized, suffocating language, there is Python. :) I think I can make my code much more portable and widely useful by judicious reference to non-SRFI "features" than I can by imagining standards and libraries that do not exist and that nobody has time to write. However, if I, and many other modest-contributors like myself, eventually hit a critical mass of library usefulness, then maybe sufficiently good portability abstraction libraries we need will get written. Right now, the Scheme universe consists of a few-dozen poorly-funded research projects, pedagogical religions, and spare-time hobbies, however, and SRFIs and their implementations are poor for much of what they are supposed to be. |
From: Michael S. <sp...@in...> - 2004-06-12 13:25:32
|
>>>>> "Neil" =3D=3D Neil W Van Dyke <ne...@ne...> writes: Neil> I think there should also be no reason, in a language with Scheme's Neil> syntactic power, that I can't have a single source code file that Neil> captures decisions I have made about how to get it to work well wit= h Neil> different extensions of several Scheme implementations. All I'm saying is that SRFI 7 isn't a good way to do that. Besides that, I'm not sure why it needs to be a single source file. It's customary and good practice in other languages to encapsulate platform-specific stuff into clearly identifiable, separate entities. I believe that what you suggest, in the long run, leads to hard-to-maintain software. I've sure seen a lot of that in practice. Is this a political statement? I don't know. It does relate to design. I would like the appearance of SRFI 7 to denote "here comes a piece of code written in R5RS + SRFIs." That's something of technical usefulness. --=20 Cheers =3D8-} Mike Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla |