<taylanub>Are there any worthwhile use-cases of set!ing a variable imported from a module ? I see this actually affects that module itself. <mark_weaver>*random-state* is an example of such a variable, that is exported from (guile) and intended to be set by the user. <mark_weaver>although all the random procedures also accept alternative random states, and only use that global one by default. <mark_weaver>global variables that are meant to be mutated by users is rarely optimal. what if more than one user wants to use the same module? they can step on each other's toes. <mark_weaver>for example, libgmp allows users to configure how storage will be allocated and freed by mutating globals, but that turns out to be very problematic in programs where multiple independent components use libgmp. For example, in programs that use libguile but also use libgmp directly, or use some other library that uses libgmp. *nalaginrut is hacking HHKB...or he can't hack anything... <ZombieChicken>As I recall CL has a method of internal documentation. Is there something similar in Scheme? Also, what is the syntax for comments? <mark_weaver>ZombieChicken: scheme has no standardized system for internal documentation, but Guile supports "docstrings", similar to Emacs docstrings. <mark_weaver>The standard Scheme comment syntax starts with a semicolon and goes to the end of the line. <mark_weaver>R6RS Scheme (which Guile supports) also includes a block comment syntax that can be nested. such comments start with #| and end with |# <ArneBab>ZombieChicken: what do you mean by syntax errors? <ArneBab>ZombieChicken: I’ll upload you answers I found myself <ArneBab>ZombieChicken: all I write is only for guile, though. <taylanub>ZombieChicken: You can have two kinds of syntax errors in Lisp: something that doesn't parse as a valid s-expression, and an s-expression that doesn't interpret as a valid Lisp program; the former is quite rare if you're using Paredit, the latter can happen when you forget the exact format of a Lisp form (e.g. `do' is tricky and hard to remember) or when you lose focus and e.g. forget a pair of parentheses where it isn't obvious, like <taylanub>writing (let (foo bar) baz) instead of (let ((foo bar)) baz). <davexunit>I'm working on a patch to add an alist->hash-table procedure to guile's native hash table implementation (not srfi-69 or rnrs) <dje42>OOC, why not srfi-69? [I don't know either very well.] <dje42>What's the difference b/w Guile's hash tables and srfi69, and can/will Guile's become srfi69 some day? <davexunit>guile's native implementation is more performant afaik <davexunit>all 3 implementations are mutually incompatible, according to mark_weaver ***enrytheermit is now known as `enrythe`ermit
<dje42>How do I read/write bytevectors to ports as raw bytes? <dje42>[e.g. r6rs binary output ports?] <mark_weaver>dje42: use get-bytevector-n, put-bytevector, etc, from the (rnrs io ports) module <dje42>I'm trying to decide how to r/w inferior memory in gdb from guile. I thought of using ports, but wasn't sure how that would work. <davexunit>I think I told you before that it is a port of srfi-69's procedure of the same name. <mark_weaver>I see two problems: you don't do any error checking, so if you pass in something other than an alist as the argument, it will probably crash or do something nasty. <davexunit>mark_weaver: I was about to ask about how much error checking I should be doing. <mark_weaver>and the other thing is that this always creates an equal?-based hash table. it would be good to have variants that create eq? and eqv? hash tables as well. <mark_weaver>I'm speaking loosely here, because actually, native guile hash tables don't keep track of what kind of table they are. instead, you must use the right add procedure and lookup procedure each time. in fact, that's the reason why it's not possible to unify native guile hash tables with SRFI-69 or R6RS hash tables. <davexunit>mark_weaver: well, thanks for the feedback. I have to go now but I'll fix the code up later. <mark_weaver>davexunit: anyway, for error checking: use SCM_VALIDATE_LIST to validate the alist, and then use scm_car and scm_cdr instead of SCM_CAR and SCM_CDR. <mark_weaver>the lowercase versions, which are functions, do error checking. the uppercase versions are macros that don't check. <ijp>I was just going to push a fix for the unfold-right doc bug dak reported, but should I was wondering if I should have used the srfi 1 wording instead <ijp>dak suggests "The tail of the list; defaults to @code{'()}." which to my mind is more sensible than "list terminator; defaults to '()." <ijp>but since the docs are *mostly* faithful to the srfi I figure it might be best to use their wording