Re: Syntax-rules generate symbol

2013-09-10 Thread Taylan Ulrich B.
Panicz Maciej Godek writes: > I assume that the main reason for using this is efficiency (rather > than simplicity), because allegedly guile's continuations are rather > inefficient. > > On one hand, it's good to know that (and would be even better > to be able to find it out by skimming section

Re: is (web client) ready for use even for the simplest task?

2013-09-10 Thread Mark H Weaver
Darren Hoo writes: > (use-modules (web client)) > > (http-post "http://www.google.com/";) > > the POST request is sent without the Content-Length header RFC 2616 makes it clear that the Content-Length header is optional. > OK, let's add something to the body > > (http-post "http://www.google.c

Re: is (web client) ready for use even for the simplest task?

2013-09-10 Thread Nala Ginrut
On Tue, 2013-09-10 at 05:19 -0400, Mark H Weaver wrote: > Darren Hoo writes: > > > (use-modules (web client)) > > > > (http-post "http://www.google.com/";) > > > > the POST request is sent without the Content-Length header > > RFC 2616 makes it clear that the Content-Length header is optional.

Re: is (web client) ready for use even for the simplest task?

2013-09-10 Thread Mark H Weaver
Mark H Weaver writes: >> GET / HTTP/1.1 >> Content-Type: text/plain;charset=utf-8 >> Host: www.google.com >> Connection: close > > I just applied a fix for this to the stable-2.0 branch in git. In the > meantime, the workaround is to explicitly pass a content-type header > that specifies the cha

Re: is (web client) ready for use even for the simplest task?

2013-09-10 Thread Ian Price
Nala Ginrut writes: > But RFC 2616 wrote: > ---cut > body is not defined by this specification, but might be defined by >future extensions to HTTP. Content negotiation MAY be used to select >the appropriate response format. If no respons

Re: Syntax-rules generate symbol

2013-09-10 Thread Ian Price
Dmitry Bogatov writes: > Hello! > > Here is my implementation of for loop. I found lisp really extremely > flexible, but there is one problem --- more often then not I do not need > var part, so I do not care how it would be named --- all I care is that > it will not shadow any other bindings. >

Re: is (web client) ready for use even for the simplest task?

2013-09-10 Thread Mark H Weaver
Mark H Weaver writes: >> (http-post "http://www.google.com/";) >> >> the POST request is sent without the Content-Length header > > RFC 2616 makes it clear that the Content-Length header is optional. Sorry, I should have qualified this statement with "in this case", i.e. when there's no body.

Re: Syntax-rules generate symbol

2013-09-10 Thread Ian Price
Panicz Maciej Godek writes: > I assume that the main reason for using this is efficiency (rather > than simplicity), because allegedly guile's continuations are rather > inefficient. Primarily, it's an efficiency hack, but you can also make a case that it better if you can tell at a glance that t

Re: and-let* is not composable?

2013-09-10 Thread Stefan Israelsson Tampe
Ahh, I thought we nuked the unhygienic macros in our tool-chain, That is a BUG! Anyway can I suggest a Bug report where we 1) Make the unhygienic define-macros in the following files hygienic, - module/srfi/srfi-4.scm: module/srfi/srfi-69.scm: module

Re: and-let* is not composable?

2013-09-10 Thread Ian Price
Stefan Israelsson Tampe writes: > Ahh, I thought we nuked the unhygienic macros in our tool-chain, That > is a BUG! It is, but the issue is going to be around for as long as Guile users themselves write unhygienic macros. And it is important to note that just because you are using syntax-case[0]

Re: and-let* is not composable?

2013-09-10 Thread Ian Price
I have a few notes unrelated to those I've already mentioned in the thread. 1. Guile already has curried definitions in (ice-9 curried-definitions) 2. By turning your functions definitions into a macro, you've lost the ability to use them in a first class manner. 3. I would strongly recommend _