Re: [Chicken-hackers] importing modules of not yet loaded extensions
Felix writes: > Being able to import a module without requiring the loading of the > libary is necessary to allow cross-compilation. Chicken separates this > and I consider it a feature. Right, Christian pointed this out, too. I wonder though: Are modules which use `require-extension' cross-compilable then at all? Or does the compiler somehow prevent the actual loading from taking place, effectively replacing them by just an `import'? If that is indeed the case, why not make `import' behave like `require-extension' in the first place? Or am I missing something obvious? > Remember the mantra: > > If in doubt, use `require-extension'. Amen! Good night for now :-) Moritz ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] importing modules of not yet loaded extensions
From: Moritz Heidkamp Subject: [Chicken-hackers] importing modules of not yet loaded extensions Date: Sat, 11 Dec 2010 18:27:56 +0100 > Fellow Chickeneers, > > when investigating the problem described in ticket #450, Christian and I > had a discussion about whether it makes sense to be able to import > modules for which the extension defining them has not yet been > loaded. In the situation described in the ticket this was the case with > the posix extension. This might suggest that it's just some core unit > oddity but it does indeed work with modules defined in eggs, too. Just > try to run csi -n and (import chicken-doc) or any other egg you happen > to have installed and you'll notice that all necessary .import.so files > will be loaded but, of course, no binding will be imported at all. Thus > I figured it may make sense to make importing modules which aren't > actually loaded signal an error or at least output a warning to catch > problems like this early on. It may be that I am misunderstanding > something about import's purpose. However, we could not really settle > for a satisfying explanation or solution. Any comments? Being able to import a module without requiring the loading of the libary is necessary to allow cross-compilation. Chicken separates this and I consider it a feature. Remember the mantra: If in doubt, use `require-extension'. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] importing modules of not yet loaded extensions
* Alan Post [101211 18:42]: > Generally, however, it is a bit annoying that import is an > all-or-nothing thing, tightly binding sets of libraries together by > not being able to separate importing from loading. Your e-mail here > notwithstanding. Generally that is exactly what import does: Separating binding from loading. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] importing modules of not yet loaded extensions
On Sat, Dec 11, 2010 at 06:27:56PM +0100, Moritz Heidkamp wrote: > Fellow Chickeneers, > > when investigating the problem described in ticket #450, Christian and I > had a discussion about whether it makes sense to be able to import > modules for which the extension defining them has not yet been > loaded. In the situation described in the ticket this was the case with > the posix extension. This might suggest that it's just some core unit > oddity but it does indeed work with modules defined in eggs, too. Just > try to run csi -n and (import chicken-doc) or any other egg you happen > to have installed and you'll notice that all necessary .import.so files > will be loaded but, of course, no binding will be imported at all. Thus > I figured it may make sense to make importing modules which aren't > actually loaded signal an error or at least output a warning to catch > problems like this early on. It may be that I am misunderstanding > something about import's purpose. However, we could not really settle > for a satisfying explanation or solution. Any comments? > I want what I think is the opposite, which I asked about here: http://lists.nongnu.org/archive/html/chicken-users/2010-12/msg00094.html Jorg gave me several fantastic answers to that problem. I've decided to mimic the utf8 egg, if I can get away with it, and rebind existing symbols on import. It would be nice, however, if I could bind to an interface without loading the library, so the library could be loaded later. This would prevent me from having to import what amounts to a dummy library, only to later import the correct one and rebind all of its symbols. Generally, however, it is a bit annoying that import is an all-or-nothing thing, tightly binding sets of libraries together by not being able to separate importing from loading. Your e-mail here notwithstanding. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] importing modules of not yet loaded extensions
Fellow Chickeneers, when investigating the problem described in ticket #450, Christian and I had a discussion about whether it makes sense to be able to import modules for which the extension defining them has not yet been loaded. In the situation described in the ticket this was the case with the posix extension. This might suggest that it's just some core unit oddity but it does indeed work with modules defined in eggs, too. Just try to run csi -n and (import chicken-doc) or any other egg you happen to have installed and you'll notice that all necessary .import.so files will be loaded but, of course, no binding will be imported at all. Thus I figured it may make sense to make importing modules which aren't actually loaded signal an error or at least output a warning to catch problems like this early on. It may be that I am misunderstanding something about import's purpose. However, we could not really settle for a satisfying explanation or solution. Any comments? Moritz ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR: (#439) quasiquote changes
On 12/10/10 22:09, John Cowan wrote: > Thomas Chust scripsit: > >> few Scheme compilers would report (cons (x)) as a compile time error >> for lack of static type information. > > You don't need any, unless you are prepared to handle reassigning (as > opposed to rebinding) the name. As long as cons is not locally rebound, > you know it takes two arguments, and if it is locally rebound, you still > know how many arguments it takes if it is bound to a lambda, and can > blow it off if it is not. If that counts as static type information, > it's a pretty minimal variety. I would also be concerned about how to efficiently implement this... If (foo (a) (b) (c)) is to be compiled without values-splicing, it's easy enough to arrange for the return value of (a) to end up wherever the first argument of (foo ...) should go, and so on. With value-splicing, unless we can tell in advance (through difficult analysis) how many values each of (a), (b) and (c) return, we'd need to collect them together at run time and then put them into the activation record for (foo ...). ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
