Re: local-eval on syntax-local-binding, bound-identifiers
Andy Wingo wi...@pobox.com writes: What if instead we implemented closure serialization somehow? Then we would handle procedural macros too, and bound-identifiers would still be sufficient. Maybe that idea is a little too crazy. Are we still talking about Scheme? The language with call-with-current-continuation? a little too crazy is not a criterion. Too complex to work or or with would be. Those are related, but not necessarily the same. -- David Kastrup
Re: Eval, tail calls, (current-module), and backward compatibility
Mark H Weaver m...@netris.org writes: (current-module) should be relevant only at the beginning of macro-expansion: before any program transformations are performed, (current-module) is baked into every symbol of the top-level form. (psyntax actually does this lazily, but the effect is the same). After that, (current-module) should be completely irrelevant to the rest of compilation and evaluation. It isn't if you call it in the code. Personally, I am not sure that it should reflect the second argument of eval if that is different from the current module in which eval has been called. Does R5RS have an opinion on modules and eval? Ideally, I think that `eval' should set (current-module) during expansion, but _not_ during evaluation. Then it can be properly tail recursive. However, some code out there might depend on the existing behavior, so I guess we can't change this, at least not in 2.0. Bummer. I am not sure. If you rebind current-module itself during expansion, you might be able to retain the currently visible behavior while being in tail-call position during execution. Of course, if any user meddles with the value of current-module other than just calling it, he is going to be in for surprises. -- David Kastrup
[PATCH] Universally-unique gensyms
This patch makes our gensyms universally-unique. Comments welcome.
Mark
From 18616afc6a3d5aca48da2e0819d08d7ff98de214 Mon Sep 17 00:00:00 2001
From: Mark H Weaver m...@netris.org
Date: Tue, 17 Jan 2012 08:15:10 -0500
Subject: [PATCH] Universally-unique gensyms
* libguile/symbols.c (scm_gensym): The gensym counter is now 128 bits,
initialized to a random number at the beginning of each session. This
counter is rendered as a 22 byte suffix of mostly base64 digits.
---
libguile/symbols.c | 69 +---
1 files changed, 60 insertions(+), 9 deletions(-)
diff --git a/libguile/symbols.c b/libguile/symbols.c
index 59aca00..cf82518 100644
--- a/libguile/symbols.c
+++ b/libguile/symbols.c
@@ -340,7 +340,9 @@ SCM_DEFINE (scm_string_ci_to_symbol, string-ci-symbol, 1, 0, 0,
/* The default prefix for `gensym'd symbols. */
static SCM default_gensym_prefix;
-#define MAX_PREFIX_LENGTH 30
+#define GENSYM_LENGTH 22 /* bytes */
+#define GENSYM_RADIX_BITS 6
+#define GENSYM_RADIX (1 (GENSYM_RADIX_BITS))
SCM_DEFINE (scm_gensym, gensym, 0, 1, 0,
(SCM prefix),
@@ -351,22 +353,71 @@ SCM_DEFINE (scm_gensym, gensym, 0, 1, 0,
resetting the counter.)
#define FUNC_NAME s_scm_gensym
{
- static int gensym_counter = 0;
-
+ static int initialized = 0;
+ static unsigned char digit_buf[GENSYM_LENGTH];
+ static char base64[GENSYM_RADIX] =
+ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789$@;
+ static char base4[4] = _.-~;
+
+ char char_buf[GENSYM_LENGTH];
SCM suffix, name;
- int n, n_digits;
- char buf[SCM_INTBUFLEN];
+ int i;
+
+ if (SCM_UNLIKELY (!initialized))
+{
+ int res = 0;
+ FILE *f = fopen (/dev/urandom, r);
+ if (f)
+{
+ res = fread(digit_buf, 1, GENSYM_LENGTH, f);
+ fclose (f);
+}
+ if (res == GENSYM_LENGTH)
+{
+ for (i = (GENSYM_LENGTH - 1); i = 0; --i)
+digit_buf[i] = (GENSYM_RADIX - 1);
+}
+ else
+{
+ /* This is a fallback in case /dev/urandom fails */
+ SCM tm = scm_gettimeofday ();
+ SCM seed = scm_sum (scm_product (scm_car (tm),
+ scm_from_int (100)),
+ scm_cdr (tm));
+ SCM random_state = scm_seed_to_random_state (seed);
+ SCM radix = scm_from_int (GENSYM_RADIX);
+ for (i = (GENSYM_LENGTH - 1); i = 0; --i)
+digit_buf[i] = scm_to_int (scm_random (radix, random_state));
+}
+ initialized = 1;
+}
if (SCM_UNBNDP (prefix))
prefix = default_gensym_prefix;
- /* mutex in case another thread looks and incs at the exact same moment */
+ /* ENHANCE-ME: make digit_buf thread-local to avoid the mutex */
+
+ /* lock the mutex */
scm_i_scm_pthread_mutex_lock (scm_i_misc_mutex);
- n = gensym_counter++;
+
+ /* increment digit_buf */
+ for (i = (GENSYM_LENGTH - 1); i = 0; --i)
+{
+ if (SCM_LIKELY (++(digit_buf[i]) GENSYM_RADIX))
+break;
+ else
+digit_buf[i] = 0;
+}
+
+ /* convert digit_buf to the base64 char_buf */
+ for (i = (GENSYM_LENGTH - 1); i 0; --i)
+char_buf[i] = base64[digit_buf[i]];
+ char_buf[0] = base4[digit_buf[0] 3];
+
+ /* unlock the mutex */
scm_i_pthread_mutex_unlock (scm_i_misc_mutex);
- n_digits = scm_iint2str (n, 10, buf);
- suffix = scm_from_latin1_stringn (buf, n_digits);
+ suffix = scm_from_latin1_stringn (char_buf, GENSYM_LENGTH);
name = scm_string_append (scm_list_2 (prefix, suffix));
return scm_string_to_symbol (name);
}
--
1.7.5.4
Re: [PATCH] Universally-unique gensyms
Hi Mark, Excellent! On Tue 17 Jan 2012 14:27, Mark H Weaver m...@netris.org writes: This patch makes our gensyms universally-unique. Comments welcome. I think the lazy initialization needs to happen within the lock. Also it would be nice to factor out the initialization of the random seed would be a nice helper to have in random.[ch]. You probably don't need to have a flag to support /dev/random (rather than urandom), because after all it's only seeding a PRNG (and not a cryptographically safe one, at that). Otherwise looks great to me! Andy -- http://wingolog.org/
Re: [PATCH] Universally-unique gensyms
On Tue 17 Jan 2012 14:57, Andy Wingo wi...@pobox.com writes: I think the lazy initialization needs to happen within the lock. Also it would be nice to factor out the initialization of the random seed would be a nice helper to have in random.[ch]. Sigh, mind racing ahead of the fingers: Also it would be nice to factor out the initialialization of the random seed to a helper in random.[ch] A -- http://wingolog.org/
Re: bound identifiers
Yes! see attachement! /Stefan On Tue, Jan 17, 2012 at 12:30 AM, Andy Wingo wi...@pobox.com wrote: On Mon 16 Jan 2012 22:56, Stefan Israelsson Tampe stefan.ita...@gmail.com writes: As you see, it's just wild west to get the racket code working. :) Can you give a stripped-down test case for this particular behavior? That code is paged into my and Mark's minds right now :) Andy -- http://wingolog.org/ (use-modules (srfi srfi-9)) (define-record-type data (make-data stx) data? (stx data-stx)) (define-syntax b (lambda (x) (syntax-case x () ((_ s) (with-syntax ((d (datum-syntax #'#f (make-data #'s #'(c #'s #'d)) (define (c s d) (let ((d (data-stx (syntax-datum d (pk s) (pk d) (bound-identifier=? s d))) (eval '(let ((t 1)) (b t)) (current-module))
Re: Eval, tail calls, (current-module), and backward compatibility
David Kastrup d...@gnu.org writes: Mark H Weaver m...@netris.org writes: (current-module) should be relevant only at the beginning of macro-expansion: before any program transformations are performed, (current-module) is baked into every symbol of the top-level form. (psyntax actually does this lazily, but the effect is the same). After that, (current-module) should be completely irrelevant to the rest of compilation and evaluation. It isn't if you call it in the code. Indeed, and that's potentially a problem. Personally, I am not sure that it should reflect the second argument of eval if that is different from the current module in which eval has been called. Does R5RS have an opinion on modules and eval? The R5RS has no module system, but it does mandate that `eval' requires a second parameter: the environment-specifier. It says almost nothing about these environment-specifiers other than to mandate a few standard procedures that must return them: (scheme-report-environment version), (null-environment version), and optionally (interactive-environment). version is the exact integer n in RnRS, e.g. 5 means the R5RS. The R5RS has no notion of a user-specified current environment. Indeed, there is no need for such a concept if it must always be passed as an explicit parameter to `eval'. Therefore, there's no need to save/restore the current environment (or anything like it) in the R5RS. The fact that the R5RS requires `eval' to be properly tail-recursive implies that it cannot do _anything_ after evaluation of the provided expression, because the continuation of the expression must be semantically equivalent to the continuation of `eval' itself. Therefore, the R5RS leaves no possible way for a complaint `eval' to restore the previous value of (current-module) after evaluation. Indeed, this is prohibited at a semantic level. Mark
Re: guile 2012
From: Andy Wingo wi...@pobox.com If I could vote for one thing to focus on in 2012, for the broader Guile community, I'd pick two things ;-) I'd pick Guile in Emacs, first of all. We have the hack power, the time is right, and we just need to focus on the task. By the end of the year we could have a credible, attractive offering. The other thing I'd like for us to focus on, in a stable-2.0 sense, would be the guildhall. There's some hacking that needs to be done there, but I'm hoping to get out a first workable prototype within a month or two, then let the meta-maintenance be driven by patches, while the repository of modules in the guildhall has time to grow and grow. Help here is much appreciated! :-) Hello All, I was a bit reluctant to throw out my comment on the mission statement, since lately I've been all talk and no action. Stupid reality getting in the way. :-( +1 for Guildhall. One weakness of Guile has been the difficulty in finding and using quality 3rd party libraries. I'd extend the Guildhall idea by also defining a way to download and build the various C library bindings that aren't currently packaged by the distros. Gtk, Cairo, Postgres, SDL, etc. I think Garnome or Gsrc could be pressed in to service. (Or Hydra?) (Garnome was once a makefile-based build system for Gnome that automated the downloading and building the whole Gnome ecosystem in a user's local directory. GNU Gsrc uses the same underlying system, and can be used to download and build much of GNU.) heresy Also, since so many people fear the parenthesis, I'd like to see some simple non-Lisp-like language become a supported language in Guile, but have it be able to directly use Guile's library functions, much like how different .Net languages use the same library. A Lua-like with Guile types and access to a subset of Guile functions, perhaps. I know that you want to believe that if your tech is good enough, people will learn Scheme. For many people, that just won't ever happen. It will always be a blocker for increasing the popularity of Guile. (Did I just propose Dylan?) /heresy Anyway, my two cents. Thanks, Mike
Re: guile 2012
I feel like I shouldn't get into this discussion for my huge lack of Guile (and Scheme in general) knowledge. But I will do in any case :-). On Tue, Jan 17, 2012 at 2:37 PM, Mike Gran spk...@yahoo.com wrote: heresy [snip] I know that you want to believe that if your tech is good enough, people will learn Scheme. For many people, that just won't ever happen. It will always be a blocker for increasing the popularity of Guile. (Did I just propose Dylan?) /heresy I disagree a bit with this point. People will learn Gule if there are nice libraries around it (what you said before). People is learning Clojure and it's being using for real work, and it has parenthesis. Ruby doesn't have parenthesis, but without Rails, may be it would have just been another language. Now there's hundreds of companies, freelancers that base their work in Ruby on Rails. And I'm sure there's plenty of more cases. I agree with the weakness of installing 3rd party libraries. I'm afraid that's true for every language. Guildhall will probably save Guile from being just another language used by a few. That was my half cent. :-) Aleix
