[Chicken-users] Re: Could we keep old URLs in the wiki working?
On Wed, May 06, 2009 at 12:29:55AM +0200, Alejandro Forero Cuervo wrote: When I moved all users in the wiki from /foo to /users/foo, I took the time to create symlinks from the old locations to the new, so that people using the old URLs would be automatically redirected to the right (new) location. People would gradually update their bookmarks and search engines would gradually notice that things have moved and everything would be fine and dandy. Gradually would imply that eventually everything would indeed be moved. A look at the Trac timeline tells me that these symlinks have been there for over 5 months. How much longer do you intend to keep them around? I've just noticed, however, that someone went and erased all the symlinks, which serves absolutely no purpose other than causing headaches for systems that still use the old links. I sent an email to this very mailinglist asking if it was ok to move the eggs and manual stuff: http://lists.gnu.org/archive/html/chicken-users/2009-02/msg00143.html Later I sent an email asking to do the same to the user pages: http://lists.gnu.org/archive/html/chicken-users/2009-03/msg00048.html Back then, nobody complained; people agreed that my changes were a good idea (or even necessary in the case of eggs and the manual). You can see the thread's responses starting here: http://lists.gnu.org/archive/html/chicken-users/2009-03/msg2.html (the archive doesn't show threads across periods, but this is the first reply to the first message I sent to the list) I gave a clear motivation for doing this; the user pages and their symlinks were getting out of synch, and having two places with the same info that you have to keep in synch is a very bad idea (there were a few broken symlinks, some user pages were _not_ symlinked and I believe there were even regular user files in the wiki rootdir). Also, the wiki provides no way to see and manage these symlinks as far as I know, which means that everytime someone creates or deletes a user page through the wiki interface, someone needs to go in and fix the symlinks. Another reason to do this was to remove clutter. There was a large number of files in the rootdir of the wiki. Now it's only a handfull, with the manuals, eggs and users nicely separated in their own namespaces. In the process of this big cleanup I found, aside from the broken symlinks, a few bogus egg pages and a few egg pages that had no eggs tag. I'm not saying that this couldn't have been done by an audit of the existing infrastructure, but it's a nice side-effect of having a good look at what we had. For example, searching for mario domenech goulart on Google lists http://chicken.wiki.br/mario%20domenech%20goulart as the second result. This result used to work, redirecting to the correct page. Now it takes you to a stupid edit form. Yes, and keeping it around will ensure Google never updates its links. We just have to wait a little longer and it will come around and update its links. So could we please just restore these links? If the names (eg. /mario%20doemenech%20goulart) eventually gets needed for something (for example, that becomes the name of something other than a user of Chicken, lets say the name of the official manual or something) we can *then* remove the symlink and use it for the purpose needed. Until then, why break things that were working? Again, I provided proper motivation in my original email. Why are you complaining now, over two months later, after I did all this work? This same comments applies to URLs for eggs and for manual pages and everything else. For example, all the URLs for all my eggs in the Chicken wiki were just broken when someone decided to move /egg-foo to /eggref/N/egg-foo without providing symlinks. Now most links to the documentation for my eggs are broken. Perhaps link /egg to /eggref/N/egg, where N is the latest version for which it is available? I proposed making such a change, but doing this automatically instead of manually - ie in svnwiki itself. This suggestion yielded no response from anyone with enough svnwiki knowledge to make this happen. Keeping these symlinks updated can be a huge maintenance chore and they will inevitably get out of synch, just like the user symlinks did. We have enough infrastructural problems as it is, I don't see why we need more. If it can be automated, I have no problems with it. In fact, I would applaud it -- nobody likes broken links. But I don't have access to our web server nor the insight in how all this stuff hangs together, so I'm not the right person to make these changes; I'll have to leave that to someone who does and has. No, I'm not volunteering my time to fix this mess. I had actually spent some time fixing this in the past for the users pages (which involved some transformations in the names of the links to make them more svnwiki-friendly). I'm merely asking for a stop to the nonsense in the way the Chicken
[Chicken-users] Re: Could we keep old URLs in the wiki working?
When I moved all users in the wiki from /foo to /users/foo, I took the time to create symlinks from the old locations to the new, so that people using the old URLs would be automatically redirected to the right (new) location. People would gradually update their bookmarks and search engines would gradually notice that things have moved and everything would be fine and dandy. Gradually would imply that eventually everything would indeed be moved. A look at the Trac timeline tells me that these symlinks have been there for over 5 months. How much longer do you intend to keep them around? Perhaps forever. :-) I've just noticed, however, that someone went and erased all the symlinks, which serves absolutely no purpose other than causing headaches for systems that still use the old links. I sent an email to this very mailinglist asking if it was ok to move the eggs and manual stuff: http://lists.gnu.org/archive/html/chicken-users/2009-02/msg00143.html Later I sent an email asking to do the same to the user pages: http://lists.gnu.org/archive/html/chicken-users/2009-03/msg00048.html Back then, nobody complained; people agreed that my changes were a good idea (or even necessary in the case of eggs and the manual). You can see the thread's responses starting here: http://lists.gnu.org/archive/html/chicken-users/2009-03/msg2.html (the archive doesn't show threads across periods, but this is the first reply to the first message I sent to the list) I'm sorry that I did not reply immediately to your proposals. I have many things that I need to keep up with in my life that are significantly more important to me than the layout of the Chicken wiki. For instance, in the last 3 weeks I had extremely limited internet access. That said, I don't think this should prevent me from pointing out things that I consider broken in a way that affects me in the layout of the Chicken wiki. I gave a clear motivation for doing this; the user pages and their symlinks were getting out of synch, and having two places with the same info that you have to keep in synch is a very bad idea (there were a few broken symlinks, some user pages were _not_ symlinked and I believe there were even regular user files in the wiki rootdir). Also, the wiki provides no way to see and manage these symlinks as far as I know, which means that everytime someone creates or deletes a user page through the wiki interface, someone needs to go in and fix the symlinks. I am *not* proposing keeping these in touch (ie. everytime someone creates or deletes a user page, go in and fix the symlinks). I'm simply proposing that if something used to be accessible at /foo and is now accessible at /bar/foo, we create a link at /foo to /bar/foo *unless there is a reason to use /foo for something else*. I'm *not* proposing that if we create a new page at /bar/foo, we create the /foo symlink. Another reason to do this was to remove clutter. There was a large number of files in the rootdir of the wiki. Now it's only a handfull, with the manuals, eggs and users nicely separated in their own namespaces. In the process of this big cleanup I found, aside from the broken symlinks, a few bogus egg pages and a few egg pages that had no eggs tag. I'm not saying that this couldn't have been done by an audit of the existing infrastructure, but it's a nice side-effect of having a good look at what we had. I agree that cleanning this up is good. However, I would also claim that just keeping the symlinks around doesn't really hurt anyone. One can simply ask for a view with symlinks removed to get exactly the same uncluttered view we have now. However, having the symlinks to old pages keeps old URLs/links working. So I see very little gain in just removing the symlinks. For example, searching for mario domenech goulart on Google lists http://chicken.wiki.br/mario%20domenech%20goulart as the second result. This result used to work, redirecting to the correct page. Now it takes you to a stupid edit form. Yes, and keeping it around will ensure Google never updates its links. We just have to wait a little longer and it will come around and update its links. I do not think this process, that everything will be automatically fixed, will be as effective and take as little time as I think you think it will. :-( So could we please just restore these links? If the names (eg. /mario%20doemenech%20goulart) eventually gets needed for something (for example, that becomes the name of something other than a user of Chicken, lets say the name of the official manual or something) we can *then* remove the symlink and use it for the purpose needed. Until then, why break things that were working? Again, I provided proper motivation in my original email. Why are you complaining now, over two months later, after I did all this work? Simply because I had not seen this. I assure you that if I had
Re: [Chicken-users] Re: Could we keep old URLs in the wiki working?
On Wed, May 06, 2009 at 11:06:35AM +0200, Alejandro Forero Cuervo wrote: When I moved all users in the wiki from /foo to /users/foo, I took the time to create symlinks from the old locations to the new, so that people using the old URLs would be automatically redirected to the right (new) location. People would gradually update their bookmarks and search engines would gradually notice that things have moved and everything would be fine and dandy. Gradually would imply that eventually everything would indeed be moved. A look at the Trac timeline tells me that these symlinks have been there for over 5 months. How much longer do you intend to keep them around? Perhaps forever. :-) That's exactly what I was afraid you were really trying to say! ;) I would prefer if we could move the wiki forward and keep it clean instead of keeping all this old cruft around. I'm sorry that I did not reply immediately to your proposals. I have many things that I need to keep up with in my life that are significantly more important to me than the layout of the Chicken wiki. For instance, in the last 3 weeks I had extremely limited internet access. That said, I don't think this should prevent me from pointing out things that I consider broken in a way that affects me in the layout of the Chicken wiki. I don't understand how having limited internet access in the last 3 weeks is relevant to your being able to read a message on this list two months ago. Also, you sent an email to this very list a short while after all these changes stating you were going to move away from Chicken's repository wiki, so you must have seen _something_ that prompted you to make this decision. In the end, if a decision is made and work is done, I'm sure you understand it's not very pleasant to hear someone complaining about this fact months later and asking to revert it partly. Also, the wiki provides no way to see and manage these symlinks as far as I know, which means that everytime someone creates or deletes a user page through the wiki interface, someone needs to go in and fix the symlinks. I am *not* proposing keeping these in touch (ie. everytime someone creates or deletes a user page, go in and fix the symlinks). I'm simply proposing that if something used to be accessible at /foo and is now accessible at /bar/foo, we create a link at /foo to /bar/foo *unless there is a reason to use /foo for something else*. I'm *not* proposing that if we create a new page at /bar/foo, we create the /foo symlink. That's even more confusing to newcomers. What's the canonical URL of a userpage? What happens when a userpage is deleted? Why do we have two URLs pointing to the same thing? What happens if someone decides to rename his userpage (for whatever reason)? Remember, you cannot see the symlinks from the wiki interface, you have to make a checkout for that. This means newcomers will only see the confusing behaviour of having some userpages available under two URLs, and some not. I agree that cleanning this up is good. However, I would also claim that just keeping the symlinks around doesn't really hurt anyone. One can simply ask for a view with symlinks removed to get exactly the same uncluttered view we have now. However, having the symlinks to old pages keeps old URLs/links working. So I see very little gain in just removing the symlinks. From a pure filesystem perspective, perhaps. But from a wiki perspective, see above. For example, searching for mario domenech goulart on Google lists http://chicken.wiki.br/mario%20domenech%20goulart as the second result. This result used to work, redirecting to the correct page. Now it takes you to a stupid edit form. Yes, and keeping it around will ensure Google never updates its links. We just have to wait a little longer and it will come around and update its links. I do not think this process, that everything will be automatically fixed, will be as effective and take as little time as I think you think it will. :-( Well, I'm not sure about that but I have seen that Google generally tends to pick things up reasonably quickly. This same comments applies to URLs for eggs and for manual pages and everything else. For example, all the URLs for all my eggs in the Chicken wiki were just broken when someone decided to move /egg-foo to /eggref/N/egg-foo without providing symlinks. Now most links to the documentation for my eggs are broken. Perhaps link /egg to /eggref/N/egg, where N is the latest version for which it is available? It is very easy to do: whenever you move file foo to bar/foo, add a symlink in foo pointing to bar/foo to the svn repos. That's all that is needed: the current infrastructure will act accordingly. You don't even need access to the server or any additional insight about how all this stuff works to automate this. This is inconsistent with what you
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
I did not consider the stream-ext library in the design of SRFI-41. In general, as explained in the SRFI, I designed SRFI-41 according to the advice of Antoine de Saint-Exupéry: *Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher*. (“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”) And I think I got a couple of things wrong -- if I was to rewrite SRFI-41 today, I would take away even more. Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, due to the underlying promises that require numerous type conversions, so streams should be used only when the sequence of elements is truly infinite (such as mathematical series) or when there is some clear advantage of laziness (such as reducing the number of passes through a large data set). Writing a library that duplicates SRFI-1 for streams seems to me to be folly. I looked briefly at your list of suggested extensions. A few may be useful for a modest extension library, if you have in mind a particular set of uses -- some of the examples in the SRFI, such as stream-partition, fall into this category. Some certainly don't belong in a general-purpose library -- if you need symbol-stream to convert the name of a symbol into a stream of characters, you can write it as part of your program. Many -- such as stream-butlast -- make sense only for lists (which are materialized in their entirety) and not for streams (which may never be materialized). I find it amusing that you consider stream-vector and vector-stream, since the pure FP people have such trouble with mutable arrays. And even the design is poor -- stream-butlast-n should almost certainly be merged into stream-butlast with an optional argument, but stream-reverse shouldn't also optionally append a list (or is it a stream?). You say that it is so obvious that all these functions should be included that you won't waste your time justifying it, but to me it is anything but obvious -- in fact, it is obvious to me that some of the functions you mentioned should never exist in the context of streams implemented for Scheme, much less be included in a standard library. On the other hand, in the context of streams implemented for Haskell, it may make sense to include some of the list-oriented functions, since Haskell has no finite-list type and uses streams in its place. Remember: streams are not lists. You are of course free to use SRFI-41 as the basis for an extended library of stream functions. I ask only that you do not call it streams, or streams-primitive, or streams-derived, so as not to cause confusion with the SRFI. I also recommend that you switch over as soon as possible from the deprecated SRFI-40 to SRFI-41. By the way, you should have mentioned as you critiqued SRFI-41 that you are the author of stream-ext. Phil On Tue, May 5, 2009 at 9:16 PM, Alejandro Forero Cuervo a...@freaks-unidos.net wrote: SRFI-40 is deprecated due to a memory leak. Please port SRFI-41 instead, and adapt any code that uses SRFI-40 to the new interface. Did you, during the design of srfi-41, consider the existance of the stream-ext library, which implements a lot of stream functions on top of srfi-40? http://chicken.wiki.br/eggref/3/stream-ext It's first version was released a long time before srfi-41 and only small changes have been made since then. The naming conventions and the semantics match those of srfi-1 as close as possible, to make things as consistent as possible. I've used the stream-ext library in many applications that represent strings as streams of characters throughout. The largest of these is probably Svnwiki. I'm worried about the incompatibilities I see between stream-ext and srfi-41. My concerns are the following: 1. srfi-41 provides a very small subset of the functionality that I think that any program that uses streams significantly will need. As such, I think it fails significantly at providing syntax derived from those primitives that permits convenient expression of stream operations. Most of the functions I list below can be implemented in a portable manner, as stream-ext does. To be fair, srfi-41 does seem to provide some functions that stream-ext does not. 2. More importantly (the previous concern can be solved with an additional library), a small portion of the interface exported by srfi-41 differs from that in the stream-ext library. I provide some cases below and explain why I believe the semantics from stream-ext are slightly preferable, mostly because of consistency with the srfi-1 list-based counterparts. I quite like the interface of srfi-1 and I find that, by providing inconsistent counterparts, srfi-41 is making it slightly harder to use streams than stream-ext. I may be the person who has written the most Scheme code using srfi-40
Re: [Chicken-users] Re: Could we keep old URLs in the wiki working?
On Wed, May 6, 2009 at 4:06 AM, Alejandro Forero Cuervo a...@freaks-unidos.net wrote: For example, searching for mario domenech goulart on Google lists http://chicken.wiki.br/mario%20domenech%20goulart as the second result. This result used to work, redirecting to the correct page. Now it takes you to a stupid edit form. Yes, and keeping it around will ensure Google never updates its links. We just have to wait a little longer and it will come around and update its links. I do not think this process, that everything will be automatically fixed, will be as effective and take as little time as I think you think it will. :-( Redirecting via a 301 rather than a 302 (as svnwiki does now) would have addressed this particular issue. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Could we keep old URLs in the wiki working?
On Tue, May 5, 2009 at 5:29 PM, Alejandro Forero Cuervo a...@freaks-unidos.net wrote: For example, searching for mario domenech goulart on Google lists http://chicken.wiki.br/mario%20domenech%20goulart as the second result. This result used to work, redirecting to the correct page. Now it takes you to a stupid edit form. The top two results when searching Google for 'require-library chicken' are both edit pages--Edit: chicken-setup redesign and Edit: man/4/Non-standard macros and special forms. But both of these pages exist! And indexing an edit form is useless. So, while we are on the subject of stupid edit forms, could we stop indexing these pages via robots.txt or meta name=robots content=noindex, nofollow? Jim ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] require-extension vs require-library/import
The manual implies that require-extension is the same as a require-library followed by an import, but this is not so. require-extension does not work for a source module that has no corresponding import file on disk. #;1 (require-extension tadm) Error: (import) during expansion of (import ...) - cannot import from undefined module: tadm #;1 (require-library tadm) ; loading ./tadm.scm ... ; loading /usr/local/chicken-4/lib/chicken/4/scheme.import.so ... ; loading /usr/local/chicken-4/lib/chicken/4/chicken.import.so ... #;2 (import tadm) #;3 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
Hi, Phil Bewig pbe...@gmail.com writes: Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, due to the underlying promises that require numerous type conversions, so streams should be used only when the sequence of elements is truly infinite (such as mathematical series) or when there is some clear advantage of laziness (such as reducing the number of passes through a large data set). I also find that any data structure in general which is built on I/O works well as a stream. For the current NLP app I'm working on, I need to build a parse graph from a port. Slurping up the whole input at once could require too much memory, and also would prevent the parser acting as a proper (buffered) Unix filter. On the other hand, since the algorithm for determining how much text I need to work with is dynamic, I can't just read chunks at a time (the basic unit I want to work on is a sentence, but I don't know what a sentence is until the parse is finished). So I build the graph as a lazy stream of nodes, and the algorithm transparently expands only as much input as needed. From what I've seen Alejandro also uses streams primarily with I/O - it's a very natural combination. 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. Some certainly don't belong in a general-purpose library -- if you need symbol-stream to convert the name of a symbol into a stream of characters, you can write it as part of your program. Sure: (define (symbol-stream sym) (string-stream (symbol-string sym))) That's just trivial and probably borderline enough that it isn't needed in the library. string-stream or equivalent functionality should be included, though, because the most efficient implementation of this may vary wildly depending on the Scheme implementation. However, the name may be unintuitive if you're not coming from a streams as I/O perspective. It may be both simpler to specify and easier to understand if you replace most of the foo-stream procedures with: (write-to-character-stream object) (display-to-character-stream object) Many -- such as stream-butlast -- make sense only for lists (which are materialized in their entirety) and not for streams (which may never be materialized). I think it's a little unfair to pick on stream-butlast when SRFI-41 includes stream-length, stream-list, stream-reverse, etc. As you yourself say, not all streams are infinite, and for finite streams these can be useful. Otherwise you'll repeatedly find people who when working entirely with streams (for type signature compatibility, and because all of their utilities are designed for streams, not lists), write things like (list-stream (butlast (stream-list stream))) when they really do need all but the last element of a stream they know to be finite. [I would argue the name and API should be changed to stream-drop-right to match SRFI-1, though.] Now, if you want to argue that the SRFI-1 API is too large, that's another story :) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Could we keep old URLs in the wiki working?
On Wed, May 6, 2009 at 4:06 AM, Alejandro Forero Cuervo a...@freaks-unidos.net wrote: For example, searching for mario domenech goulart on Google lists http://chicken.wiki.br/mario%20domenech%20goulart as the second result. This result used to work, redirecting to the correct page. Now it takes you to a stupid edit form. Yes, and keeping it around will ensure Google never updates its links. We just have to wait a little longer and it will come around and update its links. I do not think this process, that everything will be automatically fixed, will be as effective and take as little time as I think you think it will. :-( Redirecting via a 301 rather than a 302 (as svnwiki does now) would have addressed this particular issue. We actually gave this some thought and decided that a 302 was more appropriate than a 301 in the general case: http://listas.el-directorio.org/pipermail/svnwiki/2006-December/18.html http://listas.el-directorio.org/pipermail/svnwiki/2006-December/26.html I guess we should make it possible to specify per-link (or per-directory-with-links) whether the redirect should be a 301 or a 302. Thanks. Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Could we keep old URLs in the wiki working?
On Tue, May 5, 2009 at 5:29 PM, Alejandro Forero Cuervo a...@freaks-unidos.net wrote: For example, searching for mario domenech goulart on Google lists http://chicken.wiki.br/mario%20domenech%20goulart as the second result. This result used to work, redirecting to the correct page. Now it takes you to a stupid edit form. The top two results when searching Google for 'require-library chicken' are both edit pages--Edit: chicken-setup redesign and Edit: man/4/Non-standard macros and special forms. But both of these pages exist! And indexing an edit form is useless. So, while we are on the subject of stupid edit forms, could we stop indexing these pages via robots.txt or meta name=robots content=noindex, nofollow? I think http://wiki.freaks-unidos.net/svnwiki/extensions/canonical-url is a better solution to this problem. One problem I see with this, though, is that we have two visible domain names: galinha.ucpel.tche.br and chicken.wiki.br. This doesn't play that nicely with link rel=canonical. I suppose the best option may be simply to set galinha.ucpel.tche.br/$foo to 301-redirect to chicken.wiki.br/$foo for any value of $foo. Once we've done that and enabled the canonical-url extension, no more stupid edit forms should show in the search engines. Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, due to the underlying promises that require numerous type conversions, so streams should be used only when the sequence of elements is truly infinite (such as mathematical series) or when there is some clear advantage of laziness (such as reducing the number of passes through a large data set). I also find that any data structure in general which is built on I/O works well as a stream. For the current NLP app I'm working on, I need to build a parse graph from a port. Slurping up the whole input at once could require too much memory, and also would prevent the parser acting as a proper (buffered) Unix filter. On the other hand, since the algorithm for determining how much text I need to work with is dynamic, I can't just read chunks at a time (the basic unit I want to work on is a sentence, but I don't know what a sentence is until the parse is finished). So I build the graph as a lazy stream of nodes, and the algorithm transparently expands only as much input as needed. From what I've seen Alejandro also uses streams primarily with I/O - it's a very natural combination. Just thought I'd mention another example where I do this, which I feel is relevant to this discussion: http://wiki.freaks-unidos.net/xc, my command-line calculator. The whole lexing/parsing is done using streams: the input is received by the lexer as a stream of characters and turned into a stream of tokens (by procedure 'lexer'); the parser itself receives this stream of tokens and returns a stream with the numbers that should be printed (by procedure 'parse-input'). The whole evaluation of the input is thus simply (and here I'm quoting verbatim): (stream-for-each (lambda (obj) (if (number? obj) (output-num obj) (format #t ~S~% obj))) (parse-input (lexer (port-stream Very clean, isn't it? All is evaluated lazily, allowing things such as output-num to be redefined during the evaluation, to output numbers in a different formats. Given the primitives provided by stream-ext and stream-parser, xc does not have to add complexity of its own to handle streams but can deal exclusively with the problem it attacks, of evaluating arithmetic expressions and such. And, obviously, the sequence of elements in these streams is finite and, even if the tricks such as redefining output-num didn't matter, using streams instead of lists still has the advantage that Alex Shinn mentions of loading elements from the input lazily. Perhaps more importantly, it also produces the output as soon as it is available (so that one can actually use the calculator interactively and see the result of an expression immediately after entering it). Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
On Wed, May 6, 2009 at 4:56 PM, Alex Shinn alexsh...@gmail.com wrote: Hi, Phil Bewig pbe...@gmail.com writes: Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, due to the underlying promises that require numerous type conversions, so streams should be used only when the sequence of elements is truly infinite (such as mathematical series) or when there is some clear advantage of laziness (such as reducing the number of passes through a large data set). I also find that any data structure in general which is built on I/O works well as a stream. For the current NLP app I'm working on, I need to build a parse graph from a port. Slurping up the whole input at once could require too much memory, and also would prevent the parser acting as a proper (buffered) Unix filter. On the other hand, since the algorithm for determining how much text I need to work with is dynamic, I can't just read chunks at a time (the basic unit I want to work on is a sentence, but I don't know what a sentence is until the parse is finished). So I build the graph as a lazy stream of nodes, and the algorithm transparently expands only as much input as needed. From what I've seen Alejandro also uses streams primarily with I/O - it's a very natural combination. You are correct that streams and parsing go well together. One of the examples I wrote for SRFI-41 was a parsing library based on the calculator Wadler wrote for his 'list of successes' paper, but I dropped it because it was too long, and illustrated the list of successes technique with the eight-queens problem. Parsing also works well without streams, as decades of lex/yacc users can attest. 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. Some certainly don't belong in a general-purpose library -- if you need symbol-stream to convert the name of a symbol into a stream of characters, you can write it as part of your program. Sure: (define (symbol-stream sym) (string-stream (symbol-string sym))) That's just trivial and probably borderline enough that it isn't needed in the library. string-stream or equivalent functionality should be included, though, because the most efficient implementation of this may vary wildly depending on the Scheme implementation. However, the name may be unintuitive if you're not coming from a streams as I/O perspective. It may be both simpler to specify and easier to understand if you replace most of the foo-stream procedures with: (write-to-character-stream object) (display-to-character-stream object) When would it make sense to convert the name of a symbol to a stream of characters? Many -- such as stream-butlast -- make sense only for lists (which are materialized in their entirety) and not for streams (which may never be materialized). I think it's a little unfair to pick on stream-butlast when SRFI-41 includes stream-length, stream-list, stream-reverse, etc. As you yourself say, not all streams are infinite, and for finite streams these can be useful. Otherwise you'll repeatedly find people who when working entirely with streams (for type signature compatibility, and because all of their utilities are designed for streams, not lists), write things like (list-stream (butlast (stream-list stream))) when they really do need all but the last element of a stream they know to be finite. [I would argue the name and API should be changed to stream-drop-right to match SRFI-1, though.] 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 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
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
On Wed, May 6, 2009 at 10:32 AM, Phil Bewig pbe...@gmail.com wrote: Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, ... To the extent that this is true, it should be fixed, not perpetuated. Indeed, one of Scheme's greatest weaknesses is that the core functions of the language are not generic enough, and different representations of the same things are unduly difficult to intermix. Let us move towards perfection by removing an arbitrary distinction between two sequential data structures whose only real difference is that one is restricted to being finite. ~Alexey Radul P.S. On the technicalities of how to achieve this, I find the design of Clojure inspiring (http://clojure.org). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
