On 01/24/2014 11:22 AM, Mark H Weaver wrote:
I'd like to include a fully-featured SRFI-64 in the upcoming Guile
2.0.10 release, and to do so in such a way that most of the changes can
be folded back into your upstream version.
Great!
Where can I find your latest versions of testing.scm and
s
Hi Per,
I'd like to include a fully-featured SRFI-64 in the upcoming Guile
2.0.10 release, and to do so in such a way that most of the changes can
be folded back into your upstream version.
I'm aware of the earlier work by Sunjoong Lee in 2012, but it seems that
he made extensive stylistic change
> One related thing I sometimes lack is:
>=20
> (define-syntax-rule (thunk exp ...)
> (lambda () exp ...))
>=20
> (Found in Racket, notably.)
IMO, it's much more useful to have `λ', together with an Emacs hack
that makes it easy to type. In the last few years I even switched to
omitting the
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> One related thing I sometimes lack is:
>>
>> (define-syntax-rule (thunk exp ...)
>> (lambda () exp ...))
>
> My understanding is that that'd be (^ exp ...).
That's true given the c
Mark H Weaver writes:
> This patch fixes all of the thread-unsafe lazy initializations I could
> find in stable-2.0, using 'scm_i_pthread_once'.
I went ahead and pushed this, since I'm confident it's correct.
Mark
l...@gnu.org (Ludovic Courtès) writes:
> One related thing I sometimes lack is:
>
> (define-syntax-rule (thunk exp ...)
> (lambda () exp ...))
My understanding is that that'd be (^ exp ...). `thunk' might be nicer
for one's tastes, but some consistency between different people's code
would
Mark H Weaver skribis:
> From 625b1a68a7fcbe41abfd499937ecdf627a31530c Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Fri, 24 Jan 2014 00:21:17 -0500
> Subject: [PATCH] Implement SRFI-111 Boxes.
>
> * module/srfi/srfi-111.scm: New file.
> * module/Makefile.am (SRFI_SOURCES): Add srfi/srf
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
> Has it been considered to coalesce the box type with Guile's "variable"
> type? I can see two concrete differences:
>
> * External representation (*not* specified by SRFI-111)
>
> * Variables can be "unbound" (empty), boxes can't
Panicz Maciej Godek skribis:
> I think it would be best to extend SRFI-26 with the option of using
> <1>, <2>, ... placeholders, where the resulting lambda would get the
> arity indicated by the highest placeholder. Also, it should support
> nested expressions.
> Personally, I'd prefer it over th
Mark H Weaver writes:
> Here's an implementation of SRFI-111 Boxes for stable-2.0.
> What do you think?
>
> Mark
Has it been considered to coalesce the box type with Guile's "variable"
type? I can see two concrete differences:
* External representation (*not* specified by SRFI-111)
* Va
10 matches
Mail list logo
