Gambit-list Août 2007

gambit-list@iro.umontreal.ca

34 participants
37 discussions

Hygienic macros failing?
by andrew cooke 20 Aoû '07

20 Aoû '07

I may be misunderstanding hygienic macros here, but as far as I can tell I am getting variable capture. (define-syntax bad (syntax-rules () ((_ (arg1 ...) (arg2 ...)) (receive (a b c) (values arg1 ...) (newline) (write (list arg2 ...)))))) (receive (a b c) (values 1 2 3) (bad (7 8 9) (a b c))) This displays (7 8 9) when arg2 should be (1 2 3) (the value of a b c in the calling code, not the value in "bad"). It can be avoided by using different variable names, but that should not be necessary, right? Thanks, Andrew PS Gambit Version 4.0 beta 22, on Suse linux 10.2, amd64.

5 6

Segfault while running Gambit; values/receive efficiency
by andrew cooke 19 Aoû '07

19 Aoû '07

Hi, Well, first of all this segfaults: qp6 napito: ./napito-base.scm Segmentation fault which I guess is a bug. But also, I got a bit carried away trying to remove function calls in matrix multiplication. I'd appreciate some advice - if the code worked, would it be efficient? In particular, do the values/receive pairs get "compiled away"? I hope the code is fairly obvious - I'm trying to unpack a list with contains the non-zero elements from a typical 2D geometric transform and then do the matrix multiplication on a point. Thanks, Andrew

2 5

(no subject)
by Bill Richter 18 Aoû '07

18 Aoû '07

From: Bill Richter <richter(a)fourier.math.northwestern.edu> To: pierarda(a)iro.umontreal.ca CC: Gambit-list(a)iro.umontreal.ca In-reply-to: <20070815222526.GA4299(a)iro.umontreal.ca> (message from Adrien Pierard on Wed, 15 Aug 2007 18:25:31 -0400) Subject: Re: My R6RS vote References: <200708141836.l7EIaEsN016313(a)fourier.math.northwestern.edu> <78987D97-CDC5-46FE-B15D-F5D4F663CDA2(a)iro.umontreal.ca> <200708151939.l7FJdblS030238(a)whitney.math.northwestern.edu> <20070815222526.GA4299(a)iro.umontreal.ca> Roughly, DS is not important in CS for the Schemer, Thanks, Adrien, and I'll take your word on this. Let's not have a Math discussion (though your category theory sounds fun!) of languages other than Scheme. The relevance of your remarks is that it's pretty odd for the Scheme standard (R5RS) to use DS to specify the language, since DS isn't important in Scheme. Clinger's mean-spirited FAQ that Rush cited shows Clinger isn't a competent pure mathematician, as Clinger failed to understand my simple results, even if he had the legalistic skill to avoid posting any errors of his own. And I'll repeat my question: what is this Scheme community which needs a standard? I'm certainly willing to believe that R6RS is a bad standard, because of the LC_v/DS indifference of the committee members, but I don't know why we (who is we?) need a standard at all.

1 0

Re: [gambit-list] Queinnec's Lisp in Small Pieces for CAN$3.95+shipping
by Harold Ancell 18 Aoû '07

18 Aoû '07

Yow, I somehow I had forgotten about the existence of this book; I can see why people are salivating over it. Too bad the posted price was too good to be true. At 10:22 PM 8/17/2007, Jeff Read wrote: >On 8/15/07, Guillaume Germain <guillaume.germain(a)gmail.com> wrote: >> >> R6RS! Wins the "prize" for me, certainly produced the biggest laugh this week, a week that needed all the humor it could get. >Since we're doing jokes, and since RnRS is itself based on a joke (a >play on the Algol report) -- earlier today I thought of a better name >which I think the newly inaugurated R5.97RS should be called by when >it becomes a final standard: GrandScheme. > >"Grand", of course, being French for large, which is the exact >opposite of the ideal for a Scheme standard. OH! I'll be here all >week! Not bad, but not as good as "R6RS!". We *do* need a distinctive name for that which we sincerely hope someday becomes "The Language Formerly Known As Scheme", assuming the Steering Committee doesn't do a major last minute intervention. I think I'll use GrandScheme for now, it works just as well for native English speakers. We also need a name for what we've got, the R5RS based implementations that will at most have a R6RS compatibility package (the route Larceny and Gauche will be taking). I've been using "UncommonScheme" as a working name; I don't dislike Common Lisp per se, but there's reasons I switched.... >Yes, I want the book pretty damn bad. So do I.... - Harold

3 4

Queinnec's Lisp in Small Pieces for CAN$3.95+shipping
by Bradley Lucier 17 Aoû '07

17 Aoû '07

Amazon.ca is selling Christian Queinnec's Lisp in Small Pieces for CAN $3.95+shipping (anywhere in the world): http://www.amazon.ca/Lisp-Small-Pieces-Christian-Queinnec/dp/ 0521545668/ref=pd_ts_b_1/702-2137623-1855264?ie=UTF8&s=books LiSP is now their #1 bestseller, bigger even than Harry Potter! Brad

11 13

(no subject)
by Bill Richter 16 Aoû '07

16 Aoû '07

From: Bill Richter <richter(a)fourier.math.northwestern.edu> To: feeley(a)iro.umontreal.ca CC: Gambit-list(a)iro.umontreal.ca In-reply-to: <5747EF6C-7E8E-4491-ADAB-C5E9170B7777(a)iro.umontreal.ca> (message from Marc Feeley on Mon, 13 Aug 2007 21:57:52 -0400) Subject: Re: [gambit-list] My R6RS vote References: <5FB2F0B7-F9FA-4193-8EED-307B3F4ACE50(a)iro.umontreal.ca> <46C02784.9060102(a)gentoo.org> <5747EF6C-7E8E-4491-ADAB-C5E9170B7777(a)iro.umontreal.ca> But Bigloo, Chicken, Gambit, ELK, MIT-scheme, SCM and STklos will almost certainly not adopt R6RS. Marc, can you give us some more context here? Are there any fast Scheme compilers that will adopt R6RS? Is there a split between the serious computations folks like you on one side? I don't know who I'd put on the other side, the egg-headed theoreticians maybe :) How did the R6RS come to embrace feature-creep?

6 8

webserver stuff with gambit
by Phil Dawes 15 Aoû '07

15 Aoû '07

Hi Gambit List, Has anybody done any production webserver stuff with Gambit? Specifically I'm after code to help with http 1.1 stuff like chunking, pipelining etc.. context: I'm building a distributed olap application with a web interface and ideally I'd like to handle potentually large imports and query results using a REST interface. Any tips gratefully received! Many thanks, Phil

1 0

My R6RS vote
by Marc Feeley 13 Aoû '07

13 Aoû '07

Some of you wanted to know why I am voting against ratification of the R6RS. Here are the details. Marc ( (email-address "feeley(a)iro.umontreal.ca") (draft-version "5.97") (ratify "No") (explanation " I am voting against ratification of the draft because the language it specifies violates some of the fundamental design goals and principles which are behind Scheme's fame and respect in the circle of programming languages. The proposed language is both too complex for the user to grasp easily and too complex to implement. One of R5RS Scheme's strengths is that it can be implemented with minimal effort, merely a few days for an experienced implementor. Because of this several implementations have come into existence whose collective features cover a wide range of niches (platform, speed, size, interoperability, debuggability, ...). Among the over 50 existing Scheme implementations I believe at most 5 will have the energy to convert to the R6RS spec, and I fear that very few in the future will have the courage to embark on developing new implementations. The Scheme community will fragment and Scheme innovation will slowly die. It would be tedious to describe the detailed problems with the draft, and others have pointed out many of them. I will simply state some of the ones which are most obvious to me. 1) One of Scheme's strengths is its dynamic nature and in particular the ability to be used interactively through a REPL. The draft moves away from this by removing ``load'' and offering only a static linking model for programs. The draft does not explain how this affects program development and debugging using a REPL, which is the bread-and-butter of a large number of Scheme users. 2) Several features specified in the draft have been tested in existing implementations of Scheme insufficiently to warrant inclusion in the standard. Some features of the draft, such as the I/O system and records, are completely new and clearly suffer from feature creep. The standard is not the place to experiment. I do not think that R7RS can easily retract major features like these. A legitimate approach would be to use the SRFI process to introduce new features and APIs, to wait and see which SRFIs are adopted by users and implementors, and to standardize when there is a clear winner. For most features the last step could be skipped if the SRFI process was combined with a package repository in the spirit of Snow. This would remove the need for the whole ``Standard libraries'' document, and bring the language spec to a more palatable size. 3) The draft puts too much emphasis on performance. Is R5RS Scheme so slow that we need to introduce into the standard immutable variables, fields, and pairs? I am all for speed, but not at the expense of inconsistencies in the language design. Immutability hinders debugging and ``live-repair'', and goes against the basic design principles of Scheme: Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and **restrictions** that make additional features appear necessary. Given that the draft requires the full numeric tower and bignums, and that fixnum and flonum types have implementation dependent ranges, I see no need to require fixnum and flonum types in the standard. They should be moved to a SRFI. 4) The syntax for libraries is just too complex. Syntax-case is overkill. This is another unfortunate instance of feature creep. Scheme needs a simple module system that can be grasped easily. Scheme can live with the R5RS hygienic macros for a while still. ") )

7 9

Memory leak in GC?
by Bradley Lucier 13 Aoû '07

13 Aoû '07

Marc: My code seems to be leaking memory, and, of course, after an hour or so of debugging I can't find the source, so, again, I'm wondering if it's the GC bug that could be causing this. Such bugs are really insidious, even when they aren't the real cause of the problem, they distract the programmer from finding the real problem. And at least once the gc bug *was* the real problem, so it's hard to put it out of my mind ... My program gradually increased its memory usage until it got over 16GB, at which point I killed it. After I tried a fix, I ran it again with a bit of instrumentation, and the file below gives a little information about the rate of growth in the leak. This is with beta 22. Brad

1 0

Re: [gambit-list] My R6RS vote
by Harold Ancell 13 Aoû '07

13 Aoû '07

At 10:53 PM 8/12/2007, Jeff Read wrote: >Marc, > >On 8/12/07, Marc Feeley <feeley(a)iro.umontreal.ca> wrote: >> Some of you wanted to know why I am voting against ratification of >> the R6RS. Here are the details. > >You said it much better than I ever could. Certainly much better than I did, but I'm not (yet) an implementer, and my targets included the "minimalists", trying to get them to buy into a proper core (which R5.97RS most certainly is not) that includes an acceptable library system, and a set of official standard libraries that would include reference implementations, so the floor of a compliant although not very fast system is not too high, and we can hopefully enjoy the best of both worlds. Don't know if the above is really practical, but it was discussed on comp.lang.scheme and seems to be the best way to try to square this circle. I take it as a given that the "failure of the community to build a set of portable libraries" (to paraphrase one voter cited in my essay) needs to be addressed (properly!), and however we might e.g. like Snow, it's not getting buy-in from some comments people made.... But if I help to SMP Gambit, I sure don't want the core to be polluted by all that R5.97RS adds. That's the one tasty area where I want to do implementation work, although Marc's analysis of what it would require and the performance hit it would entail for Gambit is ... sobering. But I'd like to use Gambit in a multi-core world beyond the Termite NUMA model. - Harold

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Août 2007