Re: [Chicken-users] Syntax of case expressions
Shawn W. wrote: On Feb 27, 2008, at 6:39 PM, Matt Gushee wrote: I have just written a 'string-case' macro--it is supposed to behave just like case, except that it uses string=? in place of eqv? as its equality predicate. Insert obligatory plug for my extended-cond egg, which has a version of case that takes an arbitrary predicate. There's also a generalized-case egg that's very similar (Mine also implements guard clauses from srfi-87) Those sound good. I was actually not trying to write a library for public consumption--I'm mainly just trying to learn how to write macros, and perhaps provide an example for others learning macros. -- Matt Gushee : Bantam - lightweight file manager : matt.gushee.net/software/bantam/ : : RASCL's A Simple Configuration Language : matt.gushee.net/rascl/ : ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] regex problem
On Thu, Feb 28, 2008 at 6:54 AM, Daishi Kato <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I got a segfault error.
> Sorry, I have no access to Trac right now.
>
> Daishi
>
> CHICKEN
> Version 3.0.0 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook ]
> (c)2000-2008 Felix L. Winkelmanncompiled 2008-02-28 on ganglia
> (Linux)
>
> #;1> (use regex)
> ; loading library regex ...
> #;2> (string-match (regexp "(a)*") (make-string 100 #\a))
>
> (""
> "a")
> #;3> (string-match (regexp "(a)*") (make-string 1000 #\a))
>
> (""
> "a")
> #;4> (string-match (regexp "(a)*") (make-string 1 #\a))
> zsh: segmentation fault (core dumped) rlwrap -s 1
> /usr/local/chicken-3.0.0/bin/csi
>
I have no idea. It dies somewhere deep in the PCRE code. Possibly some
internal buffer overflowing?
cheers,
felix
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] regex problem
On Fri, Feb 29, 2008 at 11:38:57AM +0100, felix winkelmann wrote:
> On Thu, Feb 28, 2008 at 6:54 AM, Daishi Kato <[EMAIL PROTECTED]> wrote:
> > Hi!
> >
> > I got a segfault error.
> > Sorry, I have no access to Trac right now.
> >
> > Daishi
> >
> > CHICKEN
> > Version 3.0.0 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook
> > ]
> > (c)2000-2008 Felix L. Winkelmanncompiled 2008-02-28 on ganglia
> > (Linux)
> >
> > #;1> (use regex)
> > ; loading library regex ...
> > #;2> (string-match (regexp "(a)*") (make-string 100 #\a))
> >
> > (""
> > "a")
> > #;3> (string-match (regexp "(a)*") (make-string 1000 #\a))
> >
> > (""
> > "a")
> > #;4> (string-match (regexp "(a)*") (make-string 1 #\a))
> > zsh: segmentation fault (core dumped) rlwrap -s 1
> > /usr/local/chicken-3.0.0/bin/csi
> >
>
> I have no idea. It dies somewhere deep in the PCRE code. Possibly some
> internal buffer overflowing?
Sounds likely. There have been several buffer overflow vulnerabilities
in PCRE recently. Try upgrading to the latest PCRE.
Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
pgp3EKBMR2Y7g.pgp
Description: PGP signature
___
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, 29 Feb 2008 01:31:38 +0100 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. Wouldn't define-record do the trick? Best wishes, Mario ___ 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: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)
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. 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)
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
Re: [Chicken-users] New immediate values (was: DBI)
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. -- The experiences of the past showJohn Cowan that there has always been a discrepancy[EMAIL PROTECTED] between plans and performance. http://www.ccil.org/~cowan --Emperor Hirohito, August 1945 ___ 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 # 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
Re: [Chicken-users] DBI
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. > > 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. 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 2:24 pm, John Cowan wrote: 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, Ah, true, I'd not thought of people using symbol? - good point. Ok, on which grounds, I'd accept a new type: 'token', perhaps. Which is basically a symbol but responds to token? rather than symbol?, and also, when you define one with (define-token bob), you get (define bob (make-token 'bob)) (define (bob? x) (eq x bob)). (and (bob? bob) (token? bob)). However, then people start writing meta-token-code that uses (token? ...) and we have to start from scratch with something else. So do we make the bold move of not defining (token? x)? 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] Debugging support
On Fri, Feb 29, 2008 at 11:50 AM, William Cook <[EMAIL PROTECTED]> wrote: > > 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? I guess you're not - it depends on what you need. It is relatively easy to decorate procedures in a running Scheme system with additional stuff, or to replace them temporarily by debugging versions (see also the "advice" egg). > Is this the right email list > to discuss this topic? Sure! cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Unfair question: best Lisp for web development?
Hi Robin, On Wed, 27 Feb 2008 16:15:07 -0800 Robin Lee Powell <[EMAIL PROTECTED]> wrote: > On Wed, Feb 27, 2008 at 09:29:08AM -0800, Robin Lee Powell wrote: > > > > I'm thinking of starting a .com; probably not an especially Web > > 2.0 sort of one, but maybe with some Ajax involved. I seem to be > > more comfortable with Lisps than anything else. > > > > Are there any compelling reasons to choose a Lisp other than > > Chicken (my current best-known) for that sort of thing? > > Just wanted to thank everyone for all the responses! I have nothing > useful to say in response to the individual posts, but there's some > great stuff in there. You may also wnat to take a look at this thread: http://thread.gmane.org/gmane.lisp.scheme.chicken/9078/focus=9079 Best wishes, Mario ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] eggs unlimited 3
Hi, The call/cc.org homepage points to eggs unlimited 2 and not 3 (via call/cc.org/eggs). Cheers, Thu ___ 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 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
I don't see that anyone's mentioned the existing sql-null egg yet. Is there anything wrong with it? http://chicken.wiki.br/sql-null Graham Fawcett wrote: 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 ___ 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
Re: [Chicken-users] Error building universal on 10.5
Thanks! That fixed it. Shouldn't this then be added to the OS X Makefile? I don't know if any of chicken's maintainers read this list... On Feb 29, 2008, at 7:45 PM, Heinrich Taube wrote: 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 ___ 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)
On 29. Februar 2008 17:28:37 -0500 John Cowan <[EMAIL PROTECTED]> wrote: 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. Hello, 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) There are also places where the language behaves differently, though: // this returns false null instanceof String 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. 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. [...] OT: One of the Java puzzlers is this: Foo foo = null; foo.bar(); Under what circumstances does that *not* cause a NullPointerException? If Foo.bar is a static method this will work just fine ;-) cu, Thomas -- Murphy's Law is recursive. Washing your car to make it rain doesn't work. ___ 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] How can one get the latest html-dump of the doc?
Hi Adhi, On Fri, Feb 29, 2008 at 8:29 PM, Adhi Hargo <[EMAIL PROTECTED]> wrote: > How can one get the latest html-dump of the doc? There isn't an official one, AFAIK. The wiki content is stored in the svn repo, and you can always get the latest version there, but it's in wiki markup, not HTML. I've set up a quick hack to snapshot the wiki from svn, and generate a tarball. It's available at http://cleo.uwindsor.ca/static/chickendoc.tgz Next week I'll set up a cron job to refresh this nightly; at the moment it is a snapshot of the wiki as of about an hour ago. Warning, there are probably some wiki elements that did not convert properly; I'm using a modified version of a script called wiki2html, described here: http://www.mail-archive.com/chicken-users@nongnu.org/msg07776.html It is not "perfect" but it is pretty good. Please let me know if this helps; if not, I'll probably not bother with the cron job. ;-) Graham ___ 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 4:45 PM, Graham Fawcett <[EMAIL PROTECTED]> wrote: > > 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. Yes, I guess you're right here. > > 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. > Wether an sql-null value is immediate or not is an implementation detail which has no relevance to the discussion of a DBI API. 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: > Wether an sql-null value is immediate or not is an implementation > detail which has no relevance to the discussion of a DBI API. Quite true. I have been using "immediate" rather illegitimately as a shorthand for "unique object of a disjoint type". However, I continue to insist that the need is not unique to DBI nor to SQL databases. -- John Cowan[EMAIL PROTECTED]http://ccil.org/~cowan The whole of Gaul is quartered into three halves. -- Julius Caesar ___ 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] How can one get the latest html-dump of the doc?
Hi folks, On Fri, 29 Feb 2008 22:50:58 -0500 "Graham Fawcett" <[EMAIL PROTECTED]> wrote: > On Fri, Feb 29, 2008 at 8:29 PM, Adhi Hargo <[EMAIL PROTECTED]> wrote: > > How can one get the latest html-dump of the doc? > > There isn't an official one, AFAIK. The wiki content is stored in the > svn repo, and you can always get the latest version there, but it's in > wiki markup, not HTML. > > I've set up a quick hack to snapshot the wiki from svn, and generate a > tarball. It's available at > > http://cleo.uwindsor.ca/static/chickendoc.tgz > > Next week I'll set up a cron job to refresh this nightly; at the > moment it is a snapshot of the wiki as of about an hour ago. > > Warning, there are probably some wiki elements that did not convert > properly; I'm using a modified version of a script called wiki2html, > described here: > > http://www.mail-archive.com/chicken-users@nongnu.org/msg07776.html > > It is not "perfect" but it is pretty good. I feel I should not be writing this, since it would make galinha very mad, but you can do something like: $ cd path/to/svn/repo/copy $ cd wiki $ mkdir html $ find -maxdepth 1 -type f | sed 's+./++' > wiki-files $ while read i; do wget "http://chicken.wiki.br/$i"; -O "html/$i.html"; done < wiki-files $ rm wiki-files It's not recommended, since it consumes lots of resources. The wiki2html script, which is the recommended, good enough approach, generates readable HTML, as Graham mentioned. Another alternative is the PDF manual you can get from http://chicken.wiki.br/dev-snapshots/2008/02/24/chicken.pdf (you should be able to get it from http://chicken.wiki.br/dev-snapshots/current/chicken.pdf, but it seems that since 02/25 the manual is not being generated, which indicates we have a bug. Thank you for having induced me to look at this -- I'm gonna trace the problem). Best wishes, Mario ___ 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
