Chicken Scheme Websockets
wiki.call-cc.org
wiki.call-cc.org
Here's the article: http://home.pipeline.com/~hbaker1/CheneyMTA.html
(with-websocket
(lambda ()
(send-message (string-append "you said: " (receive-message)))))
I'll add "porting Chicken web sockets to GNU Guile" to my ever growing todo list.It probably isn't very portable right now, unfortunately. It uses a lot of CHICKEN specific things to increase speed and memory efficiency but I'm totally open to making it more portable.
I'm very familiar with that cycle. I'm writing a game engine in Guile and I am constantly implementing something, throwing it away, and trying again. Every time you get a bit closer to the API you really want.
>It probably isn't very portable right now, unfortunately.
That's alright. Portable Scheme is cool, but I prefer using what the implementation gives me instead of restricting myself to RnRS. Especially so for something like networking code.
I might never get around to it, but if I find myself wanting to tackle a new project, I'll give porting this a try.
The parentheses is just a thing to get used to, once you have done that you see the structure, not the characters. It 's also a win for research in that no effort need to be wasted on syntax, which usually isn't the object of study anyway.
In fact, if you use scheme extensively you will probably use more syntax than most languages. Scheme and other lisps are very good at allowing you to create new syntax which is very helpful in creating DSLs which you will run across a lot in scheme libraries and the SRFIs.
Then again, not just every Lisp dialect but even pretty much every implementation has its own s-expression parser with its own extensions to s-expression syntax to make it most convenient to write code in, so there's not a very good decoupling after all. :-P Nevertheless it provides some benefits. Like being able to use something like "paredit" to edit code structurally, and making macro systems somewhat simpler (though hygienic macro systems cannot work with pure s-expression data; it must be annotated with lexical context).
You might find it hard to believe but I love Lisp syntax with all of its parentheses, and am explicitly against, for example, Sweet Expressions (SRFI-110). (Though SRFI-105 is fine.)
By the way another meaning of the word "syntax" actually refers to something within the data structures after the actual concrete syntax has been parsed away. For example when you have a list and its first element is the symbol "if", then that list is a usage of the if syntax. This syntax takes three arguments (further elements of the list): a test, consequent, and alternative. So "syntax" is something like a function here, except it operates during compilation and its arguments are unevaluated sub-structures (roughly, code snippets, though the syntax could interpret them however it wants, like for example how the "lambda" syntax's first argument is a parameter list). That's why we can say "in other languages you can only implement new functions; in Lisp you can also implement new syntax." (In the form of macros.)
My point is that the s-expression format has to be defined (obviously), e.g. you enclose lists in '(' and ')' characters, space symbols separate tokens, etc. In my world these rules are consequences of a defined syntax and saying there is no syntax is just wrong. The reader parses at some point a byte sequence and builds an AST. That Lisp/Scheme has such a simple syntax is a powerful feature of the language but saying it has no syntax just contributes to the belief of misinformed people that Lisp is some kind of strange Voodoo-language which is a bad thing as it is a powerful tool.
No you didn't. It is a huge misconception to think that just because you attended lectures, that you learned the material.
It's clear from that comment that you did not learn Scheme.
See: There is your mistake.
As for why: because they learned it and are able to recognize problems where using such a language would be beneficial. That's all there is to it, really.