Re: Request for feedback on SRFI-126
Panicz Maciej Godek writes: > Even more broadly than the summaries I already gave, I could say: > I would like us to reach a state where one can think "I need to > write application X? Let's do it in Scheme since it's such a neat > language," and then proceed to install standard Scheme libraries > A, B, and C into my system either with the distro's package > manager or a Scheme package manager (written in standard Scheme, > working with my favorite implementation), proceed to write my > application in standard Scheme using those libraries, and have > this application X using libraries A, B, and C work across Guile, > Racket, Chicken, Gauche, Kawa, and what have you, without having > to change a single line of code. > > Maybe you should explain why there are so many implementations of > Scheme in the first place? (That isn't the case for Python, Java or > Perl) Because it's too easy to make a standards-compliant implementation because the standards ask for too little from compliant implementations. And/or other reasons; don't really know your intent with the question. > [...] > > That's the Grand Dream, but I don't even think it's *that* far > away: > > Had I such a "Grand Dream", I'd go with Python, because they already > have that. Python still lacks many of Scheme's greatest features. :-) > Scheme has very different traits, and very different purpose. The > position of Python stems from its particular notion of elegance, which > -- although isn't as extreme as Scheme's -- is easier to grasp to the > masses. This especially regards syntax. Python has a very intuitive > syntax for its basic notions (including dictionaries). Lisp has "all > those hairy parentheses", which apparently very few people can > appreciate, although they help to work with the code greatly, allowing > to see beyond language's limitations. S-expression syntax, allowing things like Paredit, is one of Scheme's many virtues over other languages. So I would like to use Scheme, not Python. Currently I can't. (I can use Guile, but it still misses some "batteries.") > I find it daunting that it took us 106 whopping SRFIs to reach a > *basic* socket API! Scheme could have been taking over the world > by now. : -) > > Not sure what you mean by "taking over the world". That there will be > many people using it? There won't. That there will be important > systems based on it? Don't think so. Why not? > Scheme's power to change the world doesn't stem from standardized > APIs, but (hopefully) from SICP and the way it affects thinking about > computer systems. Why even bother with something like Guile if the only worth of Scheme were pedagogical? > And as amazing as it would be if that huge pool of libraries > existed specifically as Guile modules, I'm not sure if it's > realistic. > > Somehow I can't get amazed with that vision. > The best thing that Scheme does for programming is that it promotes > writing software that can be read, and not only executed. What you > claim to be essential here seems to be a rather minor detail from that > point of view. Libraries *are* software. Currently people *don't* write any of that "software that can be read" except in small groups. > Python lacks many of Scheme's greatest features. > > The advantage of which rarely manifests in everyday practice, > especially if you're not used to working with s-expressions (most > programmers I know haven't got a clue what those are). > I recommend that you read this: > http://norvig.com/python-lisp.html I'm wondering more and more why you use Scheme if you think it has no advantages over Python. > > "Better" by which standards? > > By the above explained standards. Maybe the pool of libraries is > more important than flow of users, but still, if a Racket user can > install Guile and immediately feel somewhat at home because all > standard Scheme parts are still there, that could gain us a lot. > > I sometimes use Racket to teach people to program in Scheme. That's > because it's cross-platform and comes with a GUI that anyone can > comprehend quickly. It is terribly inconvinient compared to emacs, but > most people are unable to get through the basics of emacs. And here's > where the revolution stops. I was talking about programmers using Racket to write software, not students using Racket to learn computer science. > A good standard can be in line with lots of different values I > think. And the (lack of) standardization currently works as a > "wall" that makes the flow of users simply nigh impossible (have > to rewrite most of one's code for to work on another > implementation), so a good standard would mean abolishing that > wall, even if people won't immediately want to cross the now open > boundaries. It abolishes a fundamental limitation. > > I shouldn't think so. I was once porting a fairly advanced Guile > appl
Re: Request for feedback on SRFI-126
On 28/09/15 00:20, Panicz Maciej Godek wrote: > Delimited continuations are an academic curiosity, and sockets and > regexps are just a specific domain (I'm sure you could easily find > plenty of others; anyway, they are by no means fundamental) Sorry, but I have to comment on this. So did people think of lambdas, map, reduce and the rest of list/array collective manipulation procedures, but look at the new Java/C++ et al standards. It just so happened that they have implemented them decades after they achieved their normal use in languages like Lisp and Scheme. I wonder when we'll finally get tail calls and named lets in the mainstream languages :). I fully understand Taylan's point of view. Scheme has more expressive power than any other dynamic language I have encountered. I am trying to use it for day-to-day tasks which used to be difficult only because the batteries were not included. Maybe for you it's a nice little language to demo great coding ideas, but it can be a practical platform as Guile demonstrates. Unfortunately for the novice programmers the practicality of Guile only becomes clear after one can use its nifty FFI to patch up the still unimplemented features. In a sense, I don't think it is so necessary to have a practical Scheme standard as long as there is at least one implementation that can be used to perform with ease 90% of tasks a modern programmer needs to tackle. And, yeah, I'd love to see the core scheme kept clean. All the best...
Re: Request for feedback on SRFI-126
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer"): > So we are back to square one: anyone who wants to use Scheme for > something real needs to pick a specific implementation, Which is true for other programming languages as well: C, C++, Python, .. For me, in practice, C/C++ is gcc, Python is CPython, sh is bash, Scheme is Guile, and the OS is Linux. Marko
Re: Request for feedback on SRFI-126
Marko Rauhamaa writes: > taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer"): > >> So we are back to square one: anyone who wants to use Scheme for >> something real needs to pick a specific implementation, > > Which is true for other programming languages as well: C, C++, Python, > .. > > For me, in practice, C/C++ is gcc, Python is CPython, sh is bash, Scheme > is Guile, and the OS is Linux. Unfortunately, Scheme is also Racket, Chicken, Kawa, Gambit, Gauche, Chibi, and so on. Racket individually has considerable power so they would benefit the least from this, but a bridge between the user-bases of the others would probably have significant benefits to all of them. (And I suppose Racket would eventually support such an RnRS too; why not if they support even ALGOL.) Knowing that one doesn't have to choose and stick to an implementation would also make Scheme as a whole more attractive. Many people first hear of just "Scheme" and not immediately "Guile," then they see that one can't do anything serious with "Scheme" (standard), and the image stains every Scheme implementation. Guile could make a bold move like Racket and say that it's not Scheme anymore, not caring about further RnRS at all, but I'm not sure if it would be a good move with Guile's current stand-alone popularity. (I hope that doesn't sound negative. Of course I'd *love* Guile to become for Scheme what GCC is for C, but I don't see that becoming the case any time soon. Racket is nearer to that, though they don't even call themselves Scheme.) Taylan
Re: Request for feedback on SRFI-126
Taylan Ulrich Bayırlı/Kammer writes: > I will probably work on a delimited continuations SRFI, heavily inspired > by Guile's call-with-prompt, since I find it *immensely* more easy to > grok than shift/reset and prompt/control because those mingle together > the "stack slice" and the "handler" code whereas call-with-prompt > clearly separates them. This could be interesting! I wonder how hard it will be to do? IIRC from reading wingolog, delimited continuations need to be planned in at a pretty low level, and I wonder how hard it will be for many implementations to bring them in who don't have them at present? Will be interesting to see! Anyway, interesting to hear, good luck! - Chris
Re: Request for feedback on SRFI-126
Christopher Allan Webber writes: > Taylan Ulrich Bayırlı/Kammer writes: > >> I will probably work on a delimited continuations SRFI, heavily inspired >> by Guile's call-with-prompt, since I find it *immensely* more easy to >> grok than shift/reset and prompt/control because those mingle together >> the "stack slice" and the "handler" code whereas call-with-prompt >> clearly separates them. > > This could be interesting! I wonder how hard it will be to do? IIRC > from reading wingolog, delimited continuations need to be planned in at > a pretty low level, and I wonder how hard it will be for many > implementations to bring them in who don't have them at present? Will > be interesting to see! > > Anyway, interesting to hear, good luck! Thanks for the encouragement! Yeah, AFAIUI delimited continuations are a very fundamental feature. They can't really be implemented in call/cc for instance, as some people used to claim I think. (And that's why they need to be part of the language, as I see it; if the language itself doesn't have them, there's no way to have them, and no way to implement all the things they make possible on a higher level.) Of course it might be useful not to entirely turn one's back against implementations that have a difficulty with that feature (it's pretty new compared to some other Scheme features AFAIK, and going fairly deep into the implementation), so it could be left optional, but sanctioned as the official API for implementations to support, if they support it in any way at all. Like SRFI-106 does for sockets. Taylan
Re: Request for feedback on SRFI-126
2015-09-28 10:13 GMT+02:00 Taylan Ulrich Bayırlı/Kammer < taylanbayi...@gmail.com>: > Panicz Maciej Godek writes: > > > > Maybe you should explain why there are so many implementations of > > Scheme in the first place? (That isn't the case for Python, Java or > > Perl) > > Because it's too easy to make a standards-compliant implementation > because the standards ask for too little from compliant implementations. > And/or other reasons; don't really know your intent with the question. > Because Scheme is constructed by removing unnecesary features, rather than by adding them. > [...] > > > > That's the Grand Dream, but I don't even think it's *that* far > > away: > > > > Had I such a "Grand Dream", I'd go with Python, because they already > > have that. > > Python still lacks many of Scheme's greatest features. :-) > The MIT course 6.01 that replaces SICP introduces a language Spy, which is a mixture of Python and Scheme. Might be worth checking out, although I don't really think so. Anyway, if anyone's interested, it can be found here: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-01sc-introduction-to-electrical-engineering-and-computer-science-i-spring-2011/Syllabus/MIT6_01SCS11_notes.pdf (page 89) > > > Scheme has very different traits, and very different purpose. The > > position of Python stems from its particular notion of elegance, which > > -- although isn't as extreme as Scheme's -- is easier to grasp to the > > masses. This especially regards syntax. Python has a very intuitive > > syntax for its basic notions (including dictionaries). Lisp has "all > > those hairy parentheses", which apparently very few people can > > appreciate, although they help to work with the code greatly, allowing > > to see beyond language's limitations. > > S-expression syntax, allowing things like Paredit, is one of Scheme's > many virtues over other languages. So I would like to use Scheme, not > Python. Currently I can't. (I can use Guile, but it still misses some > "batteries.") > > > I find it daunting that it took us 106 whopping SRFIs to reach a > > *basic* socket API! Scheme could have been taking over the world > > by now. : -) > > > > Not sure what you mean by "taking over the world". That there will be > > many people using it? There won't. That there will be important > > systems based on it? Don't think so. > > Why not? > Because no one does them. > Scheme's power to change the world doesn't stem from standardized > > APIs, but (hopefully) from SICP and the way it affects thinking about > > computer systems. > > Why even bother with something like Guile if the only worth of Scheme > were pedagogical? > No. I never said it's the only worth. I find Guile very practical and convinient tool, despite its flaws. > > And as amazing as it would be if that huge pool of libraries > > existed specifically as Guile modules, I'm not sure if it's > > realistic. > > > > Somehow I can't get amazed with that vision. > > The best thing that Scheme does for programming is that it promotes > > writing software that can be read, and not only executed. What you > > claim to be essential here seems to be a rather minor detail from that > > point of view. > > Libraries *are* software. Currently people *don't* write any of that > "software that can be read" except in small groups. > Small groups are a good start, I guess. > Python lacks many of Scheme's greatest features. > > > > The advantage of which rarely manifests in everyday practice, > > especially if you're not used to working with s-expressions (most > > programmers I know haven't got a clue what those are). > > I recommend that you read this: > > http://norvig.com/python-lisp.html > > I'm wondering more and more why you use Scheme if you think it has no > advantages over Python. > I don't think so, and I never said that. Python has some inherent limitations that Scheme manages to avoid, because it isn't over-specified. I gave that link because it comes from one of the greatest Lisp advocates -- and yet he claims that "Some just couldn't get used to Lisp syntax in the limited amount of class time they had to devote to it", and also "Although some people have initial resistance to the [Python's indentation as block structure]/(Lisp parentheses), most come to [like]/(deeply appreciate) them." Even within the Scheme community there appear voices complaining on the Lisp syntax, like SRFI-105, SRFI-110 or SRFI-119. > If I can't *rely* on the constant-time factor, that's useless. If > > it's reliable, then you specified something effectively equivalent > > to a hash table API. > > > > Sure. The only difference is the cognitive overhead. If you could use > > plain "cons" for constructing hash tables and vectors, that would be a > > big win, because you would remove another weakness and restriction > > that makes this additional feature of yours necessary. > > How can one implement s
[ANN] gzochi project development release 0.9
Hi everyone, I'm pleased to announce the ninth development release of the gzochi game development framework. The project description, from Savannah: gzochi (/zoʊ-tʃiː/) is a framework for developing massively multiplayer online games. A server container provides services to deployed games, which are written in Guile Scheme, that abstract and simplify some of the most challenging and error-prone aspects of online game development: Concurrency, data persistence, and network communications. A very thin client library can be embedded to provide connectivity for client applications written in any language. This release is focused on quality and stability; dozens of memory leaks and functional defects have been resolved, and the server can more reliably handle a large volume of messages and connected clients. In addition to that, the release includes a handful of new features: * The distribution now ships with a suite of performance benchmarks for gzochid, the gzochi server container * New statistics about message transmission are published to the web administrative console * ...and more! See the NEWS files in the distribution for details This is a development release; the framework is likely not bug-free. Nonetheless, there's extensive server and client documentation, and the distribution includes three example games with heavily-annotated source code. For more information, visit the web site at http://www.nongnu.org/gzochi/ or check out the project page on Savannah, at http://savannah.nongnu.org/projects/gzochi/ -- you can pick up the release from the downloads section. Regards, Julian
