Re: [Chicken-users] R6RS immutable pair
Kon Lovett scripsit: > Hash-Consing? Permitted but not required, as I say. > You are suggesting contagion. I use this in the 'procedure-surface' > composite for example. Yes. However, there are alternative policies, like contagion towards mutability (mutable unless all are immutable) and others. > >Scheme would need new procedures MUTABLE-PAIR?, IMMUTABLE-PAIR?, > >IMMUTABLE-CONS, IMMUTABLE-LIST, MUTABLE->IMMUTABLE, and > >IMMUTABLE->MUTABLE. > > Mutable vs. Immutable should be a property of the object. Sorry, but > I don't think we need *-immutable versions of every ( > ...). Just a built-in flag and exception when a mutating > operation attempted. I think we're in agreement. IMMUTABLE->MUTABLE and its opposite would take either a list or a tree (to be decided) of one type and reconstruct it using conses of the other type. Otherwise, we just need the basic constructors CONS and LIST and some new discriminators. -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS immutable pair
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 12, 2006, at 2:42 PM, John Cowan wrote: Kon Lovett scripsit: I'd like to see the existing pairs left alone, and new immutable pairs without identity added. That is, (immutable-cons 1 2) is permitted (but not required) to return the same pair (in the sense of EQ?) every time it's called. Hash-Consing? All existing procedures would continue to work with immutable pairs except, of course, SET-CAR! and SET-CDR!. Some decision would have to be taken about procedures like APPEND that accept multiple arguments: my initial take is that they should produce immutable results unless all the arguments are mutable. You are suggesting contagion. I use this in the 'procedure-surface' composite for example. Scheme would need new procedures MUTABLE-PAIR?, IMMUTABLE-PAIR?, IMMUTABLE-CONS, IMMUTABLE-LIST, MUTABLE->IMMUTABLE, and IMMUTABLE->MUTABLE. Mutable vs. Immutable should be a property of the object. Sorry, but I don't think we need *-immutable versions of every ( ...). Just a built-in flag and exception when a mutating operation attempted. I think the R6RS editors are interested in Scheme source compiled. If it can be inferred that a datum is immutable then optimizations can be applied. -- John Cowan [EMAIL PROTECTED]http://ccil.org/~cowan Original line from The Warrior's Apprentice by Lois McMaster Bujold: "Only on Barrayar would pulling a loaded needler start a stampede toward one." English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to lose support instead of finding it when you threat with the charged weapon." Yes, the "Miles" stories are a fun read. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iEYEARECAAYFAkS1w74ACgkQJJNoeGe+5O7tUgCeMT/nMWe+gEeYszZG+gTzESN0 bhYAni5UBC4MI0yy+KlLx6prs+FjmDQG =hRDp -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] plists
On Jul 12, 2006, at 2:20 PM, Brandon J. Van Every wrote: benchmark/plists is a Scheme file. Is there a compelling reason why it doesn't have a .scm suffix? I'm a little unclear on how it's loaded and utilized, my Scheme skills being weak compared to my CMake skills. I will make whatever changes are needed to have it be plists.scm if someone points me in the right direction. It is used in cscbench.scm as a '-prologue' for "chicken" when compiling some files. Not really used as an include or source. Cheers, Brandon Van Every ___ 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] Chicken manual on galinha wiki now up to date
Hello! I have now completed the transition of the manual to the wiki at http://galinha.ucpel.tche.br/. Some rough edges still exist (and everybody willing to help clean them up is welcome), but this instance of the manual will from now on be the one that is official. The documentation is for version 2.325 (the current darcs/svn/egg version). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] check / srfi-78
Since there are not enough testing frameworks for chicken yet,
I've added the reference implementation of the SRFI-78
("check") testing tool to the egg repository.
cheers,
felix
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS immutable pair
Kon Lovett scripsit: > Anybody want to way in on the proposed immutability of pairs? FWIW, I > am ambivalent. My gut says NO but my heart says yes. This is the most > serious suggested change, IMHO. It doesn't just "break some existing > programs", it breaks with 50 years of lisp tradition. > > In Chicken 'set-c*r' is a common operator. Should pairs be immutable > something must replace them. I don't buy the suggestion of records or > vectors as a replacement, too heavy. I'd like to see the existing pairs left alone, and new immutable pairs without identity added. That is, (immutable-cons 1 2) is permitted (but not required) to return the same pair (in the sense of EQ?) every time it's called. All existing procedures would continue to work with immutable pairs except, of course, SET-CAR! and SET-CDR!. Some decision would have to be taken about procedures like APPEND that accept multiple arguments: my initial take is that they should produce immutable results unless all the arguments are mutable. Scheme would need new procedures MUTABLE-PAIR?, IMMUTABLE-PAIR?, IMMUTABLE-CONS, IMMUTABLE-LIST, MUTABLE->IMMUTABLE, and IMMUTABLE->MUTABLE. -- John Cowan [EMAIL PROTECTED]http://ccil.org/~cowan Original line from The Warrior's Apprentice by Lois McMaster Bujold: "Only on Barrayar would pulling a loaded needler start a stampede toward one." English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to lose support instead of finding it when you threat with the charged weapon." ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] plists
benchmark/plists is a Scheme file. Is there a compelling reason why it doesn't have a .scm suffix? I'm a little unclear on how it's loaded and utilized, my Scheme skills being weak compared to my CMake skills. I will make whatever changes are needed to have it be plists.scm if someone points me in the right direction. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken.css and chicken.pdf
John Cowan wrote: Brandon J. Van Every scripsit: I notice that the 2.315 tarball does not distribute chicken.css. Oddly, I cannot grep any reference to chicken.css in the source tree. Once upon a time I thought I saw something in a generated ./configure file somewhere for it, but now I can't find it. Please explain its purpose? It looks like some kind of double secret implicit makeinfo sort of thing. It's physically incorporated into the HTML files of the Chicken manual. So what's the build method? I don't find anything resembling an "include chicken.css" in chicken.texi, nor any reference to it anywhere in the Darcs tree. Also chicken.pdf is distributed but there's no way in the Darcs tree to build it as far as I can see. Please rectify so that CMake can create tarballs with chicken.pdf in 'em. The trouble is that carrying around a portable PDF-generation program is more trouble than it's worth. I don't care about Darcs having a program in it. I care about Darcs having a build method in it. I'm perfectly capable of installing whatever programs are necessary for the .pdf generation, or stubbing them if due to cost or complexity I can't install them. Also I don't see why chicken.pdf itself can't be in Darcs. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken.css and chicken.pdf
Brandon J. Van Every scripsit: > I notice that the 2.315 tarball does not distribute chicken.css. Oddly, > I cannot grep any reference to chicken.css in the source tree. Once > upon a time I thought I saw something in a generated ./configure file > somewhere for it, but now I can't find it. Please explain its purpose? > It looks like some kind of double secret implicit makeinfo sort of thing. It's physically incorporated into the HTML files of the Chicken manual. > Also chicken.pdf is distributed but there's no way in the Darcs tree to > build it as far as I can see. Please rectify so that CMake can create > tarballs with chicken.pdf in 'em. The trouble is that carrying around a portable PDF-generation program is more trouble than it's worth. -- All Gaul is divided into three parts: the part John Cowan that cooks with lard and goose fat, the parthttp://ccil.org/~cowan that cooks with olive oil, and the part that[EMAIL PROTECTED] cooks with butter. -- David Chessler ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken.css and chicken.pdf
I notice that the 2.315 tarball does not distribute chicken.css. Oddly, I cannot grep any reference to chicken.css in the source tree. Once upon a time I thought I saw something in a generated ./configure file somewhere for it, but now I can't find it. Please explain its purpose? It looks like some kind of double secret implicit makeinfo sort of thing. Also chicken.pdf is distributed but there's no way in the Darcs tree to build it as far as I can see. Please rectify so that CMake can create tarballs with chicken.pdf in 'em. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] FFI and allocation/garbage collection
Alex scripsit: > I was wondering how the FFI wraps C functions which return strings. When > the C strings are converted into Scheme strings, is the data copied (so > that the Scheme string is an ordinary GC-able Scheme object), or does > the Scheme string share the C string's data, so that automatic GC is not > possible? There are three cases, depending on what type a foreign-lambda or foreign-lambda* returns: c-string: The string contents are copied by Chicken. c-string*: The string contents are copied by Chicken and then freed (this is useful when the C side mallocs a string). c-pointer: Chicken gets a pointer object rather than a string object (the lolevel unit has tools for manipulating these) and the C side is responsible for keeping the string allocated. -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] FFI and allocation/garbage collection
Hello, I was wondering how the FFI wraps C functions which return strings. When the C strings are converted into Scheme strings, is the data copied (so that the Scheme string is an ordinary GC-able Scheme object), or does the Scheme string share the C string's data, so that automatic GC is not possible? Thanks, Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
