IRC channel logs

2014-05-14.log

back to list of logs

<nalaginrut>morning guilers~
***linas_ is now known as linas
***wingo_ is now known as wingo
*taylanub wonders why #:use-module hasn't been deprecated in favor of an #:import argument that takes a list of module names
<taylanub>well that would have needed to happen long ago I guess
<lloda>I always do (define-module (...)) (import ...). is there a difference?
<taylanub>lloda: that sounds like mixing Guile modules and R6RS libraries; I generally use `use-modules' (should be same though I guess). I think a difference between having the imports/module-uses in the module definition as opposed to a following form is that if they're in the module definition, you can re-export identifiers from them .. imma try out
<taylanub>yup, can't re-export if loading modules in a subsequent form. (careful about recompilation by the way, looks like if it succeeds once, it works on subsequent tests no matter what...)
<nalaginrut>hmm...I never tried import
<nalaginrut>but seems no need to modify it at present
<taylanub>nalaginrut: I'd reserve its usage to pure R6RS code
<nalaginrut>taylanub: but R6Rs has no define-modules
<taylanub>nalaginrut: it has `library'
<taylanub>nalaginrut: I'm talking about (import ...), not #:import (doesn't exist)
<nalaginrut>alright, I thought you mean #:import
<nalaginrut>yes, it'd better for library/import
<nalaginrut>taylanub: how can you keep your code R6Rs? Do you use match?
<taylanub>nalaginrut: I don't
<nalaginrut>ok ;-)
<taylanub>though my bytestructures library could have been R6RS, I wish I'd done that from the beginning
<nalaginrut>I use POSIX functions and match and other out-R6Rs things heavily, so I don't think about R6Rs often
<nalaginrut>but anyway, I think the better way is to write general interface for portable in my code
<nalaginrut>s/portable/portability
<lloda>taylanub: you can re-export either way. I do (import ...) and then (re-export ...) works fine...
<taylanub>lloda: oh, I didn't notice there was also a separate `re-export' form
<taylanub>I find it a little unfortunate that such "imperative" constructs are supported at all; if modules/libs were purely declarative it would be a big help for external tools that want to analyze them, like track dependencies (I just wrote a hacky procedure to make R7RS define-library forms from Guile files with define-module and a use-modules form, but it's very limited)
<taylanub>but I guess there might be cases where one wants to load modules/libs conditionally or so? dunno
<lloda>I only use (import) at the top/module level, then it's just as declarative.
<taylanub>lloda: `import' can be shadowed by an import or top-level definition. a tool that is properly aware of Scheme syntax (like the compiler itself) could work around that problem, but it rules out the simpler possibility of simply reading the file and handling the module declaration "per hand", which is trivial for e.g. R7RS-small `define-library' forms (though R7RS-small also supports separate `import' forms)
<lloda>I see the point about redefinition. I expect Guile to warn me if I that happened, or shouldn't I?
<lloda>as it is, I read the import list using ... read.
<taylanub>I don't think a top-level definition for a core or imported binding should give a warning. as for imports, clashing ones are reported but dunno about shadowing "core" bindings (not sure ATM what exactly that entails, the (guile) module?)
***cluck` is now known as cluck
***karswell` is now known as karswell
***apb is now known as Guest45182