[Chicken-users] r6rs-bytevectors for chicken 5
With his permission, I've turned John Cowan's r6rs-bytevectors implementation: https://github.com/scheme-requests-for-implementation/srfi-4/tree/master/contrib/cowan into a Chicken 5 egg here: https://github.com/dieggsy/r6rs-bytevectors I'm aware of the separate C4 implementation of r6rs-bytevectors. I originally tried to port that implementation to C5, but I had some trouble with that and I think John's implementation is a little more favorable for a couple reasons: - It's a little more recent and pretty much already written in C5 syntax - my changes were fairly minimal and trivial. - It implements a couple flonum operations in C - It has fairly extensive tests, which I've converted to use the test egg. It'd be nice to have this in the egg repo for Chicken 5, assuming I haven't made any glaring mistakes. - Diego A. Mundo ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [r6rs-discuss] WG1 and WG2 mailing lists now open to lurkers (forwarded)
---BeginMessage--- It is now possible to join the Scheme Reports WG1 and WG2 mailing lists either through the Google Groups websites (http://groups.google.com/group/scheme-reports-wg[12]) or in the usual way via email to scheme-reports-wg[12]-subscr...@googlegroups.com. Only members of the WG may post, however. This is offered as a service to the Scheme community; please propagate. -- John Cowan http://www.ccil.org/~cowan co...@ccil.org Would your name perchance be surname Puppet, given name Sock? --Rick Moen ___ r6rs-discuss mailing list r6rs-disc...@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss ---End Message--- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] R6RS Rant
On Jun 4, 2007, at 11:49 PM, felix winkelmann wrote: On 6/4/07, Mitchell Wand [EMAIL PROTECTED] wrote: We are sorry to report that Will Clinger has resigned from the Editors Committee, effective on May 21, 2007. We accept his resignation with regret and thank him for his service. According the Charter, the Steering Committee has three months to replace a resigning editor. The Steering Committee has therefore decided to wait until after the ratification ballot before taking steps to replace him. There goes another one... R6RS has become a debacle. Dropping consensus was a terrible idea. While it dooms Standard Scheme to a toy language wasteland it had the benefit of a stable, reliable, platform for extension. Taking SRFIs in popular use verbatim as the standard (ex: the inclusion of the KMP algorithm in SRFI-13) may not be the catholic response, but using close to 98% of the popular SRFIs gives us proven APIs. If I may be so bold, it seems the greatest issue is the library arena. Drop it. Define a core only. There is so many similar extensions of R5RS in std use that an agreeable R6RS would not be a rewrite of R5RS. (BTW, I think the full numeric tower extended characters/strings should be core. Doesn't mean a compiler can't be told to not use them.) I suspect there is a core in R6RS on which consensus can be reached. For example, why can't we just agree on a record concept sufficient to represent conditions. The issue of composite vs multiple inheritance shouldn't be a deal breaker. How an implementation provides record type composition shouldn't be a problem, so long as it does. And the holes. Hell, everyone deals with filenames, but R6RS has no API. Record inheritance but no pathname concept. Yeah, I would love algebraic type extension, multi-valued continuations (I use Feely's extension in F-operator for this but I don't think I should need to), delimited-continuations, reader/ printer extension, defined syntax vs. semantic phases, syntax extension, namespaces, packaging, ...) but we ain't gonna agree on it (or not most of it anyway). Rant, rant, ..., Kon cheers, felix ___ 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] R6RS Rant
Kon Lovett wrote: If I may be so bold, it seems the greatest issue is the library arena. Drop it. Define a core only. There is so many similar extensions of R5RS in std use that an agreeable R6RS would not be a rewrite of R5RS. (BTW, I think the full numeric tower extended characters/strings should be core. Doesn't mean a compiler can't be told to not use them.) What I miss most from R5RS is the user-visible way to include and/or define libraries. Today I use chicken and write (require-extension extension-names ...) but I'd love for this to be the same across most Schemes. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS Rant
On Jun 5, 2007, at 1:37 AM, Sunnan wrote: Kon Lovett wrote: snip What I miss most from R5RS is the user-visible way to include and/ or define libraries. Today I use chicken and write (require- extension extension-names ...) but I'd love for this to be the same across most Schemes. Umm, I might see my 60th birthday before packaging is core Scheme. (I don't think there should be anything else, except optional.) Well, 'require-extension' is an accepted SRFI. And Chicken does support 'require' (I use it in the bloom-filter egg, however it isn't PLT-Scheme compliant) 'load' (I use it in the 'procedure-surface' egg). But, yes. There is no agreement on the simple process of acquiring a library. Because, library is not a simple concept. Best Wishes, Kon Sunnan ___ 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] R6RS Rant
Umm, I might see my 60th birthday before packaging is core Scheme. (I don't think there should be anything else, except optional.) You forgot to mention your current age :) Well, 'require-extension' is an accepted SRFI. And Chicken does support 'require' (I use it in the bloom-filter egg, however it isn't PLT-Scheme compliant) 'load' (I use it in the 'procedure-surface' egg). require-extension is very useful, even just as a cross-platform way of loading SRFIs. But you should read the SRFI-55 mail archive to see the incredible opposition it draws from some folks. Or try asking for require-extension on the PLT or Scheme 48 mailing lists. Anyway... Two glaring omissions related to (load): 1) (include ...) is not standardized 2) no one has thought of specifying what nested (load) or nested (include) should do. That is, what happens when you have x.scm dir/y.scm dir/z.scm where x.scm does (load dir/y.scm), and y.scm does (load z.scm). Does dir/y.scm load the correct dir/z.scm, or the non-existent z.scm? Same for (include), of course. R5RS does not standardize this, neither do most implementations specify what they do. In practice, most schemes use the absolute path convention, while SISC uses the relative path convention. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS
On 5/18/07, Michael McDermott [EMAIL PROTECTED] wrote: Ubiquitous Unicode support I tend to look at requiring Unicode support as analogous to requiring the full numeric tower -- really important for some applications, and I have no beef with Chicken's solutions to both of these problems. Library/module system If and only if that standard library/module system takes off, I'll finally try to write portable Scheme. In the past I've resigned to just always writing implementation specific code (that could, with some effort, be ported). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] R6RS
It's a slow Friday afternoon, so let me pose a provocative, non-technical question: What does the impending ratification of the R6RS standard mean for Chicken, and for you? At the onset of R6RS' process, Felix shared his misgivings about its scope and substance. I doubt that Chicken's going to be R6RS-compliant. As a one-Scheme user, I'm not terribly concerned about Chicken's compliance with the new standard. But I would love to hear what others think of the process and how they might (or intend to) vote on the acceptance of the new draft. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS
On Fri, May 18, 2007 at 04:16:11PM -0400, Graham Fawcett wrote: It's a slow Friday afternoon, so let me pose a provocative, non-technical question: What does the impending ratification of the R6RS standard mean for Chicken, and for you? I'd love it if someone could point me to some kind of bottom-line overview of the new standard (what's new, what's being discarded, etc.) I've hunted around for such a thing and browsed through the spec itself, and while I see lots of detailed discussion about it, I haven't really been able to find a highlight reel for the new standard. I've also heard that Felix isn't crazy about it, but I haven't been able to find his formal pronouncements on the matter. I'm still fairly new to Scheme, so I'm not about to jump into the fray. I'd just like a sense of what's going on. Steve -- Stephen Ramsay Assistant Professor Department of English University of Nebraska at Lincoln PGP Public Key ID: 0xA38D7B11 http://lenz.unl.edu/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS
Hallo, On 5/18/07, Stephen Ramsay [EMAIL PROTECTED] wrote: I'd love it if someone could point me to some kind of bottom-line overview of the new standard (what's new, what's being discarded, etc.) I've hunted around for such a thing and browsed through the spec itself, and while I see lots of detailed discussion about it, I haven't really been able to find a highlight reel for the new standard. I've read the spec, and I'd say the most important change is the addition of libraries. Today all the major implementations have different syntaxes for creating libraries/modules, and r6rs now comes with official syntax and semantics for that. Also, there are the standard libraries. -- -alex http://www.ventonegro.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS
The bottom line is that you can think of the R6RS as an attempt to move Scheme into the mainstream. Scheme has been, throughout its existence, a minimalist language. This has been both its strength and its weakness. Its strength in that, because there is a great deal of latitude in the standard, many people can apply many different ideas to Scheme and, yet, there it is still Scheme. However, this creativity has caused a great many of versions to be created that are largely incompatible with one another in those extensions that make the language pragmatically useful. The SRFIs help, but it doesn't get things all the way there. For example, take the issue of OpenGL bindings in Chicken vs. Guile. They use a different naming scheme for bindings to the same library (this isn't a slam, just an example; I love Chicken and I have a mostly-finished OpenGL app written in it). R6RS tries to take a lot of the latitude out of those pragmatic areas. For those things that you will need to do regardless of implementation (SRFI 1 style list manipulation, character operations, etc.) the standard tries to set well, a standard, so that any compliant implementation will implement the same semantics, making programs more portable. Also in this direction is adding a library/module facility to the language (something that a lot of people have wanted for some time) and I18N'ing the language, to some small degree, by requiring true Unicode support. That said, I find some of the parts of the specification almost Draconian in nature, detracting from Scheme's mission as a lightweight flexible language. In this respect, IMHO, things have improved between the 5.91 draft and the 5.92 draft and we'll see how things go between 5.92 and 5.93. Anyway, here is a fairly decent highlight reel: - Ubiquitous Unicode support - Standardization of an API for lists (richer), sorting, records, I/O, filesystems, arithmetic, and syntax-case - Exceptions - Bytevectors (which I like) - Library/module system - Reduced leeway on some semantic issues (this one may not belong here anymore) Whether you like it or not is another matter, but this, I think, sums it up pretty well. Michael McDermott On 5/18/07, Stephen Ramsay [EMAIL PROTECTED] wrote: On Fri, May 18, 2007 at 04:16:11PM -0400, Graham Fawcett wrote: It's a slow Friday afternoon, so let me pose a provocative, non-technical question: What does the impending ratification of the R6RS standard mean for Chicken, and for you? I'd love it if someone could point me to some kind of bottom-line overview of the new standard (what's new, what's being discarded, etc.) I've hunted around for such a thing and browsed through the spec itself, and while I see lots of detailed discussion about it, I haven't really been able to find a highlight reel for the new standard. I've also heard that Felix isn't crazy about it, but I haven't been able to find his formal pronouncements on the matter. I'm still fairly new to Scheme, so I'm not about to jump into the fray. I'd just like a sense of what's going on. Steve -- Stephen Ramsay Assistant Professor Department of English University of Nebraska at Lincoln PGP Public Key ID: 0xA38D7B11 http://lenz.unl.edu/ ___ 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] 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
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: snip 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 (proc datatype ...). 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] R6RS immutable pair
On 7/2/06, Dan [EMAIL PROTECTED] wrote: Why isn't everyone up in arms about this? Doesn't this mean that many existing eggs, as well as extenral packages, and our own software, will break? Wouldn't a new (declare) form be sufficient? If they make pairs immutable, why not make vectors immutable as well? Heck, why not drop Scheme and pick up Haskell? Amen to that. I think making pairs immutable is a serious mistake. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS immutable pair
On 7/2/06, Kon Lovett [EMAIL PROTECTED] wrote: My naive thought is 'list' should be disjoint from 'pair', although how to achieve this escapes me. The message I get from section 5 is 'proper list' is a distinct type from 'circular list' 'improper list'. I agree, but ... From an implementation point of view, I think adding an additional pair type (transparent to normal list-processing procedures) and an immutability bit might work. Still, this will be extra overhead and not particularly clean to implement... cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS immutable pair
On Jul 2, 2006, at 20:00 AM, Ken wrote: Is the decision to drop set-c*r! final in R6RS? No. The editors are considering it they want considered feedback from the community. I think compiler writers should talk about the real gains to be had from immutable pairs. We can take as given the answer from regular Scheme programmers. Here my experience. Full text (formated and linked) at http://www.askemos.org/A92529c85ccc348aae277522d6d5b801e/mutable-pairs-position.html = Position Statement on Mutability of Pairs = Joerg F. Wittenberger In response to R6RS status report as of june 2006 I'd like to add my experience concerning section 5, on the mutability of pairs. Summary Non-mutability of pairs (i.e. all objects) creates a very different language than traditional Scheme. Such a setting allows to practically fulfil semantics of program execution and distributed shared state beyond feasibility on the basis of a arbitrary mutable store. I'm personally divided myself whether such a radical change should be made to the Scheme language. Having made first hand experience with the implementation of a side effect free dialect of Scheme and on the background of the reasoning, which lead to the Askemos project, I value the advantages of controlled mutability. However there is just too much good Scheme code out there, which should not be broken by radical language changes. Wouldn't it be better to add a new data type for those immutable pairs? == In Detail == === A Fictional Task === An international company has 5 owners from all over the world. Used to electronic cooperation as they are they want to elect their CEO online as well. A lack of trust make it difficult to decide whom of them should host the polling system. === Proposed Solution === The problem is solved by by hosting the polling system on all five interested sites simultaneously. The language system stores a copy of the programs continuation, in the example the polls counter, on each site. Each vote is counted at each site by this continuation. However execution is synchronised in byzantine agreement. Now, until three of those five partners collaborate there's no doubt about the result. But that's the point of an election anyway. So the aim is to design a language, which can implement justiciable processes. (For more (german) background see Rechtssicherheit im Netz (course of studies at HTWK Leipzig). The implementer is left with the problem that each mutation to the shared state has to be agreed. Thus speed of light limits what's feasible. Here immutable objects become advantageous. We escaped the problem by dedicating a kind of a coarse Scheme dialect to control persistent, replicated effects. These are intercepted by the agreement system. Another side effect free subset of Scheme is used to query the store and produce proposed modifications for the persistent part. For the programmer this boils down to implement two programs, the query part: (lambda (this request) body) =response and the proposal of the new state: (lambda (this request) body) =(values proposal digest). The proposal is (kind of a) Scheme program, which describes the (locally) proposed changes to the persistent state (i.e., the new continuation and variable assignments) and the final response of the transaction. However before the proposal is actually executed on all sites, byzantine agreement is sought on the cryptographic digest [something like (sha1-digest (with-output-to-string (lambda() (write proposal]. Since body never effects the store, complex computations can be done efficiently. Smart application design means in this context to require only a small number of persistent (distributed) transactions per user request. This makes the delay from the agreement protocol negotiable in exchange for the tamper proofed backup system. (The coarse grained language, being slow by design anyway, does slightly more: some meta data usually interesting in dispute, like date of creation and check sums to verify content integrity are maintained. Furthermore the runtime system provides a super user free permission management system. Eventually there's a resynchronisation protocol. But that's off topic here. For details see the white paper.) == Final Note == I hope I could demonstrate good reasons to have a standardised side effect free Scheme subset. Such a language can be used to encode processes defined by legally binding contracts in machine executable, tamper proofed way. But I'm not sure that this radical change should go into R6RS at the expense of breaking compatibility. Due to these concerns I'd rather vote for an optional language feature or a distinct data type. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] R6RS immutable pair
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Group, R6RS appears straightforward for Chicken (except for a lot of typing, the nagging read/write invariance of flonums, the undecided details of 'library', whatever I forgot - remind please). 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. My naive thought is 'list' should be disjoint from 'pair', although how to achieve this escapes me. The message I get from section 5 is 'proper list' is a distinct type from 'circular list' 'improper list'. I agree, but ... - - Capt Picard: Make it so, Number One. (wish it were that easy.) Best Wishes, Kon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iEYEARECAAYFAkSoABkACgkQJJNoeGe+5O5efACfRiUqQ0IN4M5QfRRL6AZD6Xws QBEAn1VlVeKAWaQx8l63EGM9xZpQ/w9Y =iBHz -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS immutable pair
just break some existing programs, it breaks with 50 years of lisp tradition. [...] would just be a rather drastical change... Why isn't everyone up in arms about this? Doesn't this mean that many existing eggs, as well as extenral packages, and our own software, will break? Wouldn't a new (declare) form be sufficient? If they make pairs immutable, why not make vectors immutable as well? Heck, why not drop Scheme and pick up Haskell? -- Dan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
