Re: Syntax-rules generate symbol
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 6.13 of the manual), > but on the other it would be nicer if the compiler could trace the > usages of continuations and figure out whether a given one is > ever being re-entered, and optimize accordingly. Delimited/composable continuations don't have the efficiency problems of call/cc (some of which are inherent, and not related to Guile, from what I know), and I'd urge anyone to read the following critique of call/cc revealing other problems with it as well. :) http://okmij.org/ftp/continuations/against-callcc.html Guile supports "prompts" as the primitive behind higher-level delimited continuation operators, escape continuations, exceptions, etc. The relevant manual section is a nice read, though it might require more than a quick skim: (info "(guile) Prompts") The compiler might be able to optimize some usages of call/cc into the more efficient use of a delimited continuation, but after reading about call/cc and delimited continuations, it becomes a rather blurry line (IMO) which generalizes which, and on the meanwhile I find it most nice to use the abstraction that expresses the actual idea as directly as possible. And since breaking from a loop or returning from a block are inherently escape-only actions, I think it's actually nicer to use `let/ec' for those cases even in terms of code clarity etc.
Re: is (web client) ready for use even for the simplest task?
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.com/"; #:body "") > > Howcome the request now becomes an http GET request: > > 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 charset, like this: (http-post "http://www.google.com/"; #:body "" #:headers '((content-type text/plain (charset . "utf-8" > This is really ridiculous. You found a bug. It happens. There's no need to be obnoxious about it. Mark
Re: is (web client) ready for use even for the simplest task?
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. > I have to mention that Firefox seems not happy if the header not contain Content-Length. When I tested Artanis redirect function under FF, it's just halt anyway, but chrome is OK. And I fixed the issue by adding this to response: Content-Length: 0 That is so-called ridiculous. 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 response body is included, the response MUST include a Content-Length field with a field-value of "0". ---end > > OK, let's add something to the body > > > > (http-post "http://www.google.com/"; #:body "") > > > > Howcome the request now becomes an http GET request: > > > > 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 charset, like this: > > (http-post "http://www.google.com/"; >#:body "" >#:headers '((content-type text/plain (charset . "utf-8" > > > This is really ridiculous. > > You found a bug. It happens. There's no need to be obnoxious about it. > > Mark >
Re: is (web client) ready for use even for the simplest task?
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 charset, like this: > > (http-post "http://www.google.com/"; >#:body "" >#:headers '((content-type text/plain (charset . "utf-8" Sorry, this wasn't quite enough if the body is non-empty. In order to work around the bug, you also need to explicitly pass the content-length header, like this: (use-modules (web client) (rnrs bytevectors)) (let ((bv (string->utf8 "test"))) (http-post "http://www.google.com/"; #:body bv #:headers `((content-type text/plain (charset . "utf-8")) (content-length . ,(bytevector-length bv) More generally, when using (web client) for anything other than GET, you must explicitly provide a content-type header with charset, and also a content-length (if appropriate). The bug is fixed in stable-2.0 git. Mark
Re: is (web client) ready for use even for the simplest task?
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 response body is included, the >response MUST include a Content-Length field with a field-value of >"0". > ---end This section is a red herring, since it refers to the response to an OPTIONS request, not to a POST request itself. Section 4.3 Message Body says The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. What this means is, if you don't send a content length or transfer encoding header, then the server should not expect a body. I will note, in particular, that not sending a message is a distinct operation from sending a message of length 0. -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Re: Syntax-rules generate symbol
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. > > I think I can do it(did not tryed it) with `define-macro` and uninterned > symbols, but it mean give up beauty of syntax-rules. > > Masters of syntax-rules and syntax-case, please give me peace of advice. > > (define-syntax for > (syntax-rules (in => as) > ([_ (pattern as var in list) exp ...] >[for-each (lambda (var) (match var (pattern exp ...))) list]))) Actually, it couldn't be simpler, just add an extra pattern that passes in a dummy name. No (explicit) gensym needed. (define-syntax for (syntax-rules (in => as) [(_ (pattern as var in list) exp ...) (for-each (lambda (var) (match var (pattern exp ...))) list)] [(_ (pattern in list) exp ...) (for (pattern as var in list) exp ...)])) Now we get scheme@(guile-user)> (for (a in '(1 2 3)) (pk a)) ;;; (1) ;;; (2) ;;; (3) scheme@(guile-user)> (for (a in '(1 2 3)) (pk var)) ;;; :52:21: warning: possibly unbound variable `var' :52:0: In procedure #:52:0 (var)>: :52:0: In procedure module-lookup: Unbound variable: var Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. ,expand (for (a in '(1 2 3)) (pk var)) $4 = (for-each (lambda (var-1) (let* ((v var-1) (failure (lambda () (((@@ (ice-9 match) error) 'match "no matching pattern" v (a v)) (pk var))) '(1 2 3)) Var is unbound as expected. Though this is not obvious if you use ,expand on an example that doesn't use 'var', since Guile tries to clean up the names for readability. The reason it's okay to just pass in the dummy is because of how syntax-case and syntax-rules work. If a name is not passed explicitly into the macro, and it is not a reference to a top-level function or macro, then syntax-case or syntax-rules will rename it automatically. I took the liberty of fixing up the indentation, and changing the use of [] to a more idiomatic one, but there is still one obvious issue with your macro. "exp ..." means 0 or more expressions. If you had intended one or more, as is more usual in this type of macro, you'll want to say so explicitly with something like "exp exps ...". Cheers -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Re: is (web client) ready for use even for the simplest task?
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. (web client) does add a Content-Length header when there's a non-empty body. It should also add a Content-Length header when an empty body is provided, but it doesn't. I'll fix this soon. Anyway, the work-around I provided adds a Content-Length header explicitly, so it works around this problem too. For the record, I didn't write this code; I'm just fixing it. Mark
Re: Syntax-rules generate symbol
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 the continuation will never be stored, similar to how we have conventions for predicates and so forth. > On one hand, it's good to know that (and would be even better > to be able to find it out by skimming section 6.13 of the manual), It is documented in section 13.5.1. > but on the other it would be nicer if the compiler could trace the > usages of continuations and figure out whether a given one is > ever being re-entered, and optimize accordingly. Well, it can sometimes, but it's a hard analysis in general. -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Re: and-let* is not composable?
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/srfi/srfi-4/gnu.scm:
module/system/base/syntax.scm:
module/system/base/language.scm:
module/system/base/lalr.upstream.scm:
module/statprof.scm:
module/oop/goops.scm:
module/oop/goops/save.scm:
module/oop/goops/accessors.scm:
module/texinfo/plain-text.scm:
module/ice-9/i18n.scm:
module/ice-9/time.scm:
module/ice-9/serialize.scm:
module/ice-9/session.scm:
module/ice-9/optargs.scm:
module/scripts/snarf-check-and-output-texi.scm:
module/scripts/lint.scm:
module/sxml/ssax/input-parse.scm:
module/sxml/transform.scm:
module/sxml/upstream/SXPath-old.scm:
module/sxml/upstream/SSAX.scm:;
module/language/tree-il/primitives.scm:
module/language/ecmascript/base.scm:
module/language/assembly/disassemble.scm:
module/rnrs/bytevectors.scm:
And also change the defmacro forms in,
-
module/system/base/lalr.scm:
module/texinfo/reflection.scm:
module/ice-9/and-let-star.scm:
module/ice-9/calling.scm:
module/ice-9/expect.scm:
module/ice-9/optargs.scm:
module/scripts/generate-autoload.scm:
module/scripts/generate-autoload.scm:
/Stefan
On Mon, Sep 9, 2013 at 11:34 PM, Ian Price wrote:
> Stefan Israelsson Tampe writes:
>
> > (use-modules (srfi srfi-2))
> > (use-modules (srfi srfi-1))
> >
> > (define-curried (string-matches pattern string)
> >(and-let* ((match-struct (string-match pattern string))
> > (count (match:count match-struct)))
> > (map (lambda(n)(match:substring match-struct n))
> > (iota (1- count) 1
> >
> > scheme@(guile-user)> (string-matches "([a-z])" "a")
> > $4 = ("a")
> >
> >
> > ,exp ((string-matches "([a-z])") "a")
> > $5 = ((lambda (string-871)
> >(let ((match-struct-876
> >(string-match "([a-z])" string)))
> > (if match-struct-876
> >(let ((count-880 (match:count match-struct-876)))
> > (if count-880
> >(map (lambda (n-883)
> > (match:substring match-struct-876 n-883))
> > (iota (#{1-}# count-880) 1))
> >#f))
> >#f)))
> > "a")
> >
> > And we see that string is not managed correctly. Is this a bug? I
> > can't understand why this is not treated as intended!
>
> The problem is one that occurs when hygienic and non-hygienic macros are
> mixed. Here, and-let* is the non-hygienic one. Basically, in a hygienic
> macro, you carry around a bunch of context to allow you to refer to the
> right variable names. Then defmacro comes along, strips all that away,
> and uses the raw symbol names.
>
> We can fix and-let* to be hygienic, that's pretty easy, but I'm not sure
> what you can do about this in general. It's not like you can pass in the
> gensymed name, because that will break the way people who for some
> reason still right defmacros expect them to work.
>
> Dunno, maybe I'm just missing some insight here.
>
> --
> Ian Price -- shift-reset.com
>
> "Programming is like pinball. The reward for doing it well is
> the opportunity to do it again" - from "The Wizardy Compiled"
>
Re: and-let* is not composable?
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], doesn't mean you are writing hygienic macros. One of my first patches to Guile was hygiene fixes in the define-record-type form in (rnrs records syntactic). Fixing it in our own backyard is a start, but there is no need to do it all at once, and it could be some nice low hanging fruit for new contributors. > Anyway can I suggest a Bug report where we Then add it to the tracker :) 0. syntax-rules is fine, modulo al petrofsky/oleg style craziness -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Re: and-let* is not composable?
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 _not_ using define-macro, and even more so, not mixing define-macro and syntax-rules in a macro. Syntax-case is as powerful as defmacro, and in most practical cases, about as much writing. 4. What your macro does is not currying, it is partial application. Those are different things. Currying refers to the process of turning a function of n arguments into an n-nested set of 1 argument functions. Partial application is, well, not supplying all the arguments to a function. You can have partial application without currying, as your macro shows. -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
