Re: syntax-local-value patch for discussion
Hi, Working on porting syntax-parse is a learning experience and I know understand how it uses syntax-local-value as a way to lookup a syntax object by joining the wraps together with the total wrap at the macro call. The question is if this really are the total wrap e.g. contains the history of all the previous variable and macro and syntax definitions. Is this so or are it a partial part of the history? Anyway syntax-parse works by defining pattern variables the hard core way and I have now changed that to a more standard way of implementation leading to skipping syntax-local-value (variables are stored in a struct and they does then not contain the correct wrap) but instead examine the syntax variables used and transport the wraps of the containing syntax variable of the struct. For this I have a messy and sloppy algorithm just to make it work - but I would like to have a syntax-join function that takes two syntax objects and join them correctly and robustly in the pressense of eventual marks or not. Anyway this now works, (define-syntax-class t (pattern (x:id y))) (define-syntax a (lambda (x) (syntax-parse x ((_ z:t ...) #'(+ z.y ...) (a (x1 1) (x2 2) (x3 3)) $1 = 6 /Stefan
Re: [PATCH] Universally-unique gensyms
David Kastrup d...@gnu.org writes: It does not appear to me that there is any locking that would prevent both ending up with the same random value. The thread-local 128-bit gensym counters are initialized from /dev/urandom. The kernel ensures that each `read' gets freshly generated random bytes, so there's no issue here. According to Wikipedia, this should cover GNU/Linux, OpenBSD, FreeBSD, NetBSD, Solaris, Tru64 UNIX, AIX, HP-UX, and MacOS X. On platforms without /dev/urandom, I have a fallback that uses the time, date, process ID, and a high-resolution timer if available. In this case, depending on the resolution of the timers, it is indeed feasible for two threads to end up with the same seed value, which would be bad. I think we can solve this problem by including the address of the scm_i_thread structure into the fallback seed. Thanks, Mark
Re: guile 2012
On Sat, Jan 7, 2012 at 10:34 AM, Andy Wingo wi...@pobox.com wrote: Greetings, Guilers! I hope this message finds all of you well: you, and yours, and all the beings in your lives. It was really a pleasure to hack with yall last year. yeah~what a great year for guile! I agree that Guile-emacs and Guildhall have the top priority. But the most expectation for me in future Guile would be the more complete multi-language support. We have some nice examples now, ecmascript/elisp/lua...besides, IIRC, the modules written by these inner language implementations could interact with each other, which would be an interesting feature. If someone plan to write a web-server/framework in Guile, it'll support these languages inherently. BTW, I'd like to know if this feature will go further in 2012?
Re: local-eval on syntax-local-binding, bound-identifiers
On Tue 17 Jan 2012 00:27, Andy Wingo wi...@pobox.com writes: TBH I think this is the best thing we can do for local-eval. We preserve flexibility for local-eval, make other experiments possible, and the local-eval implementation is a bit more perspicacious, as the scoping is more lexical (in the same file, even). Perspicuous, rather. How embarrassing! Andy -- http://wingolog.org/
Re: syntax-local-binding
Hello, I have now pushed an implementation of syntax-local-binding to stable-2.0, with the following documentation. In the spirit of Eli's note on Racket's syntax-local-value, it also works with identifiers that are bound at the module level or the top level. Comments and patches welcome. Cheers, Andy -- Scheme Procedure: syntax-local-binding id Resolve the identifer ID, a syntax object, within the current lexical environment, and return two values, the binding type and a binding value. The binding type is a symbol, which may be one of the following: `lexical' A lexically-bound variable. The value is a unique token (in the sense of `eq?') identifying this binding. `macro' A syntax transformer, either local or global. The value is the transformer procedure. `pattern-variable' A pattern variable, bound via syntax-case. The value is an opaque object, internal to the expander. `displaced-lexical' A lexical variable that has gone out of scope. This can happen if a badly-written procedural macro saves a syntax object, then attempts to introduce it in a context in which it is unbound. The value is `#f'. `global' A global binding. The value is a pair, whose head is the symbol, and whose tail is the name of the module in which to resolve the symbol. `other' Some other binding, like `lambda' or other core bindings. The value is `#f'. This is a very low-level procedure, with limited uses. One case in which it is useful is to build abstractions that associate auxiliary information with macros: (define aux-property (make-object-property)) (define-syntax-rule (with-aux aux value) (let ((trans value)) (set! (aux-property trans) aux) trans))) (define-syntax retrieve-aux (lambda (x) (syntax-case x () ((x id) (call-with-values (lambda () (syntax-local-binding #'id)) (lambda (type val) (with-syntax ((aux (datum-syntax #'here (and (eq? type 'macro) (aux-property val) #''aux))) (define-syntax foo (with-aux 'bar (syntax-rules () ((_) 'foo (foo) = foo (retrieve-aux foo) = bar `syntax-local-binding' must be called within the dynamic extent of a syntax transformer; to call it otherwise will signal an error. -- http://wingolog.org/
Re: Names for PEG Functions
On Wed 04 Jan 2012 19:12, Andy Wingo wi...@pobox.com writes: On Mon 03 Oct 2011 20:21, Noah Lavine noah.b.lav...@gmail.com writes: I hate to make more work for people, but I think the PEG module is almost ready for merging, and could probably be merged if we resolved this names issue. Any other thoughts? Have you updated the wip-peg branch? I don't remember who is waiting for whom any more, but reviewing the threads, it seems that we generally agreed on some name changes here. A kind ping here :) It would be lovely to get the peg stuff in for 2.0.5. Andy -- http://wingolog.org/
Re: Names for PEG Functions
Sorry for the delay. I haven't thought about the PEG stuff in a long time, but looking back, I'm pretty sure I didn't change the names yet. I will try to do it tonight (in GMT-5). I agree, it would be great to have the PEG stuff finished. On Thu, Jan 19, 2012 at 4:53 AM, Andy Wingo wi...@pobox.com wrote: On Wed 04 Jan 2012 19:12, Andy Wingo wi...@pobox.com writes: On Mon 03 Oct 2011 20:21, Noah Lavine noah.b.lav...@gmail.com writes: I hate to make more work for people, but I think the PEG module is almost ready for merging, and could probably be merged if we resolved this names issue. Any other thoughts? Have you updated the wip-peg branch? I don't remember who is waiting for whom any more, but reviewing the threads, it seems that we generally agreed on some name changes here. A kind ping here :) It would be lovely to get the peg stuff in for 2.0.5. Andy -- http://wingolog.org/
Re: [PATCH] Universally-unique gensyms
Replying to myself... David Kastrup d...@gnu.org writes: It does not appear to me that there is any locking that would prevent both ending up with the same random value. The thread-local 128-bit gensym counters are initialized from /dev/urandom. The kernel ensures that each `read' gets freshly generated random bytes, so there's no issue here. According to Wikipedia, this should cover GNU/Linux, OpenBSD, FreeBSD, NetBSD, Solaris, Tru64 UNIX, AIX, HP-UX, and MacOS X. On platforms without /dev/urandom, I have a fallback that uses the time, date, process ID, and a high-resolution timer if available. In this case, depending on the resolution of the timers, it is indeed feasible for two threads to end up with the same seed value, which would be bad. I think we can solve this problem by including the address of the scm_i_thread structure into the fallback seed. Better yet, I now include two memory addresses in the fallback seed calculation: an address of a freshly allocated heap cell, and an address from the local stack frame. The latter is guaranteed to be different for different threads, since each thread has its own stack. This fallback is still not ideal, but it's probably good enough as a last resort. Thankfully, almost all systems now have /dev/urandom. We can add support for additional platform-specific entropy sources as needed. Mark
Re: impressions on gc
Hello, As long as we're pinging people for 2.0.5, I don't think this patch ever got pushed. :-) I can't build master right now. This is partly my fault for doing so little sysadmin work that I still have libgc 7.1, but I still think this one should really, really be in 2.0.5 if the GC changes will also be there. Noah On Thu, Dec 8, 2011 at 3:10 PM, Andy Wingo wi...@pobox.com wrote: On Thu 08 Dec 2011 16:46, Chris K. Jester-Young cky...@gmail.com writes: Alas, part of that diff also breaks libgc 7.1 (which is the version that Debian currently has packaged), which lack the unmapping functions. Here's my diff to make it work again. Thanks for the patch! In the future a git-format-patch attachment is easiest. Though, if you like, we can set you up with commit access, I think. Request to be added to the `guile' group on savannah and we'll approve. I'll push this one though. Regards, Andy -- http://wingolog.org/
Improve `seed-random-state' in stable-2.0?
Hello all, `seed-random-state' is poorly implemented when passed a numeric argument. It converts the number to a decimal string, and then `scm_i_init_rstate' takes over and basically adds every 8th byte together to form the 64-bit internal state. The problem is that only about 3-bits of entropy is present in each character of the string, and then these are added together in an aligned fashion, which also loses a great deal of entropy. I haven't analyzed this carefully, but I'd be surprised if we preserve much more than 32-bits of entropy from the original seed. I know how to make this _much_ better, but here's the question: is it okay to change the behavior of the random number generator in 2.0? Or is it important that the same sequence of random numbers are generated from a given seed in the entire stable-2.0 series? Mark
Re: Names for PEG Functions
I've run into trouble because of my problems building master. I'll have to work around that, so it won't happen tonight. On Thu, Jan 19, 2012 at 8:54 AM, Noah Lavine noah.b.lav...@gmail.com wrote: Sorry for the delay. I haven't thought about the PEG stuff in a long time, but looking back, I'm pretty sure I didn't change the names yet. I will try to do it tonight (in GMT-5). I agree, it would be great to have the PEG stuff finished. On Thu, Jan 19, 2012 at 4:53 AM, Andy Wingo wi...@pobox.com wrote: On Wed 04 Jan 2012 19:12, Andy Wingo wi...@pobox.com writes: On Mon 03 Oct 2011 20:21, Noah Lavine noah.b.lav...@gmail.com writes: I hate to make more work for people, but I think the PEG module is almost ready for merging, and could probably be merged if we resolved this names issue. Any other thoughts? Have you updated the wip-peg branch? I don't remember who is waiting for whom any more, but reviewing the threads, it seems that we generally agreed on some name changes here. A kind ping here :) It would be lovely to get the peg stuff in for 2.0.5. Andy -- http://wingolog.org/
