<civodul>mark_weaver: i'm warry about 21bbe22a14a75fab54a5a8563fad63851a18fee3 <civodul>because it removes a test, doesn't add any, and claims that it changes the semantics <mark_weaver>the test in question verified semantics that are not part of R6RS and are inherently expensive to ensure. <mark_weaver>it's clear from the R6RS definition that the intent of 'get-bytevector-some' is to efficiently get some available bytes from the port. <civodul>but just "some" isn't very useful, no? <mark_weaver>some == at least one byte (or EOF). but in practice, with a buffered port, you'll get much more than that on average. <mark_weaver>anyway, that's just the way it's specified. argue with Sperber about it :) <civodul>"it reads one or more of the available bytes", which seems to be what you say <mark_weaver>Reads from binary-input-port, blocking as necessary, until bytes are available from binary-input-port or until an end of file is reached. If bytes become available, get-bytevector-some returns a freshly allocated bytevector containing the initial available bytes (at least one), and it updates binary-input-port to point just past these bytes. If no input bytes are seen before an end of file is reached, the end-of-file obj <mark_weaver>the key quote for me is "a freshly allocated bytevector containing the initial available bytes (at least one)" <mark_weaver>it seems that the wording was changed a bit since that formal comment. ***efftee is now known as ft
***davexuni` is now known as davexunit
<cky>sneek: later tell mark_weaver Yes, the indirect promises are in SRFI 45, in fact all promises in SRFI 45 are indirect. <cky>Suppose you're forcing promise1, and you get promise2 as a result of calling the thunk. SRFI 45 has code to make both promise1 and promise2 point to the same cons cell (and why promises are boxes pointing to conses, and not just the conses themselves). <sneek>Welcome back mark_weaver, you have 1 message. <sneek>mark_weaver, cky says: Yes, the indirect promises are in SRFI 45, in fact all promises in SRFI 45 are indirect. <wigs>he continued to say: <cky> Suppose you're forcing promise1, and you get promise2 as a result of calling the thunk. SRFI 45 has code to make both promise1 and promise2 point to the same cons cell (and why promises are boxes pointing to conses, and not just the conses themselves). <wigs>mark_weaver: not sure if he intended that for you also <mark_weaver>but I think he's mistaken. I'm looking at the SRFI-45 reference implementation, and trying to make a one-to-one correspondence to what he wrote, and they just don't match up. <mark_weaver>there's nothing in SRFI-45 that's analogous to his indirect promises. <wigs>mark_weaver: that you saw the continuation <mark_weaver>whereas SRFI-45 has two distinct data structures: (1) the top-level promise, which points to (2) a cons cell. <mark_weaver>in his core implementation, he's combining these into a single data structure. <wigs>presumably there is some reason for the indirection <mark_weaver>so whereas the SRFI-45 implementation always follows the pointer to the cons cell, and that does *not* have to be a loop, in his implementation, the top-level promise sometimes doesn't point to anything else, and sometimes has to point to another promise. <mark_weaver>and that ends up becoming a loop which was not present in the SRFI-45 ref impl. <mark_weaver>maybe this is a reasonable strategy; it will require more thought. <nalaginrut>I implemented my SSQL all with 'format', well, its efficiency is suspended for me ;-| <wigs>as in, ssql->sql uses format? <ijp>I have to confess, I don't understand the purpose of it <nalaginrut>well, ssql->sql intended to avoid users handle sql string directly <wigs>lets hope you dont have to do any bulk insert operations <nalaginrut>besides, to personal taste, sql string is hard to indent ;-P <nalaginrut>wigs: I do think there should be a cache to avoid generate sql string each time <ijp>I understood what it is, but I don't see how it is a benefit over writing it as a string <nalaginrut>and I plan to design a relational mapping to avoid users handle sql directly <wigs>unless you are using emacs mumamo <wigs>ijp: same benefits as using sxml, i.e. type safety, not worry about escaping strings and column names, etc. <ijp>except you don't spend nearly as much time generating sql as you do xml <wigs>well, some people spend a lot of time writing relational queries <nalaginrut>anyway, I still doubt 'format' efficiency, even if there'll be cache <wigs>the areas where a cache will help you, 'format' probably runs ok anyway <wigs>its only big big statements where it will be a problem, and those tend to be one-off INSERT or UPDATE <nalaginrut>maybe there could be level-2 cache to generate a SSQL template, for the situation users need to change some items frequently <ijp>sxml also works both ways, this is only ever going to be used one way <wigs>ijp: perhaps, I certainly wouldnt want to write a sql->ssql parser <wigs>but think that query composition, etc. is much easier and functional <nalaginrut>if users have many sql strings, they can use it directly in artanis <ijp>wigs: I suppose that is a little true <ijp>sql does lack an abstraction mechanism <nalaginrut>though SSQL is recommended, users still want to write sql manually <wigs>its just a _bit_ of a hack :-) <nalaginrut>and for abstraction issue, I'll write a relational mapping for that <ijp>anyway, prove me wrong :P <nalaginrut>if I can do it with 'FP way', like closure/lambda/lambda*/match... I'll call it FPRM <wigs>nalaginrut: there are relational DSLs that achieve something like this <ijp>logic programming and databases have been intermingled for decades <wigs>indeed, they are pretty much the same thing <nalaginrut>well, Kanren if pronounce as Chinese pinyin, it's 'kill people' <ijp>literally 'relation' <ijp>I never gave much thought until asumu on #racket mentioned it <ijp>alpha-kanren is quite amusing: A mix of Greek and Japanese, written in English <wigs>I didnt realise that is where kanren name comes from <wigs>alpha is of course for alpha equivalence <wigs>I shall be quite interested to see relvars in kanren languages <nalaginrut>I realized what I need is actually first-class relations <nalaginrut>ijp: and I wish guildhall could fix the 'program' category ;-) <nalaginrut>for a practical web framework plan, guildhall is essential <wigs>nalaginrut: well, a relation is not very much <ijp>I was waiting for a response from rotty about what the distinction was between 'program' and 'executable' <wigs>nalaginrut: just a tuple of a particular form/header <ijp>since I couldn't fathom it <nalaginrut>well, I'd like to add r6rs-protobuf, it's very nice, but the latest release contains an executable tools for guile to generate parser from proto file automatically <nalaginrut>so I wish guildhall could make users play it easier <wigs>program is end-user applications? <wigs>i.e. my aunty would say that paint is a program, and “'tr'? what is 'tr'?" <ijp>my assumption was that executalbe was for end-users, and programs might be used internally, e.g. for building <ijp>but I don't see anything in the code that points one way or another, except where they install to <ijp>which is currently broken anyway <nalaginrut>most of users I meet are interested on Guile, but Guile's build/compiling or guildhall is a little hard for them <wigs>well imo the distinction is very hard to make, one mans "end-user application" is another mans, erm, "one part of another program" <nalaginrut>I'll plan to create a 'guile repo' on openSUSE, one click to install all things of latest Guile things <ijp>wigs: well, true enough <wigs>nalaginrut: you can package up the individual components as suse packages, no harm in that <wigs>I'd guess that we are some ways off building arbitrary non-scheme extensions in guildhall <wigs>(unless someone has taken a secret interest) <nalaginrut>wigs: well, my idea means package each components, then put them in the one, users could install all of them with just one click <nalaginrut>many things on openSUSE in such a way, like R, Scala <wigs>nalaginrut: yes, right, a meta-package, I understood <wigs>yum install guile-and-give-me-some-batteries-dangit <ijp>wigs: what's the current state of figl? ready for an official release any time soon? <nalaginrut>wigs: for non-scheme thing, guildhall provide an option to handle the configure IIRC, but it doesn't work or I don't know how to use it... <wigs>ijp: I think we have GL 2.1 mostly covered, except textures and programmable pipeline <mike121>I've actually been sketching out a possible alternate to the package problem. I think it would be easy enough to create a script that has all of its modules as a tgz file that is embedded as a comment in the main script. <wigs>the later is probably way off, but textures are trivial, someone was going to send a patch <nalaginrut>ijp: I'll release an alpha for guildhall when I done the FPRM (maybe some years later) ;-D <wigs>of course, all of that works in the "low-level" aka raw OpenGL bindings <wigs>am just waiting for a small pocket of time to clean up some interfaces and also double-check our use of the term "OpenGL" is up to spec ***donglord8000 is now known as brendyyn
<mark_weaver>ijp: I'm surprised to hear you question the value of a sexpr-based representation for SQL. <cky>mark_weaver: I'm here. <cky>mark_weaver: _All_ SRFI 45 promises are indirect. They are all boxes to conses that contain the real data. <cky>mark_weaver: We can't use that approach for our promises since we're trying to be binary-compatible. *nalaginrut is not the only one who confused ijp and cky frequently... *nalaginrut is the only one who... <cky>mark_weaver: That's what the (set-box! promise* content) line is for. <ijp>mark_weaver: perhaps I am biased against it because of previous attempts <cky>mark_weaver: It's to make the new promise indirect to the same cons as the current promise. <nalaginrut>is there any possible to make Guile work with R? <ijp>I can argue for sxml, I can argue for SREs, but this, I'm just not sure about <cky>mark_weaver: The loop is to catch a case that SRFI 45's reference implementation doesn't catch. I'll have to write a sample case soon to demonstrate. <cky>mark_weaver: Even my version isn't foolproof, but it does catch more cases than SRFI 45 does. :-) <cky>There _is_ a problem, though. I have VALIDATE macros in checking that the thunk returns a promise, but in case of error, it doesn't unlock the mutex. <cky>There really should be a VALIDATE_OR_UNLOCK macro. ;-) <mark_weaver>cky: I'm not necessarily saying you should do it this way, but you *could* make promises with the lazy bit set point to a cons cell. <mark_weaver>otoh, that means more overhead, so maybe it's better the way you have it now. <cky>mark_weaver: We were trying to be binary-compatible with eager (computed) promises. :-) <cky>mark_weaver: Having all promises be indirect would break that. <mark_weaver>but I'm a bit concerned that your code has a loop to follow the indirects, whereas the SRFI-45 ref impl has just a single indirect in all cases (no loop) <cky>Here, in the common use case, the "primary" promise is direct (and is thus binary-compatible), and secondary promises are indirect. <cky>mark_weaver: The loop is to catch a special (very perverse) case that SRFI 45 doesn't handle. <mark_weaver>well, I'm not even convinced of that much. what you need to do is to continue supporting the 'make-promise' API. <cky>mark_weaver: Ideally nobody should be writing the kinds of lazy expressions that would trigger this, but I'm trying to deal with it, whereas SRFI 45 would break under such a circumstance. <cky>Yes, make-promise promises still continue to work with my current delay implementation. <mark_weaver>and you also need to use the same data structure for computed promises. <cky>Yes, here computed == eager. <cky>If you want to use a separate structure for eager, that would probably make things more complicated than it needs to be. <mark_weaver>honestly, I haven't put enough thought into this to know what's best. <mark_weaver>I'm trying to stay focused on my ports work for 2.0.8 :) <cky>mark_weaver: I'll make the other changes you mentioned, such as the eager procedure for srfi-45. <mark_weaver>but it seems to me that you have almost no constraints on how you represent uncomputed promises. <cky>I've given the indirect thingy a lot of thought before implementing it. <mark_weaver>so you *could* do something closer to what SRFI-45 does. <cky>If you are happy for eager promises to be represented differently to computed legacy promises, I can certainly make a force implementation that's a lot closer to what SRFI 45's reference implementation does. <mark_weaver>can you help me understand why your code needs a loop to follow indirects, whereas the SRFI-45 code doesn't need a loop? <cky>Sure. Let's give you a motivating example. <cky>So, say you have your original promise, call it p0. <cky>Invoking p0's thunk gives p1. <cky>The indirection is there so that if a separate reference to p1 is stored (e.g., using set!), forcing p0 and then forcing p1 will only result in p1's thunk being evaluated once. <cky>Now, here's the perverse case: <cky>Suppose p1's thunk returns promise p2. <cky>(Wait, lemme think this through. I was envisioning a case where p2 ceases to be aliased to p0.) <cky>and the loop can mitigate this some. <cky>I will sleep on this some more. <cky>I'll let you know when I have an example to demonstrate this, or if I don't have an example after all. <mark_weaver>okay. in general, I'd prefer to use the same algorithm that SRFI-45 uses. apparently it is tricky to get this right. look at the SRFI-45 post-finalization mail archive, where "improved" algorithms were posted, and then at some point andre discovered that they were actually flawed. <mark_weaver>if we use a different algorithm, we will have to scrutinize it *very* carefully. <mike121>Guile 100 Problem #4 is to make a tar file. See lonelycactus.com/guile100 <nalaginrut>wigs: is first-class-relational-mapping suit for my purpose to handle DB? <wigs>nalaginrut: you want to have relations as first class datatype, and some kind of functional query language? <nalaginrut>wigs: I guess so, and it'll convert to sql string in low-level <nalaginrut>anyway, an better abstraction for sql string I mean <nalaginrut>though ssql is a nice thing for that, but I still want to design a better on based on ssql <wigs>well it probably access your db, but could be a lot of effort to develop <nalaginrut>well, relational mapping -> ssql -> sql string -> dbi -> db <nalaginrut>now I want to design a better relational mapping in Scheme way <wigs>(-> sql string -> dbi) is backwards <wigs>ssql -> dbi (maybe? -> sql) -> db <nalaginrut>hmm...seems you're suggesting that I re-implement dbi? <nalaginrut>since guile-dbi need to pass sql string from user <wigs>leaving it the way you mention would be faster way to start, but perhaps broken because different dbms (mysql, etc.) have different enough syntax, quoting rules, etc. <nalaginrut>yes, but my idea is to encapsulate these difference with a proper relational mapping model <nalaginrut>and ssql will provide specific SQL for each dbms for optimization <nalaginrut>ORM could do that, but I believe there's a way to drop OO <wigs>sure, though I would just let the db driver take ssql and handle its own optimizing <nalaginrut>yes it's the easy way, but my aim is to provide a convenient way for users <wigs>users dont see any difference, they are using the relational model at the top <nalaginrut>most and most of users are not hackers, so my 'duty' is to provide that ;-D <nalaginrut>well, now the problem is, how to start if I want to drop OO? <wigs>you are already composing queries in ssql and executing them? <wigs>and the result is what, a list, alist, hash? <nalaginrut>you mean the result returned from DBI? it's assoc list <wigs>so, that alist that you get is _almost_ a relation in the strict sense ***fangism1 is now known as fangism-zzzz
<wigs>a relation is just an ordered tuple of values, and a particular _type_ <wigs>for a db, the type is more-or-less equivalent to the set of columns <ijp>relational algebra has the names in the relations *nalaginrut is listening... <wigs>well then, even closer :-) <wigs>besides that the alist is not a disjoint type, all that is missing really is some actual algebra <nalaginrut>yes, but I still no idea how to design an program interface for users <wigs>well it probably look something like ssql <nalaginrut>Chaos`Eternal: there's no sql->ssql, just ssql->sql <wigs>or, if ssql and kanren had mutant babies, it look like that <nalaginrut>wigs: (lambda* (table #:name "me" #:age 12 #:email "xx@xx.com") ...) maybe just like this <nalaginrut>and it'll make a ssql, then ssql->sql, then sql->dbi <wigs>define relations using lambda? <nalaginrut>but I have to provide a general way, maybe macros to generate lambda on the fly <nalaginrut>each time this lambda dump is a query operation for DB <ijp>macros...on the fly... does not compute <nalaginrut>and there's inner cache to store the sql string, to avoid make sql string each time <nalaginrut>ijp: hmm...I mean users don't have to write lambda* with their fields in keywords manually <nalaginrut>when users made an 'instance' of a table, there's a lambda for it <wigs>right, so suppose there are two tables: person, address <wigs>to query for persons named "fred", what does this look like? <wigs>: (person #:name "fred") <ijp>how would updates work then? <nalaginrut>for pure lambda, this may a little trouble, maybe pass an operation? (person 'get #:name "fred") and (person <nalaginrut>for pure lambda, this may a little trouble, maybe pass an operation? (person 'get #:name "fred") and (person 'set #:name "fred" '("lucy" 15 "xx@xx.com")) <wigs>well, you may be able to work an interface like that <nalaginrut>the problem for lambda is, our lambda can accept an operation with message passing <nalaginrut>when I's trying to implement Actors with lambda, I found it's not so fine for pure lambda <nalaginrut>since any operation should be implemented as message passing style, hard to extent <wigs>well, goops is very nice :-) <nalaginrut>wigs: yeah~I'll write ORM with GOOPS, but now I'm challenging FPRM ;-) <wigs>what do you mean the message parsing is hard coded? <nalaginrut>(lambda (op ...) (case op ((get) ...) ((set) ...) ... <wigs>well you can push the lookup (case op ...) to a mutable data structure <wigs>(let ((methods '((get . (lambda ...)) ...))) (lambda (op . args) (apply (assq-ref op methods) args))) <wigs>then e.g. some method on the object can add a new method, or remove one <wigs>yet methods stays private to the actor/lambda <nalaginrut>thanks, it's one of three methods in SICP chapter 2 <wigs>you can also hardcode some operations in the lambda, for speed or security <wigs>see e.g. prometheus object system uses a similar mechanism <nalaginrut>however, message passing is one of three methods too <nalaginrut>wigs: another problem, lambda seems not easy to change the attributions closured within <wigs>yeah sure, you would need a decent set of macros to handle the busy work for you <lloda>is it ok to replace GC_PTR with void *? <lloda>my version of bdwgc doesn't have GC_PTR any longer. <lloda>ok, it is a mistake then in 337edc... <nalaginrut>wigs: yes, I can maintain a hashtable in the closure, finally, I re-implemented a micro-GOOPS myself hah~ <nalaginrut>wigs: yes, maybe my real aim for Actors/FPRM is to write a half-worked OOPS <nalaginrut>anyway, if it's lightweight than GOOPS, it's worthy <wigs>usually it comes with gettext package <wigs>installs to /usr/share/aclocal <wigs>nalaginrut: trying to configure something? <nalaginrut>it's fine in my laptop, but I can't remember what are the dependencies here <taylanub>I seem to remember a problem related to that; maybe you need to export ACLOCAL_PATH. <taylanub>E.g. I had to set it to /usr/local/share/aclocal after installing autotools in $HOME/usr. <nalaginrut>each time Guile update in git needs to use all the latest GNU packages? <taylanub>Well I'm on OpenBSD 5.1 which has quite old stuff. <nalaginrut>this VPS runs centOS 6.0, so I installed many thing my self *nalaginrut is building Guile for Artanis on a VPS <nalaginrut>../configure: line 45550: syntax error near unexpected token `LIBFFI,' <nalaginrut>../configure: line 45550: `PKG_CHECK_MODULES(LIBFFI, libffi)' <mark_weaver>nalaginrut: you need pkg.m4, which is part of 'pkg-config'. usually in /usr/share/aclocal/. if you have it somewhere else, set ACLOCAL_PATH to point to the right directory before running ./autogen.sh <mark_weaver>in general, if you see errors in configure that are clearly an m4 macro and not a shell command, then it indicates that you're missing some *.m4 file in your ACLOCAL_PATH <mark_weaver>the name of the macro (the first thing before the open parenthesis) is generally a hint about which *.m4 file you're missing. in this case, PKG_CHECK_MODULES is provided by 'pkg-config'. <nalaginrut>autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION <nalaginrut>mark_weaver: well, I thought you're preparing 2.0.8 tarball <mark_weaver>those tarballs are fresh, but already have the 'configure' script built, so it's just like building a release tarball. <mark_weaver>2.0.8 will certainly be out fairly soon, but probably not tomorrow as we'd hoped. <mark_weaver>these ports fixes have taken a bit longer to resolve than we'd hoped. <mark_weaver>anyway, I wouldn't worry about that autoreconf warning. <mark_weaver>if that's the only problem, you're probably all set. <nalaginrut>I think I used something new in 2.0.7+, so I'm afraid of 2.0.8 is proper <nalaginrut>mark_weaver: I could ignore autogen.sh, but ../configure: line 45550: `PKG_CHECK_MODULES(LIBFFI, libffi)' <mark_weaver>then you won't have to worry about these missing *.m4 files. <nalaginrut>mark_weaver: let alone m4 warning, how about the libffi issue <mark_weaver>it's not a libffi issue. it's a pkg-config issue. read what I wrote above. <mark_weaver>(starting with "nalaginrut: you need pkg.m4, which is part of 'pkg-config'") <cky>sneek: later tell mark_weaver So I will try to produce a version that implements the reference implementation as closely as possible, to avoid issues, and in particular to use the indirection for all uses. <cky>(Obviously, my INDIRECT corresponds to the "shared" of the simpler implementation.) <cky>sneek: later tell mark_weaver I think I'm going to use a struct/record for the indirected thingy. It will have a flag field, a value field, and a mutex field. <cky>sneek: later tell mark_weaver I will have to revamp how mutexes are handled inside force. <ArneBab_>cky: wisp is a preprocessor because that’s much simpler than replacing the reader: Instead of understanding lisp you just need to add brackets at the right places. This also makes it possible to use it for any lisp implementation without changing each reader. <taylanub>ArneBab_: A reader does not understand Lisp. <taylanub>But you still have a point: All Lisp dialects use their slightly different s-expression format and thus reader; you can't have a universal sexp reader that works with all Lisp dialects, sadly. <tupi`>hello guilers, good day all! <garjola>hi all, which is the recommended unit testing framework/lib/etc for guile? <garjola>something easy to use, full of features, etc. of course ;) <civodul>garjola: SRFI-64, but it's not part of Guile (yet) <garjola>civodul: thanks. how do you usually write tests? <civodul>garjola: with a copy SRFI-64 bundled in my package *davexunit should really write unit tests for his code <sneek>Welcome back mark_weaver, you have 4 messages. <sneek>mark_weaver, cky says: So I will try to produce a version that implements the reference implementation as closely as possible, to avoid issues, and in particular to use the indirection for all uses. <sneek>mark_weaver, cky says: I think I'm going to use a struct/record for the indirected thingy. It will have a flag field, a value field, and a mutex field. <sneek>mark_weaver, cky says: I will have to revamp how mutexes are handled inside force. <garjola>I have a library wrapped with guile so that I can do (load-extension lib ini_function) <garjola>where init_finction is defined in the lib and contains the definitions of the exposed functions <garjola>in my scm file (module) I do (load-extension ...) <garjola>whe I compile the module in geiser, the load-extension is not taken into account and I have to call (load-extension ...) at the repl <mark_weaver>garjola: assuming that you did things in the usual way, keep in mind that the bindings introduced by your init_function will be in the module of the scm file which loaded it. <mark_weaver>garjola: therefore, you must import that module in order to get those bindings. <mark_weaver>garjola: when you run 'load-extension' from the REPL, I guess maybe you're running that code again within the (guile-user) module. <garjola>I am in the module (the repl prompt says so) <mark_weaver>specifically the module that calls 'load-extension', and your 'init function'. <garjola>I am trying on a standard guile repl (not geiser) and the problem is the same. I guess I don't understand the diffeences between load import-module use-modules, etc <dsmith-work>garjola: Do you have your load-extension call wrapped in an eval-when ? <mark_weaver>garjola: I recommend looking at section 6.20.3 (API Reference -> Foreign Function Interface-> C Extensions) <ArneBab_>taylanub: As far as I remember a lisp reader understands s-expressions and some special forms, right? <garjola>mark_weaver: thanks and sorry for asking before doing my homework. I thought I understood ... <mark_weaver>garjola: but don't just look at the first example. it shows a progression of examples. better to look at the last example. <mark_weaver>garjola: no worries. the manual could use some improvement in this area. an item of my TODO list involves changing section 5.3.1 (A Sample Guile Extension) to be closer to section 6.20.3 <mark_weaver>garjola, dsmith-work: it's true that unless the 'load-extension' is wrapped in 'eval-when', it will not be called when the module is *compiled*, but only when the module is *loaded*. However, I don't see why that would be needed. <dsmith-work>Hmm. Ok. I do remember having issues unless I used eval-when <mark_weaver>garjola: but regarding the difference between 'load' and 'use-modules' (or 'import-module'): 'load' should call the 'init_function' and add the bindings for your C functions to that module. 'use-modules' (or 'import-module') is what makes those bindings available to the module that does the 'use-modules' (or 'import-module') <garjola>OK, it works now. I was missing the scm_init_xxx_module and using only the init_xxx function. <garjola>If I include the (load-extension ...) in my .guile file, the (use-modules ..) call works on the repl <garjola>Now, is there a #load-extension: similar to the #:use-module ? <mark_weaver>you shouldn't be calling 'load-extension' except within the module that it's part of. everyone else should simply be able to load that module. <mark_weaver>so I don't see a compelling need for #:load-extension <mark_weaver>garjola: also, you shouldn't need to call 'load-extension' from your .guile. you should put the 'load-extension' call within the module that it's part of. and then just import that module. <garjola>Does that mean that I need a scm file wich defines the module and contains te load-extension? Because right now, I only have the .so lib and I use it from a scm file which defines a completely different module, but uses this lib <mark_weaver>garjola: (unless you're sure that this "completely different module" is the only place you'll ever want to import bindings from this lib) <taylanub>ArneBab_: The reader reads any binary tree, serialized as an s-expression, into memory. Analogous to a JSON reader, or XML reader, it's just a general purpose "parser" for the s-expression data format (which serializes binary trees). So it's entirely agnostic to programming-language semantics; it's the evaluator that interprets nodes of the binary tree as special-form-usages or function-calls. <taylanub>However, a Scheme implementation expects its reader to understand e.g. #t, #f, #(foo bar), etc., which are data-types native to Scheme (although "theoretically" not tied to any specific language), so the line is not so clear-cut in practice, between the reader and the rest of the Lisp implementation. <taylanub>Therefore it does indeed make sense to offer a "pre-processor" kind of program that is agnostic to the fine details of the s-expression format on which it's used, instead of providing one extended reader. <taylanub>(Alternatively, one could just write a specification, and offer a couple of reference implementations for the readers of the major Lisp dialects.) <ArneBab_>taylanub: To make that pre-processing easier, the pre-processor can take the file from stdin. So the reader could simply be extended to call the pre-processor as a first pass. The only disadvantage is that it would have to rely on heuristics to determine when to pass something to the pre-processor. For example at EOF when reading a file and when encountering a double linebreak when used interactively. <ArneBab_>The main difference is that the pre-processor needs to get a full block of code to generate valid code. <ArneBab_>A reader on the other hand might start processing even though it does not yet have the full file - or might actually evaluate partial code when it gets it. ***sneek_ is now known as sneek