I'm posting this on R6RS-discuss because my original thoughts on the matter didn't go through, and this covers them to some degree. See comp.lang.scheme for context.
On Thu, 27 Aug 2009 03:06:18 -0400, AntonioV <[email protected]> wrote: > On 26 ago, 19:13, "Aaron W. Hsu" <[email protected]> wrote: >> On Wed, 26 Aug 2009 06:29:48 -0400, Pascal J. Bourguignon >> <[email protected]> wrote: >> > "Aaron W. Hsu" <[email protected]> writes: >> >> I think that while Scheme has always been a diverse community, >> nothing >> >> can be gained by creating any schism. >> >> > Well r7rs is not a schism, since they consider that the large version >> > shall be a superset of the small version. >> >> I don't think that the bigger standard causes the schism because it >> could be a different language; as you have said, it won't be, per se. I >> think the schism will result from an all or nothing attitude, and that >> that nature of a single large specification will make it difficult to >> move forward given resistance to particular pieces. >> > > But, why "resistance to particular pieces"? I don't think any Scheme > user is "resistant" to have a standards-compliant "sockets" (XML/ > Threads/etc) library!! Oh yes they will. Most in fact. It isn't that they wouldn't like to have a standard library, it's that they don't like what others think they should have as a standard api. It takes a long time for some of the features to reach a point of consensus. Arguably, there are a lot of things in R6RS that could have been made better if they could have been left for longer discussion. It was because everything had to be "pushed out the door, that we ran into trouble. On things that the community agrees on, let's go ahead and get those things out and standardized. On things that the community is divided on, such as the right sockets library, the right way to handle threads and concurrency, the right way to do modules and such, let's spend some time figuring out how to do it right, and not rush it. > In fact I do think Scheme uers are *eager* to have a standards- > compliant set of libraries. We've been claiming for that for quite a > long time, I think. Yes, they are eager, but they are not eager to have a *bad* set of libraries. That's what will happen if we try to force things to standards that don't have well accepted solutions. THe problem isn't the desire to come together, it's that few people agree on the right way to do things. > "Working group 2 is encouraged to propose new working groups for any > new features that it considers desirable but cannot pursue without > risking the timeliness of its primary mission. " I argue that most of the basic things people are going to try to fit into this working group are like that, so trying to pick and choose and put them on a dividing line of either in or out is wasting time. Just separate everything out to start with. It will achieve the same result, with the added benefit that some things will get standardized sooner, and nothing will get standardized before it is ready, hopefully. > "Working group 2 may also consider whether it is practical to add new > features to support networking, threads, internationalization, foreign- > function interfaces, et cetera." > > So nobody is saying that lots of new features will be added all at > once. There's no hurry. There's a timeline, that's all. It's just not efficient to have Working Group 2 doing all this stuff. I'm arguing for a paradigm shift in order to make the community better able to produce good standards in a timely fashion that help us in the way I think is least likely to create bad results. > Agreed. This is what I understand it's the goal of working group 2: > make things portable. However, you also need to make sure that the quality of the interfaces is as good as they can be. Lot's of things can be made portable very quickly by making bad, ad hoc design decisions. Doing so will ruin Scheme. >> > Defining a "bottom" scheme and a "top" scheme, should promote more >> > portability across scheme implementations, since you can always count >> > on the bottom set. >> >> This really isn't any different than R5RS + De facto standard >> libraries. I don't think the all in one solution is going to help this. >> We tried it with R6RS. The end result was more of a schism than an >> increase in portability. > > So maybe the root of the problem is understanding why this happened > with R6RS, to avoid problems with the new one. I think the root of the problem was that R6RS tried to do too much. It didn't make it possible to adapt and be dynamic. It was an all or nothing type of standards process. It introduced new, untested interfaces, and had to compromise on numerous features that were not ready to be standards. >> My proposal for a better approach is to make it possible to implement >> as many standards as possible without forcing the implementations to >> use ones that they don't want. If they could cherry pick, this would at >> least > > But, it's the implementations that should adhere to the standard, and > not the standard that should adhere to the implementations!! That's not the way reports should work. The Scheme community doesn't operate on a top down approach where standards are handed down by the powers that be. Instead, the traditional, successful approach has been to recognize established practices and interfaces from the community and adapt them as standards. The implementations are the place to do the initial hot testing of a feature to see how well it works and what the problems are. As these features become more and more widespread, they can be standardized. > Or are we under a implementation-centric tyranny here? We the community should be able to write code the way we want, and when we all think that one way of doing something is good enough, then we can standardize that. Since many of the best and brightest have implementations, is it a problem that the implementors have lots of good ideas? > "Without forcing the implementations to use ones that they don't want" > is a wrong constraint, IMHO. >As a Scheme *user* I don't mind what implementations think or want or > desire. There should be a single standard, and whoever wants to adhere > to it will conform to it. After all the more standard an > implementation is the more the users will be using it. >It's time for Scheme *users*, not for Scheme *implementors*. And maybe > this is the main root of the problem: Scheme is a set of > implementation-centric communities and not a developer-centric > community. This is probably so due to a lack of standards *on > libraries*. I think it's time now to move on standardization of > libraries. From a Scheme user centric perspective. Why should the users be different than the implementors? I don't want just any user decided how I should program. I want interfaces that are well designed, things that are quality. Implementors are in a position to provide some insight into these pieces, because they actually have to implement a feature. A strong case exists for demanding that anything hoping to be standardized be tested and well used first. I agree that we should be standardizing libraries, and I don't see any reason to limit who can do that to implementors only, but there's no reason to leave them out either. Implementations *should* be able to implement what they want. Why should an implementor/user who needs a Scheme for a certain task be forced to do more work than necessary to accomplish that task? You seem to want more than a single standard, you seem to want everyone to have to do everything the same way. That's a fine sentiment, but developers need the flexibility to do things their own way. What if I want a small Scheme implementation for an embedded system? I want my standard code written for my device to work there and on other systems, but I don't care, nor do I want that system to implement everything. That would be a waste and would probably eliminate it from being useful. That is, I don't think the goal should be that we can do everything we want with every Scheme. I think the goal should be that given two schemes which both can do what I want, I should be able to write code to do what I want, and have it work on both. That is, for any given set of features X provided by systems Y and Z, code A using features X should run on Y and Z unmodified. That's all I think we need. That's portability. We don't need to arbitrarily force unnecessary conformance on Scheme implementors or users. The least invasive solution is best. > I understand that making things move "slowly" may help out > implementors accept the standards, but then again as a Scheme *user* I > do want to have a sockets library. The sooner the better. And a > standard-compliant thread library, too. Now. And many other libraries. > After all... Yeah, so, you already have that. Most other languages only give you a few implementations from which to work. Let's pick the one Scheme or two that has the features you want (likely they exist), then...well, you're not in any different position than the rest of the languages from a pure programming standpoint. Haste makes lots of bad things manifest in ugly ways. Sure, you want things now, and you want to be able to use them, so start using them. You don't need a thing to be standardized to start using it. We have threads, sockets, web frameworks, RDBMS, XML, RDF, OpenGL, Windowing and graphics, Matrix processing, Algebra systems, web servers, &c. Use them. > "While the Scheme community has many constituencies, we believe that > one primary purpose of a programming language is to program" > > ... and on the XXI century I need a socket and a thread (XML/etc) > library to program. Otherwise I'll consider doing stuff in Scala, or > Clojure, or Newlisp or whatever. And/or doing things myself (and > that's what Scheme users have been doing for a long time). And you already have those in Scheme. Actually, I'm working on a portable sockets library right now, no need for a standards committee at all. Then you don't have to use one of the *many* sockets libraries already out there. But why not use the implementation specific ones right now? Porting from one to the other isn't that hard and if you just want to program, you don't have to do it at all. > If the Scheme community is not able to have a set of standard > libraries then Scheme will end up being the best programming language > out there, that nobody uses because the Scheme community didn't agree > on a sockets library. I think this is largely a problem that people say exists, but shouldn't have to cause problems. Sure, we should be standardizing some of our libraries, but let's not try to take it all on in one go. There shouldn't be a need to do so, and doing so isn't going to get it done any faster. Things take time. I actually think you'll find your portable sockets library faster than you expect. ;-) > It's time now to make a community effort on standardization. Agreed. > In fact I think it's more important to have a not-very-bad standard > socket (XML/threading/etc) library quickly than having none. You can > make the library evolve later on, give a version number to it and make > changes on it. So lets isolate the badness. Keep these library and standardization efforts separate, and let them evolve and grow and develop at the pace suitable for them. (BTW, there's already a de facto standard portable XML library). Personally, threading is a perfect example of something that I don't think every implementation should be forced to have. Why should they? Many many many programs are written without threads, and platforms may not even provide them. I agee that a standard interface to using them would be nice, but we shouldn't force all the implementations to have it; what do we gain by that? Not portability. > What I mean is that I wouldn't matter about the library API being > *perfect*. Let's make one. A not-very-bad-one. And then let's work > together on making a new release that is even better. But let's agree > on a not-very-bad-one. For God's sake, a not-very-bad socket > (threading/XML/etc) library is not that difficult, is it? You'd be surprised. > I agree with the quotation: a tyranny sincerely exercised for the good > of a Scheme implementation-specific community (that is comfortable > with an implementation-specific sockets library) maybe the most > oppresive for the whole Scheme community! A standardization process that tries to tell us what is best certainly isn't good. We should decide what is best for us, and then the standards should respond by making these interfaces public. If someone doesn't want to adapt one interface, that's fine. Aaron W. Hsu -- Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. -- C. S. Lewis _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
