<jcowan>manumanumanu: Yes, absolutely. But until now a parameter has always been bound to a global variable in actual use. Nobody uses parameters as procedure arguments, or returns a parameter from a procedure, or stores parameters in data structures -- yet. <jcowan>I wish someone research-minded (which I am not) would take up the question. ***daviid is now known as Guest3988
<bandali>in haunt, is it possible to get the site domain in the context of a post (e.g. when setting #:post-template) ? ***sneek_ is now known as sneek
***davie` is now known as davie_
<wingo>civodul: hey going to take a look at adding a new hash table to modules to record what bindings are intended to replace core bindings <wingo>so that a binding being a replacement is a property of module + name, rather than a property of the variable object <wingo>will make a corresponding change to the duplicates handler, to look in the interface to see if the var is a replacement instead of looking at the object-property on the variable <civodul>wingo: i'm fine with the current object-property hack <civodul>well properties are a hash table too <civodul>yes, it makes more sense for "replacement" to be a property of module + name <wingo>this enables re-export-and-replace <civodul>so sure, that sounds like a worthy improvement! <wingo>and prevents a re-export of a #:replace to unintentionally replace <wingo>*from unintentionally replacing <civodul>and it will allow us to just #:replace ((&external-error . &error)) <wingo>almost :/ currently #:replace does a module-ensure-local-variable <wingo>which i don't think we can change <wingo>so it would be #:re-export-and-replace ((&external-error . &error)) or something :/ <rekado>uhm, I just tried to work a little on mumi and I see a weird error in parsing the XML responses from Debbugs — but only when done with the web server, not when done on its own. Super weird. <civodul>"with the web server", you mean on the "web server" machine? <wingo>civodul: i am going to use the keyword #:re-export/replace unless you have a better idea <civodul>dunno, we can't hack module-replace! to DTRT? <wingo>civodul: if we could do that we would also be able to hack module-export! to DTRT <wingo>but i don't think it's possible. consider (define-module (foo) #:replace (bar)) ... (define (bar) 42) <wingo>at the point of the define-module, we don't know that there's going to be a local definition for bar <wingo>like bar could come from an imported module <wingo>right now #:replace causes a module-ensure-local-variable! on bar <wingo>so that you know if you see #:replace, the binding is local to the module <wingo>we could perhaps change to only create the local variable if there's not an imported variable <wingo>but i don't know if it's a compat risk <wingo>in that case we don't need #:re-export any more <rekado>civodul: no, I mean when something is called in a request handler of the Guile web server. ***zap` is now known as davie`
<wingo>i can imagine a user being surprised if an imported binding is re-exported, instead of their local binding <wingo>but, there are a number of pitfalls in the current system, perhaps an improvement is in order; if we could eventually kill #:re-export that would be nice :) <civodul>wingo: ah yes, i see, i agree that there would be compatibility concerns <wingo>but r6rs modules manage to figure this out automatically <wingo>so maybe like you say, we can just make a change <wingo>it would be a better system; risk is just compat. <wingo>maybe we can add a warning on module-ensure-local-variable! if the public interface already has an export under that name... <wingo>like define-module would add a tombstone for the internal name of the re-exported binding to some set associated with the module. if module-ensure-local-variable! would then define a binding for that name, it would issue a warning <civodul>so in what case exactly would one get different behavior? *civodul has a hard time wrapping his head around it <wingo>let's say you have (define-module (foo) #:export (raise)) (define (raise x) (throw 'foo x)) <wingo>guile has a binding for `raise' already. at the point of the define-module, guile wouldn't see the local definition, and would re-export the imported binding from (guile) <civodul>if you had #:re-export, not #:export, right? <wingo>sorry, i am making a shortcut. if we have #:replace automatically detect whether a binding is local or re-exported, that is the same as having #:export do it. so my question was, can we make #:export DTRT <wingo>if we can't, then we need #:re-export-and-replace <civodul>i mean, (define-module (foo) #:export (raise)) should definitely export the module-local "raise", not guile's <civodul>so to me, that part is non-negotiable ;-) <wingo>here is another option to get #:export and #:replace to DTRT regardless of whether bindings are local or imported: define-module re-exports imported bindings if there is no local binding. if a local binding is defined later, we arrange to update the public interface to replace the re-exported binding with the local binding <civodul>that means keeping track of top-level defines as the module is loaded, right? <wingo>that creates a window in which, for circular module graphs, users might see the "wrong" import. not nice <wingo>civodul: yes it means instrumentation into module-ensure-local-variable!, which is what (define ...) ends up calling <civodul>at this point i'd lean towards #:re-export-and-replace <wingo>(and=> (hashq-ref (module-re-exports module) name) (lambda (external-name) (module-add! (module-public-interface mod) external-name var)) <civodul>note that it's not a very common use case anyway, so having that extra #:re-export-and-replace is not that bad IMO <wingo>well, something we can think on for the future <wingo>#:re-export-and-replace it is <wingo>neat, this change correctly causes more replacement warnings <rekado>hmm, so this problem only happens when using the web server from (fibers web server). <wingo>ecraven: where can i find the graph.scm that you use to make the benchmark html output? ***ng0_ is now known as ng0
<wingo>ecraven: also how do you run chez scheme with r7rs support? <lispmacs>Hi, I was wondering how other Guile/Emacs users handle the issue of initializing load-paths for their project directories. Geiser has a geiser-guile-load-path variable which is supposed to used in conjunction with .dir-locals.el files, but I'm having trouble getting that to actually work. <sneek>lispmacs, you have 2 messages. <sneek>lispmacs, nckx says: chrislck says: this particular gnucash bug is resolved in recent maint. <nckx>TIL that sneek is cross-channel 😮