This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Tel <telford@eng.uts.edu.au> writes: > If the regexp state machine is constant then is there any reason why > hobbit cannot compile the initialised regexp data into the code. This is > pretty much what the flex utility does for C code. C programs have supported > the concept of compiling in initial variable values for quite some time. Well, yes and no. C will compute initial variable values if you're lucky. But, for example: int fac(int n) { if (n) return n*fac(n-1); else return 1; } int k=fac(10000); This will get computed at runtime, not compile time. Myabe if you inlined the function, you could explode the compiler's brain. Anyway, this is closer to the situation in guile-lang. Hobbit could do that, but the C compile still wouldn't fix it up. And besides, it's currently computed lazily. The freezer is worth looking at (another form of unexec, really), because it can freeze scheme data into C code. But here, we have great honking C data structures (shudder). > This is also a good point because you know how many pointers to expect > in your data and where to expect them. In theory the (write) procedure > can serialise any non recursive scheme data structure but in practice > this may not be useful for all situations. Yes, but scheme data structres aren't really all that problematic. The big problem is the C structures and SMOBs which ware difficult to pickle. And it doesn't pickle vectors, lambdas, or continuations. Lambdas are definitely useful to have in a sheme data structure. Andrew