[Chicken-hackers] simplifying loading/linking/import (long)
Ok, let's start from scratch... * We can't change the existing machinery without breaking an awful lot of code, so any solution must be an addition to what we currently have. * The basic entities we have to deal with are "compilation units", bodies of code, either statically linked into an executable (or library) or dynamically loaded. * These compilation units may or may not contain one or more "modules", which are separate namespaces (or "bindings") over those bodies of code. * "import" incorporates bindings into the current environment, either globally or inside another namespace (module). We want to _automatically_ make the code associated with that namespace available, regardless of the nature of the compilation unit that contains that code. Is this interpretation correct? * Making the code inside a compilation unit available happens either by loading, resulting at one point of time in a call to "load" (this includes interpreted code in source form, which is just another flavor of a compilation unit), or it happens by declaring an externally available entry-point, currently via "(declare (uses ...))". (This needs a more obvious or natural syntax at some point, but that isn't relevant right now) * Declaring an entry-point into the current compilation unit (basically the current source file) takes place by "(declare (unit ...))". * The last 2 points are important if we want to support static linking. Loading is in this case the simpler operation, as the entry-point always has the same name. For static linking the entry-points need to be named differently (there might be ways around this limitation, but to keep things simple, let's not consider that right now.) * So, if we create a "registry" of linked/loaded compilation units, "import" can consult this registry and check whether a compilation unit of the same name is already registered and, if not, default to loading a ".so" or ".scm" with the same name. If the latter is not found, we have an error. If it is found, add it to the registry. * "import" incorporates bindings from a set of available modules, also registered somewhere, specifically in ##sys#module-table. Should it also handle compilation-units for which no bindings exist (i.e. all bindings are unqualified)? This is only useful at toplevel, or, in other words, not inside a module. This will also bring up the question whether such a behaviour might lead to head-scratching in case a module should exist, but the binding-information is unavailable for some erroneous reason. * Declaring an externally available entry-point must add the compilation unit associated with it to the registry. (Sorry, now it gets complicated...) * libchicken contains a number of entry-points, one for each library unit that comes with the core system. The registry must already have entries for these. Users might want to have to use a similar physical structure of their code, so we will have to provide means to add "default" registry entries, I think (I'm not completely sure right now - the resolution of the entry-points happens automatically by the linker, but we have to make later "import"s aware of this.) * Currently "(declare (unit ...))" calls the entry-point, _initializing_ the compilation unit. Later "import"s will just incorporate the bindings. Do we want to initialize the compilation unit on the first "import"? If yes, we need to separate the notions of declaring an externally available entry-point and calling it, the latter being done (we hope) transparently by "import". * The same situation arises with loaded compilation units. Consider a dynamically loaded ".so" that holds several compilation units: When is the entry-point of each contained compilation unit called? On first "import"? I this case it makes sense to generalize this, I think. * The different actions or declarations will need different constructs to implement the low-level behaviour. Not all of them need to be user-visible. "import" naturally will. Declaring the current compilation unit to have a separately named entry point will do so as well. Declaring an externally available entry-point will. And finally something for registering a "default" (admittedly for those special occasions...) * The registry needs to be something more extensible than a simple "feature" list. We have to keep track of what is initialized, and so on. Using any existing mechanism will only make it harder to later remove the old code and make the existing code even more complicated than it already is. * Changing the semantics of "import" for "late" initializing of compilation units breaks backwards compatibility, but we don't want to create yet another special form, right? The conservative solution is to do initialization at the point where an externally available entry point is declared or code is explicitly loaded, like it
Re: [Chicken-hackers] [PATCH] Fix #1133
On 2014-06-30 12:58, Felix Winkelmann wrote: > Excellent! Evan, would you mind writing a wiki-page for the egg? > Perhaps based on the r7rs-tasks page? Certainly. > The thing about "define-values" is related to not being able to handle > extended (DSSSL) lambda-lists, is that correct? If yes, we can > probably ignore that for the time being. Not DSSSL, but more basic lambda lists such as the following, which core's `define-values` doesn't support: (define-values a (values 1 2 3)) (define-values (a . b) (values 1 2 3)) I initially added an alternative definition of `define-values` to the egg that supports these cases, but ran up against #1132 in that it wasn't used within let and lambda bodies. I hope to post a patch to extend core's version shortly. Cheers, Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1079 by ripping out pathname expansion and putting it into an egg [Was: Re: [PATCH] add pathname-expand]
On 2014-06-22 13:43, Peter Bex wrote: > I have now implemented Felix's "pathname-expand" patch as an egg (see > http://wiki.call-cc.org/eggref/4/pathname-expand). > > [...] > > Attached is an updated version of Florian's patch to remove all implicit > expansion from CHICKEN core. Pushed, thank you Peter and Florian. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1133
>> Hm. You mean invoking the entry-point of a library unit should >> register a feature of the same name? > > Or something else, I'm not sure what exactly. I think conflating > features with module names is asking for trouble down the line. > If nothing else, we could prefix it, like for example module:foo. > It's ugly but would avoid name conflicts. Yes, I agree. But perhaps using a different form of "registry" flor loadied stuff might be better. > >> Perhaps that might work (yet >> wouldn't solve the problem of multiple compilation (and thus >> entry-points) units in a single library) > > Can you elaborate on that? You can have multiple entry-points (units) in a single library, just as we have in libchicken in the moment. This might work with a "feature-registry" based approach, but I'm afraid of changing anything in that code (somewhere deep in eval.scm). > >> but I'm not sure if it is a >> good idea. The separation of loading/linking and importing is IMHO >> actually an advantage and provides more flexibility. Hiding >> everything in "import" will result in trying to work around that very >> feature, sooner or later. > > Is this just a gut feeling, or can you give an example where it will > cause trouble? So far, I've only seen several questions on IRC from > newbies who got confused that import didn't actually load the code. > And having to remember to (import chicken scheme) but that we should > (use everything-else) is just a hassle, and a barrier to entry for > newbies. I admit it's a relatively minor annoyance, but if we can > remove it I don't see why we shouldn't (unless of course there's a > compelling example why loading and importing should be kept separate) It's a gut feeling. I don't doubt this *can* be simplified, but getting this right will be a major job, if it is going to cover all possible use cases. And we already are planning too much, and haven't even got the manpower to get patches to this list reviewed in a timely manner... > I'm not sure if "require" has any uses, otherwise we could start by > deprecating that. I've never seen anyone use it "in the wild". You need it if you don't use modules, and if you don't want to manually track what is loaded. But it is probably the least used of those loading constructs. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] incorrect warning during compilation
On Tue, Jul 01, 2014 at 12:07:35PM +0200, Kristian Lein-Mathisen wrote: > I am watching these patches with great interest. They are surprisingly > small, nice and comprehensible :) > > I'm happy and would love to see this committed somewhere :) I also like the patch. I haven't had time to look into it, due to being afk in the weekend and having the srfi-13 and move-memory bugs. There are also a few of my patches waiting to be committed. It would be great if any of the other core hackers could help out. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] incorrect warning during compilation
I am watching these patches with great interest. They are surprisingly small, nice and comprehensible :) I think this is a really nice foreign-type extension! And it's backward-compatible, right? (let ((str "xBC")) ((foreign-lambda* c-string (((scheme-pointer unsigned-char) x)) "x[0] = 65; return(x);") str) (print str)) which produces unsigned C_char *x=(unsigned C_char *)C_data_pointer_or_null(C_a0); x[0] = 65; return(x); which prints ABC I'm happy and would love to see this committed somewhere :) K. On Fri, Jun 27, 2014 at 10:56 PM, Felix Winkelmann < felix.winkelm...@bevuta.com> wrote: > From: Kristian Lein-Mathisen > Subject: Re: [Chicken-hackers] incorrect warning during compilation > Date: Fri, 27 Jun 2014 17:13:21 +0200 > > > Actually, that's really cool! A "string-buffer" type! I wouldn't mind > > seeing this in core. So how does this work, Felix, do we vote and things? > > Here is an attempt at Moritzens proposal. > > > felix > ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1133
On Tue, Jul 01, 2014 at 12:15:47AM +0200, Felix Winkelmann wrote: > Hm. You mean invoking the entry-point of a library unit should > register a feature of the same name? Or something else, I'm not sure what exactly. I think conflating features with module names is asking for trouble down the line. If nothing else, we could prefix it, like for example module:foo. It's ugly but would avoid name conflicts. > Perhaps that might work (yet > wouldn't solve the problem of multiple compilation (and thus > entry-points) units in a single library) Can you elaborate on that? > but I'm not sure if it is a > good idea. The separation of loading/linking and importing is IMHO > actually an advantage and provides more flexibility. Hiding > everything in "import" will result in trying to work around that very > feature, sooner or later. Is this just a gut feeling, or can you give an example where it will cause trouble? So far, I've only seen several questions on IRC from newbies who got confused that import didn't actually load the code. And having to remember to (import chicken scheme) but that we should (use everything-else) is just a hassle, and a barrier to entry for newbies. I admit it's a relatively minor annoyance, but if we can remove it I don't see why we shouldn't (unless of course there's a compelling example why loading and importing should be kept separate) > I also don't think that the confusion is _that_ great, > "require-extension"/"use" normally works fine, in the usual mode most > users will eventually have - one module per compilation unit. Having multiple modules inside one file is kind of problematic anyway, so I don't think many people are doing that. (I don't think we should actively make that impossible, however) > That the documentation does probably increase the confusion due to the > many options is a valid concern, though. Perhaps we should strive to get rid of some forms. I'm not sure which though. require-extension is there for SRFI compat, isn't it? If "import" performed the task currently performed by "use", we could eventually get rid of "require-library" AND "use". I'm not sure if "require" has any uses, otherwise we could start by deprecating that. I've never seen anyone use it "in the wild". > And as "use" currently performs the task of "import", why do you want > "import" to perform the task of "use", if not for R7RS compatibility? For convenience and to reduce confusion. We wouldn't need "use" at all, eventually we can get rid of it. > (which is not necessary to implement in core. CHICKEN is an R5RS > system, as you said in another mail.) It is, but R5RS doesn't have a module system, so we're not bound to the spec for how that works, and can change it to whatever is most convenient for us. > And why would it make using the r7rs egg less painful? I'm not sure I > understand, but I'm probably missing something. Hm, perhaps it's me who is missing something. I seem to recall that the r7rs egg just mapped import to CHICKEN's import, requiring the user to load the implementation of a module somehow "from the outside", but that doesn't seem to be the case (anymore?), so just ignore that. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
