Re: [Chicken-users] New immediate values (was: DBI)
On Fri, Feb 29, 2008 at 1:31 AM, Tobia Conforto [EMAIL PROTECTED] wrote: Graham Fawcett wrote: There does seem to be a good case for an immediate value that *can* be tested this way, though. John et. al. wouldn't have used (void) in eggs if there weren't. What about providing a utility to create new immediate values, disjoint from anything else? The immediate value space is far from cramped, if I'm not mistaken. Such a new-immediate-value function (which could benefit from a better name) would return a new value every time it's called, using for example an internal counter. One could write: (define sql-null (new-immediate-value)) (define (sql-null? x) (eq? x sql-null)) With the certainty that sql-null won't be eq? to anything else at all, won't be a list, a record, nothing at all except itself. I think this could have a few uses. (Unless it's terribly broken in a way I can't see, which is quite possible :-) It would probably have uses, but what would you gain? All you need is a distinct unique object: (define sql-null (gensym 'sql-null)) cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On 29 Feb 2008, at 12:31 am, Tobia Conforto wrote: What about providing a utility to create new immediate values, disjoint from anything else? It's called gensym :-) ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On Fri, Feb 29, 2008 at 1:41 PM, Tobia Conforto [EMAIL PROTECTED] wrote: felix winkelmann wrote: (define sql-null (new-immediate-value)) (define (sql-null? x) (eq? x sql-null)) With the certainty that sql-null won't be eq? to anything else at all, won't be a list, a record, nothing at all except itself. I think this could have a few uses. It would probably have uses, but what would you gain? All you need is a distinct unique object: (define sql-null (gensym 'sql-null)) This is still a symbol. People are using (void) because it's nothing but (void), that is, all standard predicates (symbol?, pair?, number?, string?...) return #f. Only its own predicate returns #t. Would a db interface include symbols as output? cheers, felix (who would like to keep the number of immediate types small) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] PCRE problem via regex
I will do this. Current PCRE is 7.6 Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On 29 Feb 2008, at 1:14 pm, John Cowan wrote: Alaric Snell-Pym scripsit: What about providing a utility to create new immediate values, disjoint from anything else? It's called gensym :-) Gensym values aren't disjoint *in type* from anything else. Ah, but disjointness in value is all that's required... ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
Alaric Snell-Pym scripsit: Gensym values aren't disjoint *in type* from anything else. Ah, but disjointness in value is all that's required... Technically yes, but most of us find predicates like number?, string?, and symbol? rather handy all the same, and don't want NULL mixed up with them. C programmers may be happy with a world where integers, characters, and booleans are the same thing, but should we be? It was not for nothing that Codd made sure his nulls (later divided into A-marks for the unknown and I-marks for the inapplicable) were quite independent of concrete types. -- John Cowan http://ccil.org/~cowan [EMAIL PROTECTED] All isms should be wasms. --Abbie ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Debugging support
Hi, I just joined up because I'm going to use Chicken. I started with PLT but dropped it because it doesn't have a debugger. I moved to Gambit, but it has strange macros and doesn't have all the libraries I need, so I'm trying Chicken. I'm astounded that none of the public schemes out there have a visual debugger. (I know, some people say scheme doesn't need a debugger, but I don't believe it; its a dynamic language, debugging should be *easy*). My plan is to hook up some scheme system to the powerful Eclipse debugging framework. This should be doable in a week or two, if the language has the right hooks. See http://www.eclipse.org/articles/Article-Debugger/how-to.html This will be combined with the SchemeWay plugin. I am curious if people have thought about adding debugging capabilities to Chicken, along the lines of what is in Gambit. It seems like most of the hooks are there. Am i missing something? Is anybody else interested in helping out? Is this the right email list to discuss this topic? William ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On Fri, Feb 29, 2008 at 3:59 PM, John Cowan [EMAIL PROTECTED] wrote: Alaric Snell-Pym scripsit: So do we make the bold move of not defining (token? x)? No, we realize that just as we need only one empty list (unlike Java, where any list can have zero elements without losing its identity), we need only one object that has: a unique identity, disjoint from all other objects a unique type, disjoint from all other types no information inside it Why do we need this? I can't remember right now... cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On 29. Februar 2008 09:24:07 -0500 John Cowan [EMAIL PROTECTED] wrote: Alaric Snell-Pym scripsit: Gensym values aren't disjoint *in type* from anything else. Ah, but disjointness in value is all that's required... Technically yes, but most of us find predicates like number?, string?, and symbol? rather handy all the same, and don't want NULL mixed up with them. [...] Hello, this is really a question of taste, isn't it? You could just as well argue that a NULL value should be of a type that is a subtype of every other existing type but contains no other concrete instances, which would imply that all the type predicates should return #t when applied to the NULL value. This makes a lot of sense when the NULL value is used to indicate the absence of an object reference and is the way it is handled in several object oriented languages. cu, Thomas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
Alaric Snell-Pym scripsit: So do we make the bold move of not defining (token? x)? No, we realize that just as we need only one empty list (unlike Java, where any list can have zero elements without losing its identity), we need only one object that has: a unique identity, disjoint from all other objects a unique type, disjoint from all other types no information inside it -- But you, Wormtongue, you have done what you could for your true master. Some reward you have earned at least. Yet Saruman is apt to overlook his bargains. I should advise you to go quickly and remind him, lest he forget your faithful service. --Gandalf John Cowan [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On Fri, Feb 29, 2008 at 7:57 AM, felix winkelmann [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 1:41 PM, Tobia Conforto [EMAIL PROTECTED] wrote: felix winkelmann wrote: Would a db interface include symbols as output? Would it? I honestly don't know. I haven't seen it in practice, and can't think of a deal-breaking use-case. Enum types come to mind, but that could be handled (perhaps less naturally) with strings. Could it? I'm looking at Postgres, and wondering how to come up with a consistent approach for handling user-defined datatypes. There's no right solution, and the best compromise is to let the user register in/out translation functions. An out-function could translate a value in a custom type into anything, including a symbol (unless we *specify* that this should be illegal). Should it? If we are approaching a common dbi, we should decide now. But it feels premature to rule out an entire datatype for lack of a good null type. For representing sql-null, the special immediate-type solution is best because it's unambiguous. If that were ruled out, simply using the symbol 'null -- and forbidding database layers from returning symbols as output-values other than 'null -- would be my second choice, but it's an inferior solution, and I have a feeling I'd regret it later. But please not '(), for the same reason not #f, 0, or an empty string. cheers, felix (who would like to keep the number of immediate types small) I don't want to see a circus of immediate types either, but one more isn't horrible. I thought (void) was perfect for this, but I respect the concerns that have been raised. So, (void) needs a brother who has no semantic baggage. Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
On Fri, Feb 29, 2008 at 10:41 AM, felix winkelmann [EMAIL PROTECTED] wrote: On Thu, Feb 28, 2008 at 4:02 PM, Graham Fawcett [EMAIL PROTECTED] wrote: It would be a smart idea to change the implementation, then, so that the unspecified value could not be tested with (eq?). That would prevent it from being 'misused'. The unspecified value is unspecified. It has both no identity and no efforts are made to make it identity-less. Right, but (eq? (void) (void)) = #t is a property that shouldn't exist for two unspecified values: by definition it gives identity to unspecified. (eq? (void) (void)) = #f is better, raising an exception is better still. To preserve the 'undefined' meaning, any functions that can test #unspecified should really be internal, e.g. in the ##sys# namespace. But as you say, it's unspecified, so this is a divergent discussion. :-) There does seem to be a good case for an immediate value that *can* be tested this way, though. John et. al. wouldn't have used (void) in eggs if there weren't. Record instances aren't really a great answer (though I suggested them myself) since different records of the same type will fail an identity test. Unless you use a single unique instance. That would be problematic in compiled code, would it not? Where is the instance stored? Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] spiffy example
Hi, In 'Adding dynamic resources' at http://chicken.wiki.br/spiffy, I think there are two mistakes : - http:write-response-header should be write-response-header - and before calling it, the current-request parameter should be changed to the request argument. I don't change the wiki because I'm not really sure of this (we can use the code of the http egg example instead). Cheers, Thu ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
Graham Fawcett wrote: (eq? (void) (void)) = #t is a property that shouldn't exist (eq? (void) (void)) = #f is better, raising an exception is better still. I think SQL has it right here: NULL any-op anything, or in s-expr (any- op NULL anything), gives NULL. So NULL is neither equal nor disequal to NULL, or to hello, it's NULL to them. (I'm not suggesting adding this behaviour to Chicken, as it would degrade performance for every simple operation without a good reason. I'm just noting what I think is a nice approach.) Tobia ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
So, to recap: '(), 0, , #f, 'null, (gensym) Very bad for representing SQL NULL, because some DBs or DB operations could theoretically support lists, numbers (doh), strings (doh), booleans, and symbols, and in those cases we wouldn't want the null value to clash with valid values. For example I'd quite like to see a Postgres extension (or just the Chicken interface) supporting symbols in an efficient manner, with a symbol table and all. As it can't be ruled out, having symbol? return #t for sql NULL is a very bad idea. (void) Bad. You would need to test for it by (eq? x (void)), which is terrible, and is a non-value inappropriate for representing an actual return value, as already expressed in this thread. (define-record-type sql-null (sql-null) sql-null?) Not too bad. Any piece of code could create null values with (sql- null), even in different compilation units. People would just have to remember to use (sql-null? x) instead of eq?. The API could state that eq? on two sql-null values is undefined. A new immediate value IMHO the best option, and it could be useful for other APIs too, but if Felix says no he's probably right. Tobia ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] spiffy example
Absolutely correct, feel free to update the wiki to reflect this. On 2/29/08, minh thu [EMAIL PROTECTED] wrote: - http:write-response-header should be write-response-header - and before calling it, the current-request parameter should be changed to the request argument. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] General problem with the chickenegg tag on the Eggs Unlimited page.
Many author sections have e-mail addresses in them, which get eaten to turn the other name into a horribly munged wiki page name. In some cases (someone tried to use a href=mailto:...) it even breaks the egg's insertion in the table completely. Not sure what the right fix is here, but the current state is losing data (that is, the authors are providing e-mail addresses which the user can't see). -Robin -- Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo Proud Supporter of the Singularity Institute - http://singinst.org/ http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On Fri, Feb 29, 2008 at 2:57 PM, Tobia Conforto [EMAIL PROTECTED] wrote: So, to recap: Perfect recap! :-) (define-record-type sql-null (sql-null) sql-null?) Not too bad. Any piece of code could create null values with (sql- null), even in different compilation units. People would just have to remember to use (sql-null? x) instead of eq?. The API could state that eq? on two sql-null values is undefined. True. I suspect there will be slightly more overhead here than with using an immediate, perhaps noticeably on large queries. Ideally (sql-null) would be a closure that constantly returned the same instance, while (sql-null?) was just a record predicate, as in your example. I *believe* that if multiple modules include (define-record sql-null ...), that the predicates will work across definitions. E.g. if your module defines a sql-null record, and mine does too, then instances of your type will satisfy my predicate, as long as the type-names match. This is *ugly*, but it would be better than forcing each db egg to dynamically link to some sql-null egg. This is not a terrible answer for the sql API, though perhaps more terrible for other APIs, and I don't think it would be bad to solve both problems at once (the sql-null, and the well-intentioned 'abuse' of (void) in current eggs). A new immediate value IMHO the best option, and it could be useful for other APIs too, but if Felix says no he's probably right. My preference by far, too. Thanks for this summary, Tobia, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
felix winkelmann scripsit: No, we realize that just as we need only one empty list (unlike Java, where any list can have zero elements without losing its identity), we need only one object that has: a unique identity, disjoint from all other objects a unique type, disjoint from all other types no information inside it Why do we need this? I can't remember right now... To represent the null object of foreign environments that do not conflate null with the empty sequence -- not only SQL but also Lua, Java (and other JVM languages), .NET, and others. While this is an additional immediate object, it's only *one* additional immediate object. I support it. -- Said Agatha Christie / To E. Philips Oppenheim John Cowan Who is this Hemingway? / Who is this Proust? [EMAIL PROTECTED] Who is this Vladimir / Whatchamacallum, http://www.ccil.org/~cowan This neopostrealist / Rabble? she groused. --George Starbuck, Pith and Vinegar ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
Graham Fawcett scripsit: For representing sql-null, the special immediate-type solution is best because it's unambiguous. If that were ruled out, simply using the symbol 'null -- and forbidding database layers from returning symbols as output-values other than 'null -- would be my second choice, but it's an inferior solution, and I have a feeling I'd regret it later. It also doesn't scale to foreign environments other than SQL ones. But please not '(), for the same reason not #f, 0, or an empty string. +1 I don't want to see a circus of immediate types either, but one more isn't horrible. I thought (void) was perfect for this, but I respect the concerns that have been raised. So, (void) needs a brother who has no semantic baggage. +1 -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat? No, I wouldn't, the beggar replied. Why is that? the Master asked. A Dinar doesn't go very far these days, Master.--Kehlog Albran Besides, the Temple of Toplat is across the street. The Profit ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
Thomas Chust scripsit: this is really a question of taste, isn't it? You could just as well argue that a NULL value should be of a type that is a subtype of every other existing type but contains no other concrete instances, which would imply that all the type predicates should return #t when applied to the NULL value. This makes a lot of sense when the NULL value is used to indicate the absence of an object reference and is the way it is handled in several object oriented languages. As far as I know, no OO language does that. They interpret (or IMHO misinterpret) a *static* declaration that a variable is of type Foo as meaning that it can contain a Foo or null, but nowhere is null *dynamically* a member of type Foo: tests analogous to number?, string?, etc. always return false on null. Haskell spells it out: a foo-typed variable can only hold a foo, and if you want it to be otherwise, you declare it as of type Maybe foo, which means it can hold either a Just foo (which you can unwrap to be a foo) or Nothing. OT: One of the Java puzzlers is this: Foo foo = null; foo.bar(); Under what circumstances does that *not* cause a NullPointerException? -- We are lost, lost. No name, no business, no Precious, nothing. Only empty. Only hungry: yes, we are hungry. A few little fishes, nassty bony little fishes, for a poor creature, and they say death. So wise they are; so just, so very just. --Gollum[EMAIL PROTECTED] http://ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Error building universal on 10.5
Hi, I tried building chicken 3.0.0 from source on Mac OS X 10.5.2 using the following command: make PLATFORM=macosx ARCH=universal And got the following error: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - dynamiclib -compatibility_version 1 -current_version 1.0 - install_name libchicken.dylib \ -o libchicken.dylib library.o eval.o extras.o lolevel.o utils.o tcp.o srfi-1.o srfi-4.o srfi-13.o srfi-14.o srfi-18.o posixunix.o regex.o regex-extras.o scheduler.o profiler.o stub.o match.o runtime.o pcre/pcre_compile.o pcre/pcre_config.o pcre/ pcre_dfa_exec.o pcre/pcre_exec.o pcre/pcre_fullinfo.o pcre/ pcre_get.o pcre/pcre_globals.o pcre/pcre_info.o pcre/ pcre_maketables.o pcre/pcre_newline.o pcre/pcre_ord2utf8.o pcre/ pcre_refcount.o pcre/pcre_study.o pcre/pcre_tables.o pcre/ pcre_try_flipped.o pcre/pcre_ucp_searchfuncs.o pcre/ pcre_valid_utf8.o pcre/pcre_version.o pcre/pcre_xclass.o pcre/ pcre_chartables.o apply-hack.universal.o -lm ld: library not found for -ldylib1.10.5.o collect2: ld returned 1 exit status ld: library not found for -ldylib1.10.5.o collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/Bl/BlVb4pxXGg8tGWkxFze1+U++ +TI/-Tmp-//ccVnFkTU.out (No such file or directory) make[1]: *** [libchicken.dylib] Error 1 make: *** [all] Error 2 Help? Thanks, - Greg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Error building universal on 10.5
dont know if this will help but i do this when i build universal on 10.5.1: export MACOSX_DEPLOYMENT_TARGET=10.4 make PLATFORM=macosx ARCH=universal On Feb 29, 2008, at 6:30 PM, Greg wrote: Hi, I tried building chicken 3.0.0 from source on Mac OS X 10.5.2 using the following command: make PLATFORM=macosx ARCH=universal And got the following error: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - dynamiclib -compatibility_version 1 -current_version 1.0 - install_name libchicken.dylib \ -o libchicken.dylib library.o eval.o extras.o lolevel.o utils.o tcp.o srfi-1.o srfi-4.o srfi-13.o srfi-14.o srfi-18.o posixunix.o regex.o regex-extras.o scheduler.o profiler.o stub.o match.o runtime.o pcre/pcre_compile.o pcre/pcre_config.o pcre/ pcre_dfa_exec.o pcre/pcre_exec.o pcre/pcre_fullinfo.o pcre/ pcre_get.o pcre/pcre_globals.o pcre/pcre_info.o pcre/ pcre_maketables.o pcre/pcre_newline.o pcre/pcre_ord2utf8.o pcre/ pcre_refcount.o pcre/pcre_study.o pcre/pcre_tables.o pcre/ pcre_try_flipped.o pcre/pcre_ucp_searchfuncs.o pcre/ pcre_valid_utf8.o pcre/pcre_version.o pcre/pcre_xclass.o pcre/ pcre_chartables.o apply-hack.universal.o -lm ld: library not found for -ldylib1.10.5.o collect2: ld returned 1 exit status ld: library not found for -ldylib1.10.5.o collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/Bl/BlVb4pxXGg8tGWkxFze1+U+ ++TI/-Tmp-//ccVnFkTU.out (No such file or directory) make[1]: *** [libchicken.dylib] Error 1 make: *** [all] Error 2 Help? Thanks, - Greg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] How can one get the latest html-dump of the doc?
How can one get the latest html-dump of the doc? Because there's only pointer to the wiki version of it, and the one in the distribution always seems outdated. Can't the source and dumped docs be made available in separate archives, so that the latter can be updated at more regular interval (only keeping the latest)? -- Adhi Hargo Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
Thomas Chust scripsit: for example in Java there are some places where the dynamic type of null is effectively a subtype of another class: // this returns (String)null and doesn't throw a ClassCastException foo.getClass().cast(null) c Yes, well, that is where static typing is done at runtime. So the static typing behaviour may differ from the dynamic one and it may be inconsistent. But a distinction between static and dynamic typing behaviour wouldn't apply to Scheme. True, and what I'm saying is that the dynamic behavior is the appropriate one. Of course I don't want to have the same typing mess as in Java in CHICKEN and I do think the whole practice of having nullable reference types (by default) is questionable. I just don't think it is completely canonical that the type of NULL should be disjoint from every other type, especially if you think of types as being sets (or classes) of objects. I do think of types as being named sets of objects (named, because then there are only denumerably many types). If Foo.bar is a static method this will work just fine ;-) Yup. But did you deduce that from first principles, or had you seen it before? -- John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan The penguin geeks is happy / As under the waves they lark The closed-source geeks ain't happy / They sad cause they in the dark But geeks in the dark is lucky / They in for a worser treat One day when the Borg go belly-up / Guess who wind up on the street. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] eggs unlimited 3
On Fri, Feb 29, 2008 at 5:54 PM, minh thu [EMAIL PROTECTED] wrote: Hi, The call/cc.org homepage points to eggs unlimited 2 and not 3 (via call/cc.org/eggs). That's correct.Thanks for reporting this. cheers felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On Fri, Feb 29, 2008 at 9:56 PM, John Cowan [EMAIL PROTECTED] wrote: Why do we need this? I can't remember right now... To represent the null object of foreign environments that do not conflate null with the empty sequence -- not only SQL but also Lua, Java (and other JVM languages), .NET, and others. When you look for a generic null or void object, that is used for a particular library, then any unique value is sufficient, whether immediate or not. As I already replied to Graham, immediacy vs. non-immediacy is an implementation detail and shouldn't concern us here. The performance benefit is negligible. I have the feeling that immediacy is desired by the proponents of a new unique void value because it *feels* right to them, not because there is any real requirement. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
felix winkelmann scripsit: When you look for a generic null or void object, that is used for a particular library, then any unique value is sufficient, whether immediate or not. I agree; however, this is not a matter of a particular library, but of a large number of libraries, not all of which have anything to do with databases. As I already replied to Graham, immediacy vs. non-immediacy is an implementation detail and shouldn't concern us here. I have already conceded this point. The issue is having a unique object universally available that is of a disjoint type. -- A mosquito cried out in his pain, John Cowan A chemist has poisoned my brain! http://www.ccil.org/~cowan The cause of his sorrow [EMAIL PROTECTED] Was para-dichloro- Diphenyltrichloroethane.(aka DDT) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
Tobia == Tobia Conforto [EMAIL PROTECTED] writes: Tobia What's wrong with the sql egg? Can't we just use Tobia that, maybe improve it a bit? Sure, I didn't mean to rule that out. The biggest issue I see with the sql egg right now is it currently hard-codes all values, generating a new SQL expression every time. You want it to be able to represent placeholder values (named or just with a ? as in Perl's DBI) allowing the backends to cache the SQL expression and apply it to different data. However, different backends represent this (and various other extensions we'll eventually want) in different ways. SQL could just generate a standard syntax that all the backends would have to support, but then they'd be reparsing the SQL string we just generated and then putting it back together in their own way. It makes more sense to integrate the SQL generation with the backends from the start. The issue isn't just with the actual query string generated either. We may want the high-level interface to always allow the LIMIT and OFFSET keywords to page results, even if the backend doesn't support it, by emulating it on the client side. This would have to be handled as a combination of query string generation and result set processing. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
