Peter Bex has pointed out that my example in
http://lists.nongnu.org/archive/html/chicken-hackers/2013-05/msg00031.html
was not very clear about the problem at hand; let my clarify.
I wanted to show that we can proof the body of `(delay expr)` being
evaluated any random number of times.
On May 13 2013, Jörg F. Wittenberger wrote:
Peter Bex has pointed out that my example in
http://lists.nongnu.org/archive/html/chicken-hackers/2013-05/msg00031.html
was not very clear about the problem at hand; let my clarify.
...
NB: Things would be even stranger, if we would cause the
From: John Cowan co...@mercury.ccil.org
Subject: Re: [Chicken-hackers] [PATCH] inline-syntax and
require-extension-for-syntax
Date: Sun, 12 May 2013 19:46:52 -0400
Felix scripsit:
1) require-extension-for-syntax/use-for-syntax, which does
the same as the often occurring idiom
On Mon, May 13, 2013 at 10:44:53AM +0200, Felix wrote:
Hello!
Hi!
I know this is going to be controversial, but I'd like to un-deprecate
the use of plain procedures as syntax-transformers. The way it is
currently implemented, using a procedure can be seen as a simple
default
Felix scripsit:
I know this is going to be controversial, but I'd like to un-deprecate
the use of plain procedures as syntax-transformers. The way it is
currently implemented, using a procedure can be seen as a simple
default (er-transformer). I find the use of transformer-constructors
On May 13 2013, Peter Bex wrote:
On Mon, May 13, 2013 at 10:44:53AM +0200, Felix wrote:
Hello!
Hi!
I know this is going to be controversial, but I'd like to un-deprecate
the use of plain procedures as syntax-transformers. The way it is
currently implemented, using a procedure can be seen
From: John Cowan co...@mercury.ccil.org
Subject: Re: [Chicken-hackers] plain lambdas as syntax transformers
Date: Mon, 13 May 2013 05:47:24 -0400
Felix scripsit:
I know this is going to be controversial, but I'd like to un-deprecate
the use of plain procedures as syntax-transformers. The way
Peter, Joerg:
However, it's confusing to newbies, you can't really explain what
exactly er-transformer *does*. Also, the extra typing isn't that bad
and I'm not sure we should be subtly encouraging the use of ER
transformers over IR transformers by making them less work to type
(IR transformers
Felix scripsit:
So wwhat would be the right default, if I may ask?
When there is no clear preferred alternative, the right default is no
default: prefer explicit over implicit in this case.
--
John Cowan co...@ccil.org http://ccil.org/~cowan
Linguistics is arguably the most hotly contested
From: Peter Bex peter@xs4all.nl
Subject: Re: [Chicken-hackers] plain lambdas as syntax transformers
Date: Mon, 13 May 2013 12:34:16 +0200
On Mon, May 13, 2013 at 12:09:09PM +0200, Felix wrote:
Peter, Joerg:
But the subtle damage it does to the newbies brain when reading
existing code to
On Mon, May 13, 2013 at 12:49:43PM +0200, Felix wrote:
It makes it harder to explain what exactly er-macro-transformer does
(ie, nothing?).
I'm unable to see the problem with implicitly wrapping an
er-macro-transformer around a given lambda. That's fairly easy to
understand.
True. Like
Jörg F. Wittenberger scripsit:
BTW: To those concerned with r7rs: I really don't like that the draft
still leaves it undefined what the result of (force promise) is,
if the promise returns multiple values. force/delay are not that
complicated to implement. The way the r7rs draft is now, one
On May 13 2013, John Cowan wrote:
Felix scripsit:
So wwhat would be the right default, if I may ask?
When there is no clear preferred alternative, the right default is no
default: prefer explicit over implicit in this case.
May I 2nd that.
Felix, I don't want to upset you with the
On Sun, May 12, 2013 at 10:49:09PM +0200, Felix wrote:
Attached are some patches for adding two small enhancements:
1) require-extension-for-syntax/use-for-syntax, which does
the same as the often occurring idiom
(begin-for-syntax (require-library FOO))
(import-for-syntax
14 matches
Mail list logo
