[Chicken-users] Re: SRFI 41
On Wed, May 6, 2009 at 11:26 PM, Kon Lovett klov...@pacbell.net wrote: Hello Involved, I really hate to respond to this thread but since I ported from the SRFI 41 reference implementation maybe I should. I'm curious. What did you have to do to port SRFI-41? It should have worked directly as written just about everywhere. On May 6, 2009, at 5:46 PM, Phil Bewig wrote: On Wed, May 6, 2009 at 4:56 PM, Alex Shinn alexsh...@gmail.com wrote: Hi, Phil Bewig pbe...@gmail.com writes: snip Writing a library that duplicates SRFI-1 for streams seems to me to be folly. Well, if you have streams at all, even if they are only suited to a special class of algorithms, it makes sense to provide a complete library of basic operations. Otherwise people will continuously reinvent the same utilities, and sometimes get them wrong. In fact, it is specifically desirable to provide an exact match of the SRFI-1 API for easy conversions and comparisons. In any module system with import prefixing (including Chicken 4), you can write everything with a stream- prefix and swap the backend from streams to lists with: (import srfi-41) (import (prefix stream-) srfi-1) Going the other direction (writing for SRFI-1 but then switching to streams) is only a little more verbose, requiring renaming of the individual identifiers you use. I disagree. Streams and lists are not substitutable. Haskell conflates the two because everything in Haskell is lazy, so there is no difference. But that isn't true in Scheme. There is a reason for 'delay' 'force'. Scheme is eager but multi-paradigm and API designers shouldn't go out of the way to hide the fact. At least for the basics :-) Exactly. Haskell is pure and lazy all the way. Scheme is broader. snip When would it make sense to convert the name of a symbol to a stream of characters? If your interface only accepts streams. But Scheme doesn't only accept streams. It also accepts lists. My other point is that 'symbol' is an atomic concept. A symbol doesn't consist of the stream of characters in its name-string. There might be a specialized need for a symbol-stream function, perhaps in a debugger or some other introspective program where streams exist but lists don't, but that's far beyond a general-purpose library. That's why using SRFI-1 as a checklist for streams-ext makes no sense. snip [I would argue the name and API should be changed to stream-drop-right to match SRFI-1, though.] Sounds like a synonym in a SRFI 41 based streams-ext. Stream-length and stream-reverse are certainly candidates to be dropped from a stream library. I'm not entirely sure how I feel about them. You feel badly ;-) They imply streams are finite. I prefer the general idea by the user that streams are infinite, at least until they run out of steam ... err, stream. I included stream-length and stream-reverse because they are used regularly in Haskell programs, and Scheme programmers who are porting Haskell code, say as an academic exercise, might find them useful. I continue to maintain, as I did in SRFI-41, that if you need to materialize an entire stream, you do better to find a way to re-cast your program to use lists. You and Alejandro seem to be suggesting that you would use streams in preference to lists in a variety of programs. Take as given that streams will be much slower than lists, at least in current Scheme implementations. I can't imagine using streams for much more than toy programs or academic exercises. I would always find a better way. Now, if you want to argue that the SRFI-1 API is too large, that's another story :) It is. I never use SRFI-1. My personal standard library has take, drop, take-while, drop-while, range, iterate, filter, zip, a simple list comprehension macro, and pattern matching. Maybe the R6RS authors were on to something ;-) The guiding principle in any library must be to keep it small and simple. I quoted Saint-Exupéry in SRFI-41, but could have quoted Einstein Everything should be as simple as possible, but no simpler. Occam's Razor also applies. SRFI-1 and streams-ext violate that principle to their own detriment. -- Alex I continue to maintain that it makes no sense to use SRFI-1 as a checklist for implementing a streams extension library. I hate to keep repeating myself, but streams are not lists. The two data types are used in two entirely different sets of circumstances, with different usage patterns. I agree. We are walking into sequence territory here. I kinda think everything that can be treated as a sequence should have an, optional, sequence oriented interface. But built on a type specialized interface. (Yes, I would prefer 'list-map', etc. in the base API.) That idea is more Lispy than Schemely. All that said, if you want to write a streams-ext library that mimics SRFI-1, feel free. Just be sure it is based on
Re: [Chicken-users] Re: SRFI 41
2009/5/7 Phil Bewig pbe...@gmail.com: ... I disagree. Streams and lists are not substitutable. Haskell conflates the two because everything in Haskell is lazy, so there is no difference. But that isn't true in Scheme. There is a reason for 'delay' 'force'. Scheme is eager but multi-paradigm and API designers shouldn't go out of the way to hide the fact. At least for the basics :-) Exactly. Haskell is pure and lazy all the way. Scheme is broader. Hi, I'm a bit surprised you mention delay and force for Scheme then say Haskell is pure and lazy all the way. You can have side effects in Haskell and you can force evaluation too. Cheers, Thu ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: SRFI 41
Phil Bewig scripsit: The guiding principle in any library must be to keep it small and simple. I quoted Saint-Exupéry in SRFI-41, but could have quoted Einstein Everything should be as simple as possible, but no simpler. Occam's Razor also applies. The analogy is false, at least as far as Einstein and Occam are concerned. They were talking about keeping the number of explanatory principles small. But tools are not principles. The smallest and simplest library for lists in Scheme consists of car, cdr, cons, pair?, and '(). Would you really be happy in a world where that's all you get, and the rest is just part of your program? When I ask a builder to construct a house for me, I do not expect him to begin by cutting down trees, digging clay for bricks, and mining iron ore for nails and screws. Nor do I expect him to reinvent drywall from first principles. SRFI-1 and streams-ext violate that principle to their own detriment. The point of a library, like that of a tool chest, is to provide tools considered generally useful. If your tool chest is half-empty, you wind up pounding nails with a screwdriver, or in the extreme case, instantiating Greenspun's Tenth Law. Too-simple libraries make too-complex programs. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: SRFI 41
As simple as possible, but no simpler. A large library has many costs. The obvious cost is the code size, but that's the least thing to worry about. Implementers must write, and test, and debug, and document, and maintain all that code. Users must endure long training and voluminous documentation, and inevitably find that the closest function in the library isn't quite what they need, and write their own anyway -- worse, they don't notice that the library does provide exactly what they need, but under a different name, and they write it again, anyway. And how many times have you seen a library that was useful in version 2 but unusable in version 5 because the need to maintain backward compatibility prevented some feature from working the right way? If you don't provide a function now, you won't regret having the function later. It's ultimately a matter of philosophy. Scheme has since its inception favored minimalism. Other languages make other choices. I'm not necessarily saying that streams-ext should be tiny, though I do think smaller is better than larger. I am saying that SRFI-1 is not an appropriate checklist by which to design streams-ext, because it will force you to provide many functions that only make sense for programming with streams-as-lists but not for programming with streams-as-streams. And I think SRFI-41 is, overall, a pretty good library, neither too small nor too large, but mostly just right. And if you need butlast, you should probably be using lists, not streams. On Thu, May 7, 2009 at 9:10 AM, John Cowan co...@ccil.org wrote: Phil Bewig scripsit: The guiding principle in any library must be to keep it small and simple. I quoted Saint-Exupéry in SRFI-41, but could have quoted Einstein Everything should be as simple as possible, but no simpler. Occam's Razor also applies. The analogy is false, at least as far as Einstein and Occam are concerned. They were talking about keeping the number of explanatory principles small. But tools are not principles. The smallest and simplest library for lists in Scheme consists of car, cdr, cons, pair?, and '(). Would you really be happy in a world where that's all you get, and the rest is just part of your program? When I ask a builder to construct a house for me, I do not expect him to begin by cutting down trees, digging clay for bricks, and mining iron ore for nails and screws. Nor do I expect him to reinvent drywall from first principles. SRFI-1 and streams-ext violate that principle to their own detriment. The point of a library, like that of a tool chest, is to provide tools considered generally useful. If your tool chest is half-empty, you wind up pounding nails with a screwdriver, or in the extreme case, instantiating Greenspun's Tenth Law. Too-simple libraries make too-complex programs. -- John Cowan http://www.ccil.org/~cowanhttp://www.ccil.org/%7Ecowan co...@ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
