Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
scheme packages and most active implementation
202 views
Skip to first unread message
Patrick Useldinger
Apr 15, 2012, 8:51:53 AM4/15/12
to
Hello
I've been playing around with a few Scheme implementations, and I'm
about to get serious about diving in some more. I've essentially tried
Racket, Bigloo, Chicken and Gambit. I very much like each of them for
their respective strengths, and I'm sure there are other useful
implementations around. I'm using OS X, potentially targeting other
platforms (Ubuntu, Windows, even z/OS if available).
Coming from Python, what I miss most is libraries a.k.a. extensions
a.k.a. eggs. Each implementation has its own extensions, but hardly
comparable in number and activity with Python. Also, there do not seem
to be many cross-implementation packages available, and the various
implementations do not implement the same RxRS levels.
So my question basically is: what is the most "active" implementation
available? In the sense that people using it contribute actively in
terms of packages, with an active mailing list and such. I don't mind
paying if the product is worth it.
Regards,
-Patrick
I've been playing around with a few Scheme implementations, and I'm
about to get serious about diving in some more. I've essentially tried
Racket, Bigloo, Chicken and Gambit. I very much like each of them for
their respective strengths, and I'm sure there are other useful
implementations around. I'm using OS X, potentially targeting other
platforms (Ubuntu, Windows, even z/OS if available).
Coming from Python, what I miss most is libraries a.k.a. extensions
a.k.a. eggs. Each implementation has its own extensions, but hardly
comparable in number and activity with Python. Also, there do not seem
to be many cross-implementation packages available, and the various
implementations do not implement the same RxRS levels.
So my question basically is: what is the most "active" implementation
available? In the sense that people using it contribute actively in
terms of packages, with an active mailing list and such. I don't mind
paying if the product is worth it.
Regards,
-Patrick
Aaron W. Hsu
Apr 15, 2012, 1:51:25 PM4/15/12
to
On Sun, 15 Apr 2012 05:51:53 -0700, Patrick Useldinger wrote:
> So my question basically is: what is the most "active" implementation
> available?
I am afraid that is a question with many answers. If you care about lots
> So my question basically is: what is the most "active" implementation
> available?
and lots of external libraries, Chicken and Racket are both well
respected for this, but on the other hand, there are Java or .NET based
implementations that can leverage all of the Java or .NET libraries, for
instance.
Additionally, there are implementations like Chez Scheme which have a lot
of active development on the core system, but less vocal sharing of
libraries. Indeed, most of these libraries have no explicit
"distribution" channel, so it is harder to find them, though they are out
there.
You should consider that there are portable libraries for many things,
and one can often port libraries from one system to another if they were
designed with that in mind, especially for many libraries that were
written on R6RS.
--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.
John Cowan
Apr 15, 2012, 2:57:01 PM4/15/12
to
On Sunday, April 15, 2012 1:51:25 PM UTC-4, Aaron W. Hsu wrote:
> I am afraid that is a question with many answers. If you care about lots
> and lots of external libraries, Chicken and Racket are both well
> respected for this,
I would say (without actually checking it; this *is* Usenet) that Racket has the larger library, but Chicken's eggs are more actively developed. Of course these things are subject to change.
> I am afraid that is a question with many answers. If you care about lots
> and lots of external libraries, Chicken and Racket are both well
> respected for this,
> but on the other hand, there are Java or .NET based
> implementations that can leverage all of the Java or .NET libraries, for
> instance.
> You should consider that there are portable libraries for many things,
> and one can often port libraries from one system to another if they were
> designed with that in mind, especially for many libraries that were
> written on R6RS.
--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo
namekuseijin
Apr 15, 2012, 4:32:53 PM4/15/12
to
Others had thorough answers, here's my frank view as a user for quite some years, knowing it after perl, python and the likes: Scheme was a minimalist academic language designed for teaching programming language concepts and to do research into programming language theory. It's just that people who graduated with a Scheme background had such a love for this small language that continued to provide more practical implementations.
Still, up until very recently it was still a pretty small language, not fit for most real programming out there, unless you turned every task into a nail/file so you could process it with your hammer or used an implementation-specific handler. Thus, it so happens, with so many implementations out there and such a small core of shared features, that portable libs were never quite a reality in schemeland.
Even coming up with such a lib used to be a much more bureaucratic process than simply making it available in the web: you provided a detailed account of what your lib was supposed to do and what features it provided, then watched people diss it and vote on it being ready for prime-time or not and then waited a few years until implementations would support it. This was the SRFI process. It is an peer-review academic process not able to cope with a patched online library world as those produced by open-source projects.
Nowadays I see PLT research with Scheme is mainly stalled and implementations are now gearing at being of some practical use, thus more focus on libraries. The R7RS small language seems to be quite about the same language as always, they are just wrestling over names for common features. No word yet on the big language...
Summing up, if you came here expecting batteries-included pythonism, you're in for a sad reality. If you've come in search of a simple, clear, regular language with enough flexibility and power in a small package and with awesome units for source code editing (with the right editor) in the form of s-exps, you're in for a treat, though.
OTOH, there are many such libs for python because there's only the one true implementation, right? How many python libs run on IronPython, Jython or even PyPy? If you restrict yourself to libs written in the language itself rather than wrappers to native libs, I guess you'd find about as many as portable scheme libs...
Still, up until very recently it was still a pretty small language, not fit for most real programming out there, unless you turned every task into a nail/file so you could process it with your hammer or used an implementation-specific handler. Thus, it so happens, with so many implementations out there and such a small core of shared features, that portable libs were never quite a reality in schemeland.
Even coming up with such a lib used to be a much more bureaucratic process than simply making it available in the web: you provided a detailed account of what your lib was supposed to do and what features it provided, then watched people diss it and vote on it being ready for prime-time or not and then waited a few years until implementations would support it. This was the SRFI process. It is an peer-review academic process not able to cope with a patched online library world as those produced by open-source projects.
Nowadays I see PLT research with Scheme is mainly stalled and implementations are now gearing at being of some practical use, thus more focus on libraries. The R7RS small language seems to be quite about the same language as always, they are just wrestling over names for common features. No word yet on the big language...
Summing up, if you came here expecting batteries-included pythonism, you're in for a sad reality. If you've come in search of a simple, clear, regular language with enough flexibility and power in a small package and with awesome units for source code editing (with the right editor) in the form of s-exps, you're in for a treat, though.
OTOH, there are many such libs for python because there's only the one true implementation, right? How many python libs run on IronPython, Jython or even PyPy? If you restrict yourself to libs written in the language itself rather than wrappers to native libs, I guess you'd find about as many as portable scheme libs...
John Cowan
Apr 15, 2012, 7:30:38 PM4/15/12
to
On Sunday, April 15, 2012 4:32:53 PM UTC-4, namekuseijin wrote:
> Even coming up with such a lib used to be a much more bureaucratic
> process than simply making it available in the web: you provided
> a detailed account of what your lib was supposed to do and what
> features it provided, then watched people diss it and vote on it
> being ready for prime-time or not and then waited a few years until
> implementations would support it. This was the SRFI process.
To be fair, SRFIs are more like PEPs than just like libraries.
> Even coming up with such a lib used to be a much more bureaucratic
> process than simply making it available in the web: you provided
> a detailed account of what your lib was supposed to do and what
> features it provided, then watched people diss it and vote on it
> being ready for prime-time or not and then waited a few years until
> implementations would support it. This was the SRFI process.
> The R7RS small language seems to be quite about the same language as always,
> they are just wrestling over names for common features.
> No word yet on the big language...
> OTOH, there are many such libs for python because there's only the one true
> implementation, right? How many python libs run on IronPython, Jython
> or even PyPy?
Beyond that, it depends on if the library you need depends on C.
Eli Barzilay
Apr 15, 2012, 7:40:21 PM4/15/12
to
John Cowan <johnw...@gmail.com> writes:
> On Sunday, April 15, 2012 1:51:25 PM UTC-4, Aaron W. Hsu wrote:
>
>> I am afraid that is a question with many answers. If you care
>> about lots and lots of external libraries, Chicken and Racket are
>> both well respected for this,
>
> I would say (without actually checking it; this *is* Usenet) that
> Racket has the larger library, but Chicken's eggs are more actively
> developed. Of course these things are subject to change.
Note that John is demonstrating here that on usenet you can say
> On Sunday, April 15, 2012 1:51:25 PM UTC-4, Aaron W. Hsu wrote:
>
>> I am afraid that is a question with many answers. If you care
>> about lots and lots of external libraries, Chicken and Racket are
>> both well respected for this,
>
> I would say (without actually checking it; this *is* Usenet) that
> Racket has the larger library, but Chicken's eggs are more actively
> developed. Of course these things are subject to change.
anything you want.
Racket's standard set of libraries is under extremely active
development, as it has in the past. New packages on planet are also
being added at roughly the same rate it had in the past.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
John Cowan
Apr 15, 2012, 8:06:47 PM4/15/12
to
On Sunday, April 15, 2012 7:40:21 PM UTC-4, Eli Barzilay wrote:
> Note that John is demonstrating here that on usenet you can say
> anything you want.
Apparently so.
> Note that John is demonstrating here that on usenet you can say
> anything you want.
> Racket's standard set of libraries is under extremely active
> development, as it has in the past. New packages on planet are also
> being added at roughly the same rate it had in the past.
Eli Barzilay
Apr 16, 2012, 1:52:00 AM4/16/12
to
Patrick Useldinger <use...@gmail.com> writes:
> So my question basically is: what is the most "active"
> implementation available? In the sense that people using it
> contribute actively in terms of packages, with an active mailing
> list and such. [...]
> So my question basically is: what is the most "active"
> implementation available? In the sense that people using it
> contribute actively in terms of packages, with an active mailing
Actually, mailing list activity is measurable: on a quick look at my
gnus list with unread message counts since around the beginning of
october I get:
258 messages for comp.lang.scheme
1055 messages on the two chicken lists
1445 for "all" scheme implementation lists except for chicken and
racket (where "all" is whatever I found on gmane)
4259 for the two racket lists
And for reference:
3362 for comp.lang.lisp
8625 for comp.lang.python
Patrick Useldinger
Apr 16, 2012, 11:51:30 AM4/16/12
to
On Sunday, April 15, 2012 7:51:25 PM UTC+2, Aaron W. Hsu wrote:
> Additionally, there are implementations like Chez Scheme which have a lot
> of active development on the core system, but less vocal sharing of
> libraries. Indeed, most of these libraries have no explicit
> "distribution" channel, so it is harder to find them, though they are out
> there.
Yes I'm aware that Chez Scheme is the holy grail in terms of performance and conformity to the standard. But I'm put off by the fact that the free version is limited and the price of the paid version is not even advertised, and I assume I'd need a license for each targeted platform.
> Additionally, there are implementations like Chez Scheme which have a lot
> of active development on the core system, but less vocal sharing of
> libraries. Indeed, most of these libraries have no explicit
> "distribution" channel, so it is harder to find them, though they are out
> there.
Furthermore, it hardly helps to make it hard to find libraries.
-Patrick
Patrick Useldinger
Apr 16, 2012, 11:55:25 AM4/16/12
to
On Sunday, April 15, 2012 8:57:01 PM UTC+2, John Cowan wrote:
> On Sunday, April 15, 2012 1:51:25 PM UTC-4, Aaron W. Hsu wrote:
> > but on the other hand, there are Java or .NET based
> > implementations that can leverage all of the Java or .NET libraries, for
> > instance.
>
> Specifically, Kawa and SISC (both R5RS+) on the JVM, and IronScheme (R6RS) on .NET.
After looking into Clojure, I admit I am put off by JRE-based implementations, since they seem to inherit limitations such as no tail call optimization. And they're not R6RS.
> On Sunday, April 15, 2012 1:51:25 PM UTC-4, Aaron W. Hsu wrote:
> > but on the other hand, there are Java or .NET based
> > implementations that can leverage all of the Java or .NET libraries, for
> > instance.
>
> Specifically, Kawa and SISC (both R5RS+) on the JVM, and IronScheme (R6RS) on .NET.
Nils M Holm
Apr 16, 2012, 1:31:05 PM4/16/12
to
Patrick Useldinger <use...@gmail.com> wrote:
> Yes I'm aware that Chez Scheme is the holy grail in terms of
> performance and conformity to the standard. But I'm put off by the
> fact that the free version is limited and the price of the paid
> version is not even advertised, and I assume I'd need a license for
> each targeted platform.
Ask them. Last time I checked, they had interesting plans for
> Yes I'm aware that Chez Scheme is the holy grail in terms of
> performance and conformity to the standard. But I'm put off by the
> fact that the free version is limited and the price of the paid
> version is not even advertised, and I assume I'd need a license for
> each targeted platform.
multiple platforms.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
namekuseijin
Apr 16, 2012, 2:25:46 PM4/16/12
to
Em segunda-feira, 16 de abril de 2012 02h52min00s UTC-3, Eli Barzilay escreveu:
> Patrick Useldinger <use...@gmail.com> writes:
>
> > So my question basically is: what is the most "active"
> > implementation available? In the sense that people using it
> > contribute actively in terms of packages, with an active mailing
> > list and such. [...]
>
> Actually, mailing list activity is measurable: on a quick look at my
> gnus list with unread message counts since around the beginning of
> october I get:
>
> 258 messages for comp.lang.scheme
mostly from clueless students wanting some free answers for scheme assignments.
> Patrick Useldinger <use...@gmail.com> writes:
>
> > So my question basically is: what is the most "active"
> > implementation available? In the sense that people using it
> > contribute actively in terms of packages, with an active mailing
> > list and such. [...]
>
> Actually, mailing list activity is measurable: on a quick look at my
> gnus list with unread message counts since around the beginning of
> october I get:
>
> 258 messages for comp.lang.scheme
> 1055 messages on the two chicken lists
>
> 1445 for "all" scheme implementation lists except for chicken and
> racket (where "all" is whatever I found on gmane)
> 4259 for the two racket lists
> 3362 for comp.lang.lisp
half of that begin spam or WJ's vitriol...
> 8625 for comp.lang.python
most of it real-work related...
John Cowan
Apr 16, 2012, 3:11:00 PM4/16/12
to
On Monday, April 16, 2012 11:55:25 AM UTC-4, Patrick Useldinger wrote:
> After looking into Clojure, I admit I am put off by JRE-based implementations,
> since they seem to inherit limitations such as no tail call optimization.
SISC is properly tail recursive and has full support for continuations. Kawa can run in two modes, properly tail recursive and tail-recursive only in cases the compiler can easily handle; the latter is more efficient, so you pays your money and you takes your choice.
> After looking into Clojure, I admit I am put off by JRE-based implementations,
> since they seem to inherit limitations such as no tail call optimization.
> And they're not R6RS.
Aaron W. Hsu
Apr 16, 2012, 5:04:07 PM4/16/12
to
On Mon, 16 Apr 2012 08:55:25 -0700, Patrick Useldinger wrote:
> After looking into Clojure, I admit I am put off by JRE-based
> implementations, since they seem to inherit limitations such as no tail
> call optimization. And they're not R6RS.
The developer for IronScheme seems like a nice enough chap.
> After looking into Clojure, I admit I am put off by JRE-based
> implementations, since they seem to inherit limitations such as no tail
> call optimization. And they're not R6RS.
Aaron W. Hsu
Apr 16, 2012, 5:08:32 PM4/16/12
to
On Mon, 16 Apr 2012 08:51:30 -0700, Patrick Useldinger wrote:
> Yes I'm aware that Chez Scheme is the holy grail in terms of performance
Hardly the holy grail, just a good quality implementation that has a
> Yes I'm aware that Chez Scheme is the holy grail in terms of performance
reputation for speed.
> and conformity to the standard.
> But I'm put off by the fact that the free version is limited
> the price of the paid version is not even
> advertised, and I assume I'd need a license for each targeted platform.
depending on various circumstances. The website could certainly do more
to make the costs clear.
> Furthermore, it hardly helps to make it hard to find libraries.
Scheme intentionally makes it hard, but simply that the official
developers have no interest in spending a large amount of time on
producing an implementation specific infrastructure for package
distribution. I am sure they would welcome a community driven effort on
this front.
I try to publish all of the Chez Scheme code that I hack on that might be
useful to other people in reasonable ways, but that takes a lot of effort
to maintain at times. I do publically release my collections of
libraries that I have made to work for Chez, including ports of the
portable SRFIs libraries, among others. That greatly expands the
usability of Chez's library system.
Patrick Useldinger
Apr 18, 2012, 2:01:14 PM4/18/12
to
Thanks everybody for your answers.
I'll stick with Racket for the moment, since is the most convenient (documentation, Editor, GUI facilities) and at the same time actively developed. And it certainly has what it takes to keep my mind busy. I also look forward to their book.
I appreciate the pointer to SISC, looks like a great implementation although development seems to have stalled 5 years ago.
And I certainly look forward to R7RS both "small" and "large".
I'll stick with Racket for the moment, since is the most convenient (documentation, Editor, GUI facilities) and at the same time actively developed. And it certainly has what it takes to keep my mind busy. I also look forward to their book.
I appreciate the pointer to SISC, looks like a great implementation although development seems to have stalled 5 years ago.
And I certainly look forward to R7RS both "small" and "large".
nick_keigh...@hotmail.com
May 8, 2012, 5:28:40 AM5/8/12
to
On Sunday, April 15, 2012 9:32:53 PM UTC+1, namekuseijin wrote:
<snip>
> Summing up, if you came here expecting batteries-included pythonism, you're in for a sad reality. If you've come in search of a simple, clear, regular language with enough flexibility and power in a small package and with awesome units for source code editing (with the right editor) in the form of s-exps, you're in for a treat, though.
what is "awesome" source code editing? What can you do with it that a bog-standard editor doesn't do? If the answer is EMACs then the price may be too high for me...
<snip>
> Summing up, if you came here expecting batteries-included pythonism, you're in for a sad reality. If you've come in search of a simple, clear, regular language with enough flexibility and power in a small package and with awesome units for source code editing (with the right editor) in the form of s-exps, you're in for a treat, though.
nick_keigh...@hotmail.com
May 8, 2012, 5:19:55 AM5/8/12
to
On Monday, April 16, 2012 12:30:38 AM UTC+1, John Cowan wrote:
> On Sunday, April 15, 2012 4:32:53 PM UTC-4, namekuseijin wrote:
<snip>
> On Sunday, April 15, 2012 4:32:53 PM UTC-4, namekuseijin wrote:
> > The R7RS small language seems to be quite about the same language as always,
>
> Somewhat bigger and better (IMHO) than R5RS. Simple records, simple library modules, a bunch of cleanup here and there.
<snip>
John Cowan
May 8, 2012, 7:56:56 AM5/8/12
to
On Monday, April 16, 2012 11:55:25 AM UTC-4, Patrick Useldinger wrote:
> After looking into Clojure, I admit I am put off by JRE-based
> implementations, since they seem to inherit limitations such
> as no tail call optimization. And they're not R6RS.
SISC is properly tail recursive.
> implementations, since they seem to inherit limitations such
> as no tail call optimization. And they're not R6RS.
John Cowan
May 8, 2012, 8:00:16 AM5/8/12
to
On Tuesday, May 8, 2012 5:19:55 AM UTC-4, nick_keigh...@hotmail.com wrote:
> string streams? (or whatever they're called). I find it easier to
> write test code if they exist.
String ports are in R7RS-small, yes. A fairly complete list of changes
> string streams? (or whatever they're called). I find it easier to
> write test code if they exist.
from R5RS (and, less complete, from R6RS) can be found at pp. 71-73 of
http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7rs-draft-6.pdf .
George Neuner
May 8, 2012, 1:19:33 PM5/8/12
to
handle only simple tail recursion.
With JNI support you can do Cheney-MTA on JRE, but CPS styled code
won't pass the verifier - which makes it unacceptable in many security
conscious settings.
George
0 new messages