Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Scheme advocacy: scheme vs. perl

5 views
Skip to first unread message

Brian Campbell

unread,
Nov 13, 2001, 12:37:34 AM11/13/01
to
I've been learning a lot of perl in my current job, and have found
that it supports a lot of the same features that scheme does. It has
higher order functions, lexical closures, eval, and plenty of other
nifty features. Perl 6 will even have continuations and real
tail-recursion, supposedly. So a co-worker of mine, who is a real perl
fan, asked me what advantages scheme had over perl, and I couldn't
really tell him anything other than "it's more elegant". I mean,
currently (as of perl 5) there are some definite advantages that
scheme has over perl; most schemes have real garbage collectors, and
perl doesn't have continuations or real tail call elimination yet. But
he's never run into problems with those limitations, and perl does
have one significant advantage over scheme, which is CPAN. We would
have had to do a lot more work on our current project if we hadn't
been able to just download SOAP::Lite and DBD::Oracle from CPAN.

Can anyone describe some real, useful cases in which scheme is
quantitatively better than perl, especially for the kind of thing I'm
doing right now, which is web services as an interface to a database,
or at least some ways in which you can express things so much more
easily in scheme than in perl that anyone reasonable would have to
admit that the scheme way is better? I realize what tail recursion and
continuations add, but for what we're doing, it wouldn't help us very
much, and perl seems to be catching up in all the areas that scheme
has been traditionally good at.

-- Brian Campbell
to email me, send to lambda (at) world (dot) std (dot) com

Kaz Kylheku

unread,
Nov 13, 2001, 1:38:30 AM11/13/01
to
In article <58562558.01111...@posting.google.com>, Brian

Campbell wrote:
>I've been learning a lot of perl in my current job, and have found
>that it supports a lot of the same features that scheme does. It has
>higher order functions, lexical closures, eval, and plenty of other
>nifty features. Perl 6 will even have continuations and real
>tail-recursion, supposedly.

Perl 6 will have continuations of bad hacks, and stepping on one's own tail.

:)

>So a co-worker of mine, who is a real perl
>fan, asked me what advantages scheme had over perl, and I couldn't
>really tell him anything other than "it's more elegant".

Perl's surface syntax makes it hard for perl code to be treated as data.
The perl implementation has a convoluted parser which turns apparent
line noise into some internal representation that is not accessible to
the programmer.

The property of being able to easily treat code as data is important if
you want to be able to write new language constructs with the same ease
that you write libraries of functions.

What is Perl's equivalent of define-syntax?

>much, and perl seems to be catching up in all the areas that scheme
>has been traditionally good at.

Not in this area, I suspect. Or am I wrong?

Anton van Straaten

unread,
Nov 13, 2001, 1:58:27 AM11/13/01
to
>I've been learning a lot of perl in my current job, and have found
>that it supports a lot of the same features that scheme does. It has
>higher order functions, lexical closures, eval, and plenty of other
>nifty features.

The same applies to e.g. Javascript, although you don't see a lot of people
suggesting that it be used for major development efforts (well, I guess
there's Mozilla...)

>Perl 6 will even have continuations and real tail-recursion, supposedly.

Scheme has these today, and they're important if you want to program in that
style - and you should want to! ;)

>I mean, currently (as of perl 5) there are some definite advantages that
>scheme has over perl; most schemes have real garbage collectors, and
>perl doesn't have continuations or real tail call elimination yet. But
>he's never run into problems with those limitations

He hasn't run into problems because he's programming in a conventional
imperative style. He's not taking full advantage of the features you've
mentioned. The fact that they're there doesn't really help, if they aren't
being used.

>and perl does
>have one significant advantage over scheme, which is CPAN. We would
>have had to do a lot more work on our current project if we hadn't
>been able to just download SOAP::Lite and DBD::Oracle from CPAN.

It's hard to refute this. I've used Perl myself in cases where CPAN has had
some functionality I wanted. But, I've also been called in to rescue a Perl
project which had grown beyond the bounds of rationality. Large-scale
programming is not something that I believe Perl is suited to. It's great
as glue - but not so great as an implementation language for complex logic.
However, the kinds of applications you mention - web services as an
interface to a database - are often little more than thick glue, and Perl
can be quite appropriate. There can be a danger in continuing to depend on
it if the requirement is enlarged, though.

>Can anyone describe some real, useful cases in which scheme is
>quantitatively better than perl, especially for the kind of thing I'm
>doing right now, which is web services as an interface to a database,

This probably isn't exactly what you were looking for, but take a look at:
http://youpou.lip6.fr/queinnec/VideoC/ps3i.html, which uses continuations to
implement low-overhead, transparent session and state support (and far more
than that) on a web server using Scheme. This goes beyond anything that
*any* commercial web server application I've ever seen can do. This can't
reasonably or practically be done in Perl right now.

>or at least some ways in which you can express things so much more
>easily in scheme than in perl that anyone reasonable would have to
>admit that the scheme way is better?

See above. See also the lightweight threading supported by Stackless Python
(http://www.stackless.com/), which uses continuations to implement
lightweight threads ("microthreads") - see:
http://www.onlamp.com/pub/a/python/2000/10/04/stackless-intro.html?page=2
A quote: "With microthreads, you can code these [simulation or game]
behaviors as Python functions. ... Microthreads switch faster and use much
less memory than OS threads. You can run thousands of microthreads
simultaneously." Of course, you can also do this sort of thing in Scheme.
The Python example simply illustrates something that Perl is currently
missing out on in this area.

>I realize what tail recursion and continuations add,
> but for what we're doing, it wouldn't help us very much

It might help you more than you think, if you expand your thinking beyond
the limitations of your current tools. The practical problem, though, is
that to do some of these things in the real world now, you'd have to go out
on some pretty slender limbs - slender in terms of real-world support. You
can tell your friend that Scheme is showing the way to what mainstream
systems will be able to do five or ten years from now - when Perl has
continuations, for example.

Whether you personally or professionally can take advantage of these
features now depends on what you're doing and whether it's worth the effort
and "risk", to you or to the project. Scheme doesn't provide a drop-in
replacement for *all* of Perl's functionality. That doesn't mean it can't
be used in the real world, only that it requires a little more effort in
some cases, and may not be ideal in others.

>perl seems to be catching up in all the areas that scheme
>has been traditionally good at.

I'll believe it when I see it - Perl 6 is rather low-density vapor right
now, I believe. But I think this trend is a good thing. Scheme has led the
way, but languages like Perl and Python are driving mainstream programming
languages in a useful and constructive direction.

But even if Perl had all of Scheme's key features, it would still be
instructive to learn Scheme or a more purely Scheme-like language, in order
to better understand the new features in Perl. After someone has learned
Scheme, they should understand why it's not as important to use Scheme in a
particular project, as it is to use the ideas and understanding that Scheme
embodies and represents.

Having descended into sheer lambda mysticism, I may as well go all the way
and point out that Scheme is not a language, it's a state of mind... :)

\Anton.

MJ Ray

unread,
Nov 13, 2001, 6:14:29 AM11/13/01
to
On Tue, 13 Nov 2001 06:58:27 GMT, Anton van Straaten <an...@appsolutions.com> wrote:
>It might help you more than you think, if you expand your thinking beyond
>the limitations of your current tools. The practical problem, though, is
>that to do some of these things in the real world now, you'd have to go out
>on some pretty slender limbs - slender in terms of real-world support.
[...]

Yes, I feel like I'm out on one of those limbs right now. There are some
really good support libraries out there for some scheme implementations and
I've developed the others which I need (although they are still inelegant in
many cases). The biggest problem is that it's so easy to use the
implementation's own functions, rather than stick to rnrs and slib and give
yourself some sort of portability. If I could make one request, it would be
that all extension library developers (myself included), used rnrs and slib
whenever possible.

I know that's not going to be popular and probably some people here can
point up serious problems in that tactic, but wouldn't it be the best way to
give scheme the support libraries it needs?

Why am I using scheme? Macros, mostly.

--
MJR

Bruce Lewis

unread,
Nov 13, 2001, 8:30:48 AM11/13/01
to
lambd...@yahoo.com (Brian Campbell) writes:

> Can anyone describe some real, useful cases in which scheme is
> quantitatively better than perl, especially for the kind of thing I'm
> doing right now, which is web services as an interface to a database,

Could you post a little web/database Perl code that you think is
particularly good? I find it hard to do effective advocacy without
examples.

Sander Vesik

unread,
Nov 13, 2001, 10:13:43 AM11/13/01
to


Just post a good web/database example written in scheme with explanation
why this particular case is good and where it's strengths might be?

Negative advocacy isn't imho much fun.

--
Sander

+++ Out of cheese error +++

Bruce Lewis

unread,
Nov 13, 2001, 12:20:42 PM11/13/01
to
Sander Vesik <san...@haldjas.folklore.ee> writes:

> Just post a good web/database example written in scheme with explanation
> why this particular case is good and where it's strengths might be?

My intent was to post the equivalent BRL after the OP posted some perl.
Doing it the other way around would be painful for the OP.

Here's an example with some explanation:

http://brl.sourceforge.net/brl_4.html#SEC26

I'd be interested in seeing the perl equivalent. Working code, please.
Not a summary of how it would work. The devil's in the details.

Sander Vesik

unread,
Nov 13, 2001, 1:47:46 PM11/13/01
to
Bruce Lewis <brl...@yahoo.com> wrote:
> Sander Vesik <san...@haldjas.folklore.ee> writes:

>> Just post a good web/database example written in scheme with explanation
>> why this particular case is good and where it's strengths might be?

> My intent was to post the equivalent BRL after the OP posted some perl.
> Doing it the other way around would be painful for the OP.

One problem I see with "equivalent" is that the programming styles one
normally uses in the two languages tend to be different. Yes, you can
do functional-like (ok, ok, functional) programming in perl but it is
often not the most convinient or intuitive way, and also the other
way around.

> Here's an example with some explanation:

> http://brl.sourceforge.net/brl_4.html#SEC26

> I'd be interested in seeing the perl equivalent. Working code, please.
> Not a summary of how it would work. The devil's in the details.

Haven't written with perl for some time, but a fast and dirty (and achieves
the same) would essentially be:
* walk through the array, transform it to a hash of color, list of
names pairs [foreach $i (@result) {has_add(colorhash, $i[0], $i[1])]
* walk through the keys of the hash and write out the result
[foreach $key (keys %colorhash) {blah}]

This is not really more code than lisp, if you really want to, I can
write it down (but I'm not advocating perl, so why me?).

Oh, and if you do any amount of web/cgi programming, you will have your
own (or your comapnies or whatever) version that prints out a
<li><custom highlight>blah:</custom highlist> list) stuff and similar.

Brian Campbell

unread,
Nov 13, 2001, 2:52:11 PM11/13/01
to
Bruce Lewis <brl...@yahoo.com> wrote in message news:<nm9wv0u...@buzzword-bingo.mit.edu>...

I can't paste an example right in here, since the code is proprietary,
but I can describe what I'm doing. We have two interfaces to the
database; one for humans to use in HTML::Mason and one for programs
using SOAP::Lite. I would say that from what I've seen, BRL might be
cleaner than HTML::Mason for the human interface, except for the
module facilities in HTML::Mason. But there are no SOAP libraries for
scheme, at least that I've seen. Also, there are some problems with
Java being slow, for our client side SOAP libraries, anyways. I don't
know how well it would perform on the server side.

Bruce Lewis

unread,
Nov 13, 2001, 3:33:47 PM11/13/01
to
lambd...@yahoo.com (Brian Campbell) writes:

> I would say that from what I've seen, BRL might be
> cleaner than HTML::Mason for the human interface, except for the
> module facilities in HTML::Mason.

Google searches for "module facilities HTML::Mason" and "modules
HTML::Mason" didn't turn up anything that looked like it might be what
you're referring to. Can you point to a doc on said facilities?

> But there are no SOAP libraries for
> scheme, at least that I've seen. Also, there are some problems with
> Java being slow, for our client side SOAP libraries, anyways. I don't
> know how well it would perform on the server side.

BRL is a tool for making output that's a mix of static/dynamic content.
There are certainly cleaner models to use for SOAP and other RPC.

Java has a high startup cost associated with finding, loading, verifying
and possibly JIT-compiling classes. This is less costly for
continuously-running server processes.

I don't do SOAP myself. I'm not clear on the relationship between SOAP
and XML-RPC, but would an XML-RPC lib be useful? Here's one for
MzScheme:
http://homepage.mac.com/phopkins/

Anton van Straaten

unread,
Nov 13, 2001, 3:54:37 PM11/13/01
to
Bruce Lewis wrote:
>Here's an example with some explanation:
>
>http://brl.sourceforge.net/brl_4.html#SEC26
>
>I'd be interested in seeing the perl equivalent. Working code, please.

I agree with Sander - in theory, this could be implemented functionally in
Perl, exactly as it is done in BRL; it could also be implemented equally
expressively in a more imperative style, as I will illustrate, so it doesn't
really address the original question: given that Perl supports higher order
functions and closures, what advantages does Scheme offer? Is traditional
web scripting really a good showcase for Scheme's strengths?

>Not a summary of how it would work. The devil's in the details.

You won't get me to write Perl for fun, but to satisfy your requirement for
working code, here's a JSP/Javascript version (written for Resin,
www.caucho.com), which deliberately uses imperative style, but is logically
equivalent to the BRL example:

<%@ page language="javascript" %>
<html>
<head><title>Favorite Colors</title></head>
<body>
<ul>
<%
import RowGroup;
var conn = new Database( "colors" );
var rs = conn.query( "select * from favcolor order by color, name" );
var grp = new RowGroup( rs );

while ( grp.next() ) {
if ( grp.isBeginning( "color" ) )
write( "<LI><STRONG>" + grp.row.color + "</STRONG>: " +
grp.row.name );
else
write( ", " + grp.row.name );
if ( grp.isEnding( "color" ) ) write( "\n" );
}
%>
</ul>
<p>Count: <%= grp.rowCount %></p>
</body>
</html>

This relies on a RowGroup object, which is generic, so would be part of a
shared library, just like BRL's runtime library. Here's the version I used
to test the above - this was extracted from a real system, stripped down,
and modified to look more like BRL's API. Although it supports the above
example, it's very basic, but obviously could be expanded as necessary:

function RowGroup( rs ) {
this.row = [];
this.prevRow = [];
this.nextRow = null;
this.rowCount = -1;

this.next = function () {
++this.rowCount;
if ( this.nextRow == null ) // first row
this.row = ( rs.next() ? rs.toObject() : false );
else {
this.prevRow = this.row;
this.row = this.nextRow;
}
this.nextRow = ( rs.next() ? rs.toObject() : false );
return (this.row != false);
}

this.isBeginning = function ( colName ) { return this.row[colName] !=
this.prevRow[colName]; }
this.isEnding = function ( colName ) { return this.nextRow == false ||
this.row[colName] != this.nextRow[colName]; }
}

The approach used above, of caching the previous and next rows, is useful if
one is doing something more than just simple grouping, and in fact that was
the original justification for the above.

Anton
P.S. being able to use <%@ page language="scheme" %> in JSP engines like
GNUJSP or Tomcat/Jasper would still be nice... The next frontier for BRL?
The killer app for Scheme in the commercial web application development
world??? :)

Bruce Lewis

unread,
Nov 13, 2001, 4:03:19 PM11/13/01
to
Sander Vesik <san...@haldjas.folklore.ee> writes:

> > Sander Vesik <san...@haldjas.folklore.ee> writes:
>
> One problem I see with "equivalent" is that the programming styles one
> normally uses in the two languages tend to be different. Yes, you can
> do functional-like (ok, ok, functional) programming in perl but it is
> often not the most convinient or intuitive way, and also the other
> way around.

Agreed. I meant functionally equivalent, not algorithmically
equivalent.

> Bruce Lewis <brl...@yahoo.com> wrote:
> > I'd be interested in seeing the perl equivalent. Working code, please.
> > Not a summary of how it would work. The devil's in the details.
>
> Haven't written with perl for some time, but a fast and dirty (and achieves
> the same) would essentially be:
> * walk through the array, transform it to a hash of color, list of
> names pairs [foreach $i (@result) {has_add(colorhash, $i[0], $i[1])]
> * walk through the keys of the hash and write out the result
> [foreach $key (keys %colorhash) {blah}]
>
> This is not really more code than lisp, if you really want to, I can
> write it down (but I'm not advocating perl, so why me?).

Because nobody else wants to? ;-) Feel free to put sample results in an
array and do array manipulation if setting up actual database code is
too much. Or, if it's too much to make complete working code, I'd be
willing to pit BRL against the English description of what the Perl code
would do. That would make things more even anyway. :-)

Does (keys %colorhash) return the keys in alphabetical order? If so,
lucky for this example. If not, be sure to sort accordingly.

Note that the BRL example pipelines nicely. Results are output as they
are retrieved from the database, not after they've all been received and
processed.

> Oh, and if you do any amount of web/cgi programming, you will have your
> own (or your comapnies or whatever) version that prints out a
> <li><custom highlight>blah:</custom highlist> list) stuff and similar.

Not a criticism, but I didn't understand the point you were making with
this last paragraph.

Bruce Lewis

unread,
Nov 13, 2001, 4:37:49 PM11/13/01
to
"Anton van Straaten" <an...@appsolutions.com> writes:

> You won't get me to write Perl for fun, but to satisfy your requirement for
> working code, here's a JSP/Javascript version (written for Resin,
> www.caucho.com), which deliberately uses imperative style, but is logically
> equivalent to the BRL example:

[ music plays; crowd roars ]

Congratulations, Anton van Straaten, on completing level one. Prepare
for level two.

In this level, you will have grouping within grouping, complicating
matters for your RowGroup object. Also, the outer group will be based
not on a named column, but on an expression based on a column. See if
you can still keep the RowGroup object generic.

> P.S. being able to use <%@ page language="scheme" %> in JSP engines like
> GNUJSP or Tomcat/Jasper would still be nice... The next frontier for BRL?
> The killer app for Scheme in the commercial web application development
> world??? :)

No. The JSP model converts
%>foo<%
to
(display "foo" some-output-port)

The BRL model converts
]foo[
to
"foo"

The latter is useful in more contexts. E.g. constructing e-mail
messages or dynamic SQL statements. See
http://brl.sourceforge.net/brl_4.html#SEC21

It may be in someone's interest to downgrade the BRL model to the JSP
model, but it certainly wouldn't be the "next frontier".

Now, here's working, tested code for level 2. Good luck!

[
(define conn (db1 brl-context))
(define st (brl-sql-statement brl-context conn))
]<html>


<head><title>Favorite Colors</title></head>
<body>

<ul>
[(define rowcount
(sql-repeat st (name color)
("select * from favcolor


order by color, name")

(brl-when (group-beginning? (string-ref color 0))
] <li> <strong>[(string-ref color 0)]</strong>
<ul>
[)
(if (group-beginning? color)
(brl ] <li><strong>[color]</strong>: [name)
(brl ", " name))
(brl-when (group-ending? color)
#\newline)
(brl-when (group-ending? (string-ref color 0))
] </ul>
[)))]
</ul>

<p>Count: [rowcount]</p>

</body>
</html>

Anton van Straaten

unread,
Nov 13, 2001, 5:28:52 PM11/13/01
to
Bruce Lewis wrote:
>In this level, you will have grouping within grouping, complicating
>matters for your RowGroup object. Also, the outer group will be based
>not on a named column, but on an expression based on a column. See if
>you can still keep the RowGroup object generic.

Before I write code to demonstrate that a generic object can do what you
want (which it can!) could you tell me what it is that you're claiming?
Certainly, to have groupings based on expressions, I would use closures -
whether in Javascript, Perl, Scheme, even perhaps closure-challenged Java.
That's why in my other message in this thread, I suggested (paraphrasing)
that a big point of Scheme was to learn about ways to solve problems in any
language, whether or not you end up using Scheme for a given project.

What is it that you're saying can be done in Scheme that can't be done in
other languages that have good support for higher-order functions and
closures?

>It may be in someone's interest to downgrade the BRL model to the JSP
>model, but it certainly wouldn't be the "next frontier".

I was thinking in terms of potential audience, not purely technical
capability. Offering an additional plug-in language to an existing,
standards-based template engine is a much easier sell than a new,
non-standard, replacement engine. If your goal were to have as many users
as possible using this technology, JSP probably *would* be the next
frontier. Of course, I realize that probably isn't your goal.

Anton

Anton van Straaten

unread,
Nov 13, 2001, 6:41:28 PM11/13/01
to
Bruce Lewis challenged:

>In this level, you will have grouping within grouping, complicating
>matters for your RowGroup object. Also, the outer group will be based
>not on a named column, but on an expression based on a column. See if
>you can still keep the RowGroup object generic.

I'm not sure why you think nested groups complicates matters for the
RowGroup object. The only change that was needed was to support basing
groups on expressions, which I chose to specify via closures, which seemed
most appropriate in this case. This is a vanilla translation of your
example, but I'll post another which cleans up the client code a bit
shortly.

I tested this against a small dataset of 12 rows, with two major groups and
three subgroups. If it has any bugs, I'm sure they can easily be fixed.

<%@ page language="javascript" %>

<html>
<head><title>Favorite Colors</title></head>
<body>
<ul>

<%
import RowGroup;
var conn = new Database( "jdbc/epas" );
var rs = conn.query( "" );


var grp = new RowGroup( rs );

while ( grp.next() ) {

if ( grp.isBeginning( function (row) { return
row.color.charAt(0) } ) )
write( "<li><strong>" + grp.row.color.charAt(0) +
"</strong>\n<ul>" );

if ( grp.isBeginning( "color" ) )

write( "<li><strong>" + grp.row.color + "</strong>: " +


grp.row.name );
else
write( ", " + grp.row.name );

if ( grp.isEnding( "color" ) ) write( "\n" );

if ( grp.isEnding( function (row) { return row.color.charAt(0) } ) )
write( "</ul>" );


}
%>
</ul>
<p>Count: <%= grp.rowCount %></p>
</body>
</html>

-----
And here's the new RowGroup object:
-----

function RowGroup( rs ) {
this.row = [];

this.prevRow = null;


this.nextRow = null;
this.rowCount = -1;

this.next = function () {
++this.rowCount;
if ( this.nextRow == null ) // first row
this.row = ( rs.next() ? rs.toObject() : false );
else {
this.prevRow = this.row;
this.row = this.nextRow;
}
this.nextRow = ( rs.next() ? rs.toObject() : false );
return (this.row != false);
}

this.isBeginning = function ( expr )

if ( this.prevRow == null )
return true;
else if ( typeof( expr ) == "function" )
return expr( this.row ) != expr( this.prevRow );
else
return this.row[expr] != this.prevRow[expr];
}

this.isEnding = function ( expr )

if ( this.nextRow == false )
return true;
else if ( typeof( expr ) == "function" )
return expr( this.row ) != expr( this.nextRow );
else
return this.row[expr] != this.nextRow[expr];
}
}


MJ Ray

unread,
Nov 13, 2001, 6:54:54 PM11/13/01
to
On Tue, 13 Nov 2001 20:54:37 GMT, Anton van Straaten <an...@appsolutions.com> wrote:
>really address the original question: given that Perl supports higher order
>functions and closures, what advantages does Scheme offer? Is traditional
>web scripting really a good showcase for Scheme's strengths?

Scheme offers you three advantages for traditional web scripting:
- ease of separation of concerns makes for faster development and easier
testing/debugging... perl doesn't even have an interpreter as standard;
- more elegant top-level code for the same results (OK, that one's hard to
justify);
- macros (because code is data);

but you're right, there's only two things there that can't be added to perl
easily.

If you really want to show off Scheme's unique capabilities, you really need
something like send/suspend from the PLT scheme webserver. Hopefully the
paper by Graunke et al, "Programming the Web with High-Level Programming
Languages" can be found by starting at http://www.plt-scheme.org/

The biggest challenge for scheme is that library support for useful
real-world tasks has been poor. This seems to be being addressed now and
I've found many of the libraries I need. Others I am developing without too
much difficulty and will release to the world when I can. Please do the
same.

MJR

Benjamin Simon

unread,
Nov 13, 2001, 7:43:50 PM11/13/01
to
>>>>> "Brian" == Brian Campbell <lambd...@yahoo.com> writes:

[snipped]

Brian> Perl 6 will even have continuations and real tail-recursion,
Brian> supposedly. So a co-worker of mine, who is a real perl fan,
Brian> asked me what advantages scheme had over perl, and I couldn't
Brian> really tell him anything other than "it's more elegant".

I'm not sure this is an advantage, but I think it is pretty safe to say
that scheme and perl represent two completely opposite styles of
programming languages (or language design). And if you like the style of
Scheme, then perl seems disgusting, and my guess is that perl folks feel
the same way about scheme.

See what I mean...

Perl has got it all. It's got C style functions, sed style regexps, awk
style BEGIN/END blocks, BASIC style report formatting (or so I've been
told), OOP, shell style automagic variables, goto statements, the
ability to eval your own perl code on demand, an embedded documentation
system for literal programming, shell style here documents, functional
style closures, a list of 25 different precedence rules, 8 different
quoting styles, AND now your telling me perl will have continuations and
tail-recursion. Of course it will, it's perl! And there's nothing wrong
with the previous list. In fact, I think it is kind of cool. All these
"features" go into a language that can support large OOP projects and
one-line shell commands alike.

And then there's scheme. With its cute 50 page specification and almost
no syntax. And it is incredibly powerful, as powerful as perl, if not
more so. It just goes about it in a totally different way. With scheme
you'll get the smallest most fundamental tools to do just about anything
you want. And with the cool macro support, you'll be able to do it in a
way that is convenient. You really have to try it to believe it. I
guess it comes down to that "elegance" you were talking about.

My recommendation would be to learn them both :-). Ideally, you should
use them both too. Recently I've embedded a scheme interpreter in a
Java swing application that I work on. Now, I can connect to the
application over a socket and talk scheme to the JVM. Finally, I got
emacs talking to my swing app! I get all the Java APIs, and scheme's
simple and interactive elegance. It turns out to be a might cool
combo. And I'm sure someone has embedded a scheme interpreter in perl...

Heck, that could be perl's next feature!

-Ben


Benjamin Simon

unread,
Nov 13, 2001, 7:45:32 PM11/13/01
to
>>>>> "Brian" == Brian Campbell <lambd...@yahoo.com> writes:

[snipped]

Brian> Perl 6 will even have continuations and real tail-recursion,
Brian> supposedly. So a co-worker of mine, who is a real perl fan,
Brian> asked me what advantages scheme had over perl, and I couldn't
Brian> really tell him anything other than "it's more elegant".

I'm not sure this is an advantage, but I think it is pretty safe to say
that scheme and perl represent two completely opposite styles of
programming languages (or language design). And if you like the style of
Scheme, then perl seems disgusting, and my guess is that perl folks feel
the same way about scheme.

See what I mean...

Perl has got it all. It's got C style functions, sed style regexps, awk
style BEGIN/END blocks, BASIC style report formatting (or so I've been
told), OOP, shell style automagic variables, goto statements, the
ability to eval your own perl code on demand, an embedded documentation
system for literal programming, shell style here documents, functional
style closures, a list of 25 different precedence rules, 8 different
quoting styles, AND now your telling me perl will have continuations and

tail-recursion [1]. Of course it will, it's perl! And there's nothing


wrong with the previous list. In fact, I think it is kind of cool. All
these "features" go into a language that can support large OOP projects
and one-line shell commands alike.

And then there's scheme. With its cute 50 page specification and almost
no syntax. And it is incredibly powerful, as powerful as perl, if not
more so. It just goes about it in a totally different way. With scheme
you'll get the smallest most fundamental tools to do just about anything
you want. And with the cool macro support, you'll be able to do it in a
way that is convenient. You really have to try it to believe it. I
guess it comes down to that "elegance" you were talking about.

My recommendation would be to learn them both :-). Ideally, you should
use them both too. Recently I've embedded a scheme interpreter in a
Java swing application that I work on. Now, I can connect to the
application over a socket and talk scheme to the JVM. Finally, I got
emacs talking to my swing app! I get all the Java APIs, and scheme's
simple and interactive elegance. It turns out to be a might cool
combo. And I'm sure someone has embedded a scheme interpreter in perl...

Heck, that could be perl's next feature!

-Ben

Footnotes:
[1] See: perlsyn(1), perlop(1), perlfun(1)


Jeffrey Siegal

unread,
Nov 13, 2001, 10:05:26 PM11/13/01
to
MJ Ray wrote:
> Why am I using scheme? Macros, mostly.

Over the years, I've come to appreciate macros and the power of S-exp
syntax in Lisp-family languages (whether Lisp-style low-level macros or
Scheme-style high-level macros) more than any other feature.

I've never used any other language where you can build more and more
complex facilities, extensions, and applications one on top of another
without at some point pushing the limit of the language's ability to
help managing complexity.

Anton van Straaten

unread,
Nov 13, 2001, 10:41:15 PM11/13/01
to
I wrote:
>I'll post another which cleans up the client code a bit[,] shortly.

What I did was add a "define" method to the RowGroup object to allow groups
to be defined and named up front, and subsequently accessed via expressions
of the form group.def.xxx.isBeginning(), where xxx is the name of the group.
For good measure, I added an equivalent for brl-when as a RowGroup method,
and wrapped the main client loop in a "with" block. The client code now
looks like this:

var group = new RowGroup( rs );
group.define( "initial", function (row) { return
row.color.charAt(0) } );
group.define( "color" ); // group based on column name

while ( group.next() ) with (group) {

when( def.initial.isBeginning(),
"<li><strong>" + row.color.charAt(0) + "</strong>\n<ul>" );

if ( def.color.isBeginning() )
write( "<li><strong>" + row.color + "</strong>: " + row.name );
else
write( ", " + row.name );

when( def.color.isEnding(), "\n" );
when( def.initial.isEnding(), "</ul>" );
}

This requires the following method definitions to be added to RowGroup:

this.define = function ( name, expr ) {
var outer = this;
if ( expr == null ) expr = name;
this.def[ name ] = ( typeof( expr ) == "function" ) ? {
isBeginning: function () { return outer.prevRow == null ||
xpr( outer.row ) != expr( outer.prevRow ) },
isEnding: function () { return outer.nextRow == false ||
xpr( outer.row ) != expr( outer.nextRow ) }
}:{
isBeginning: function () { return outer.prevRow == null ||
outer.row[expr] != outer.prevRow[expr] },
isEnding: function () { return outer.nextRow == false ||
outer.row[expr] != outer.nextRow[expr] }
}
}

this.when = function ( condition, str ) { if (condition) write( str ); }

The original API still works, if those definitions are not removed, so
predefined groups and ad-hoc groups can be used interchangeably.

Anton

MJ Ray

unread,
Nov 13, 2001, 7:38:03 PM11/13/01
to
On Tue, 13 Nov 2001 23:41:28 GMT, Anton van Straaten <an...@appsolutions.com> wrote:
[some scripting]

Hey, I just had another idea why scheme is better for web scripting: it only
uses one type of brackets! If you enjoy typing <>, {}, [] and (), as well
as over-verbose closing brackets like </li>, then I think you're insane ;^)

--
MJR, not being entirely serious.

Bruce Lewis

unread,
Nov 14, 2001, 12:09:03 PM11/14/01
to
"Anton van Straaten" <an...@appsolutions.com> writes:

> What is it that you're saying can be done in Scheme that can't be done in
> other languages that have good support for higher-order functions and
> closures?

In a word, macros.

I'm in total agreement that higher-order functions and closures are the
building blocks for all sorts of useful constructs. With them, a
sufficiently educated programmer can do interesting things in many
different languages.

With macros, such constructs find more convenient expression, and are
accessible even to less-educated programmers. One needn't understand
anonymous functions to use (group-beginning? (string-ref color 0)). One
can just use a Scheme reference combined with an intuitive understanding
of grouping results.

Even for more-educated programmers, it's nice to save some keystrokes
and express things more concisely.

> Bruce Lewis wrote:
> >It may be in someone's interest to downgrade the BRL model to the JSP
> >model, but it certainly wouldn't be the "next frontier".
>
> I was thinking in terms of potential audience, not purely technical
> capability. Offering an additional plug-in language to an existing,
> standards-based template engine is a much easier sell than a new,
> non-standard, replacement engine. If your goal were to have as many users
> as possible using this technology, JSP probably *would* be the next
> frontier. Of course, I realize that probably isn't your goal.

My goal is not as many users as possible, but I do want to gain a
noisier user base. I'd like to show management more outside activity
involving BRL. However, I wouldn't want to do so at the cost of BRL's
most distinguishing feature.

You can give an HTML coder a JSP page and say, "everything outside the
<% and %> markers is yours." But that's not entirely true. Some of
what's his/hers is inside those markers, double-quoted and
backslash-escaped.

You could have used %> <% to mark those strings in your example, but you
didn't because the notation isn't convenient. Neither does anybody
else. What's the point of using a template engine if you hardly use
its notation?

What you couldn't have done is use %> and <% to mark static content that
is part of an e-mail message, or for that matter anything other than
output to the web page. With BRL, the square-bracket syntax is
available *and convenient* in any such context. A non-programmer can
just hit C-s ] in emacs to find something s/he can change.

The example code we've played with involved relatively simple HTML. The
more complex the markup, the more advantageous BRL's notation becomes.
And its convenience stays constant as code complexity increases.

David Rush

unread,
Nov 14, 2001, 1:07:48 PM11/14/01
to
Bruce Lewis <brl...@yahoo.com> writes:
> lambd...@yahoo.com (Brian Campbell) writes:
> > I would say that from what I've seen, BRL might be
> > cleaner than HTML::Mason for the human interface, except for the
> > module facilities in HTML::Mason.
>
> Google searches for "module facilities HTML::Mason" and "modules
> HTML::Mason" didn't turn up anything that looked like it might be what
> you're referring to. Can you point to a doc on said facilities?
>
> > But there are no SOAP libraries for
> > scheme, at least that I've seen.

Screw SOAP. I've been doing SOAPy things using s-expressions to/from
the SUnet web-server. S-expressions are simply better than XML for
data representation, anyway. Now if you want to talk about document
representation, it's a different story, but the XML world has very
thouroughly obfuscated the differences between the two, to the
detriment of the programming world at large.

What is that rule of thumb: Any sufficiently large program contains a
poorly-implemented Lisp environment...

> I don't do SOAP myself. I'm not clear on the relationship between SOAP
> and XML-RPC, but would an XML-RPC lib be useful? Here's one for
> MzScheme:
> http://homepage.mac.com/phopkins/

SOAP == XML-RPC for all intents and purposes. Anybody who says
differently is misunderstanding a few things about object-orientation
and distributed computing.

david rush
--
Who is frustrated from having to do more politics than code for the
last month...It's actually worse than writing in C++

Brian Campbell

unread,
Nov 14, 2001, 2:29:18 PM11/14/01
to
Bruce Lewis <brl...@yahoo.com> wrote in message news:<nm93d3i...@biohazard-cafe.mit.edu>...

> lambd...@yahoo.com (Brian Campbell) writes:
>
> > I would say that from what I've seen, BRL might be
> > cleaner than HTML::Mason for the human interface, except for the
> > module facilities in HTML::Mason.
>
> Google searches for "module facilities HTML::Mason" and "modules
> HTML::Mason" didn't turn up anything that looked like it might be what
> you're referring to. Can you point to a doc on said facilities?

Sorry, it calls them components, not modules. And the docs usually
refer to it as simply Mason, not HTML::Mason. The way components
interact is kind of kludgy, but useful (I guess that describes all of
perl). I haven't ever used BRL, but I didn't see any way to do
anything like including components in other components the way you can
in Mason.

http://www.masonhq.com/docs/manual/Devel.html

>
> > But there are no SOAP libraries for
> > scheme, at least that I've seen. Also, there are some problems with
> > Java being slow, for our client side SOAP libraries, anyways. I don't
> > know how well it would perform on the server side.
>
> BRL is a tool for making output that's a mix of static/dynamic content.
> There are certainly cleaner models to use for SOAP and other RPC.
>
> Java has a high startup cost associated with finding, loading, verifying
> and possibly JIT-compiling classes. This is less costly for
> continuously-running server processes.
>
> I don't do SOAP myself. I'm not clear on the relationship between SOAP
> and XML-RPC, but would an XML-RPC lib be useful? Here's one for
> MzScheme:
> http://homepage.mac.com/phopkins/

XML-RPC is much simpler than SOAP, and we are already fairly heavily
invested in SOAP. I've been considering writing my own SOAP libraries
for scheme, and seeing how they compare to the perl/java libraries.
SSAX looks fairly nice.

Have you ever considered porting BRL to another scheme? It looks like
some of it is fairly dependent on being run under Kawa, but it seems
to me that PLT scheme has all of the features you would need.

Sander Vesik

unread,
Nov 14, 2001, 2:35:52 PM11/14/01
to
Bruce Lewis <brl...@yahoo.com> wrote:
> Sander Vesik <san...@haldjas.folklore.ee> writes:

>> > Not a summary of how it would work. The devil's in the details.
>>
>> Haven't written with perl for some time, but a fast and dirty (and achieves
>> the same) would essentially be:
>> * walk through the array, transform it to a hash of color, list of
>> names pairs [foreach $i (@result) {has_add(colorhash, $i[0], $i[1])]
>> * walk through the keys of the hash and write out the result
>> [foreach $key (keys %colorhash) {blah}]
>>
>> This is not really more code than lisp, if you really want to, I can
>> write it down (but I'm not advocating perl, so why me?).

> Because nobody else wants to? ;-) Feel free to put sample results in an

I'm not sure where from you imply that i want to 8-)

> array and do array manipulation if setting up actual database code is
> too much. Or, if it's too much to make complete working code, I'd be
> willing to pit BRL against the English description of what the Perl code
> would do. That would make things more even anyway. :-)

> Does (keys %colorhash) return the keys in alphabetical order? If so,
> lucky for this example. If not, be sure to sort accordingly.

so make it foreach (sort keys % colorhash) -as a bonus, you get to choose
what and how you sort on. Yes, the in which orer we sort is something that
is likely to change a couple of times IRL.

> Note that the BRL example pipelines nicely. Results are output as they
> are retrieved from the database, not after they've all been received and
> processed.

Uhh... this assumes things about the specific database glue.

Bruce Lewis

unread,
Nov 14, 2001, 3:05:25 PM11/14/01
to
lambd...@yahoo.com (Brian Campbell) writes:

> I haven't ever used BRL, but I didn't see any way to do anything like
> including components in other components the way you can in Mason.

Not having had to do much in the way of content management so far, it
hasn't been high on my priority list.

If you don't mind using full file paths instead of relative URLs, you
can do
(brl-handle-request "/full/path" '())
wherever you want to output the result of another BRL page.

It would be wise to put some wrapper in sitedefs.scm around
brl-handle-request so that when I get around to making a cleaner system,
you'll only have to change one place.

There won't be anything analagous to Mason components that return
values. Functions are for returning values; BRL pages are for producing
output.

Bruce Lewis

unread,
Nov 14, 2001, 3:08:29 PM11/14/01
to
Sander Vesik <san...@haldjas.folklore.ee> writes:

> so make it foreach (sort keys % colorhash) -as a bonus, you get to choose
> what and how you sort on. Yes, the in which orer we sort is something that
> is likely to change a couple of times IRL.

Neither Scheme nor Perl can compete with SQL w.r.t. ease of sorting, so
it's best to just preserve the order they come in.

Ed Dengler

unread,
Nov 14, 2001, 5:59:04 PM11/14/01
to
Greetings all!

In article <slrn9v3cme.3...@cloaked.freeserve.co.uk>,


MJ Ray <markj...@cloaked.freeserve.co.uk> wrote:
>
>The biggest challenge for scheme is that library support for useful
>real-world tasks has been poor. This seems to be being addressed now and
>I've found many of the libraries I need. Others I am developing without too
>much difficulty and will release to the world when I can. Please do the
>same.
>

While I would love to be an advocate for use of Scheme in web programming,
there are two major issues I have had problems with:

(1) Too many implementations. There is not a single stock reference
implementation that is accepted as the base for all others. Is there
a reason why there cannot be an agreed upon (rich!) implementation?

(2) Database support (and the corollary of better libraries for many tasks
such as CPAN). Is there a reason that there is not a supported,
all (or as much as reasonable) done in Scheme, interface to the
common databases such as Oracle, Paradox, Microsoft, Sybase, etc?
_Any_ real world task is most likely going to require accessing a
database (and web programming in particular). In the time I spent
looking, other than BRL (which cheats by going through JDBC), Guile
(which has modules that "are no longer supported"), and PLT (which
requires ODBC, which is not much help for Linux boxes), SIOD is the
_only_ implementation that seems to have a direct interface to
Oracle. (If anybody knows a good general _supported_ system for use
with the PLT derivatives, I would be interested!)

Didn't Pascal die because many basic operations (such as I/O) were
not supported, and so each version did it's own implementation? In
today's world, database accessing can be considered a defacto
requirement!

While Scheme is more elegant than Perl, Perl is _much_ more useful to
get things _done_ (and not just play). Where is the DBI equivalent
for Scheme? Don't get me wrong, I think Scheme is much more powerful,
but only in a theoretical sense. However, it only took me 5 minutes to
download the CPAN stuff and have a working connection to my database with
Perl!

Regards,
Ed

Anton van Straaten

unread,
Nov 14, 2001, 7:23:10 PM11/14/01
to
MJ Ray wrote...

>Hey, I just had another idea why scheme is better for web scripting: it
only
>uses one type of brackets! If you enjoy typing <>, {}, [] and (), as well
>as over-verbose closing brackets like </li>, then I think you're insane ;^)

You're joking, but it's a valid point, and I considered it while writing
that code. As Bruce pointed out, aside from the question of which type of
punctuation to use when, there's also the potential for confusion of the
non-expert due to the use of anonymous functions, which in Perl or
Javascript adds plenty of otherwise redundant punctuation and a keyword or
two ("function" and "return", in the Javascript case).

But I've been arguing something of a devil's advocate position, though,
prompted by the original question. If you're coming from the perspective of
knowing all the arcane syntax of a given language - and the original
example, Perl, certainly is king of the hill in that area - then arguments
like "the syntax is cleaner" aren't likely to have much effect. The answer
to that will be, in effect, "I've spent the last N years of my life rewiring
billions of neurons in my brain to support pattern matching of this syntax -
it's not complicated any more, it's how my brain works!"

So it seems to me that to sell the benefits of Scheme in these cases,
although cleaner syntax might be mentioned as a bullet-point item, it needs
to be an expendable one, and you need other, better examples. It's only
usually once someone has gained a familiarity with Scheme that they'll begin
to respect the advantages of the syntax - until then, you're more likely to
encounter resistance due to "all those parentheses".

Anton

MJ Ray

unread,
Nov 14, 2001, 8:24:05 PM11/14/01
to
On 14 Nov 2001 11:29:18 -0800, Brian Campbell <lambd...@yahoo.com> wrote:
>I haven't ever used BRL, but I didn't see any way to do anything like
>including components in other components the way you can in Mason.

Another system which is currently growing its guile interface is HB. It
looks rather more promising for component-based web applications, although
I'm still waiting to see if the potential problems I percieve are
surmountable:

http://bachue.com/hb/hb.cgi/

I'm also trying to convince them to add an XML-namespace-based equivalent
for the slightly odd custom tag names they use at the moment. I don't know
whether I'm being successful.

--
MJR

Shriram Krishnamurthi

unread,
Nov 14, 2001, 9:00:11 PM11/14/01
to
eade...@mud.uwaterloo.ca (Ed Dengler) writes:

> (1) Too many implementations. There is not a single stock reference
> implementation that is accepted as the base for all others. Is there
> a reason why there cannot be an agreed upon (rich!) implementation?

I agree to use PLT Scheme. You can do the same. Then neither you nor
I needs to worry about what anyone else uses. (You can pick a
different implementation if you wish; you will still find others who
agree with you.)

I find arguments about the number of Scheme implementations quite
unnecessary. Nobody reasonably complains that there's an
implementation called Python when there's already one called Perl.
They're different languages. They share some keywords and ideas, and
they differ in others. Why should we view PLT Scheme and Guile
differently? They don't even have a word in common in their names!

I've said several times on this newsgroup that I don't consider Scheme
a language. It's an idea. Or, A&S might say, it's a notation for
expressing algorithmic concepts. Turning that idea into a language
takes a lot of work. People will disagree on how to do that. Why
should they agree?

> (2) Database support (and the corollary of better libraries for many tasks
> such as CPAN).

PLT Scheme is getting there. Given the amount of time you probably
spend switching between implementations, I suspect you could just as
easily help us hack up whatever support is necessary to make life easy
enough for you on Linux. You could post on our user's list -- perhaps
others are in your boat. They may be interested in helping out.
Maybe we can just lift the code from SIOD?

> Didn't Pascal die because many basic operations (such as I/O) were
> not supported, and so each version did it's own implementation? In
> today's world, database accessing can be considered a defacto
> requirement!

I used Turbo Pascal on PCs for years for my consulting and
professional work. Indeed, I used it until I discovered Scheme. Now,
I wasn't part of any Turbo Pascal user's group (I was a high school
student in India), but I don't think too many users stopped using TP
because some Pascal written by a college student in the 70s didn't
have the necessary i/o operations ...

Shriram

MJ Ray

unread,
Nov 14, 2001, 9:20:03 PM11/14/01
to
On 14 Nov 2001 22:59:04 GMT, Ed Dengler <eade...@mud.uwaterloo.ca> wrote:
>While I would love to be an advocate for use of Scheme in web programming,
>there are two major issues I have had problems with:
>(1) Too many implementations. There is not a single stock reference
> implementation that is accepted as the base for all others.

Uh, RnRS?

> Is there
> a reason why there cannot be an agreed upon (rich!) implementation?

SLIB? OK, pretty much no-one seems to use that for some reason. Maybe the
older hands can explain to me why?

>(2) Database support

Yes, this is a weak spot at the moment.

> (and the corollary of better libraries for many tasks such as CPAN).

There are libraries and CPAN's mere existance doesn't make it any easier to
locate the right library for the job, IME. There appears to be not much of
a barrier to entry to CPAN and no easily-accessible ratings guides.

> Is there a reason that there is not a supported,
> all (or as much as reasonable) done in Scheme, interface to the
> common databases such as Oracle, Paradox, Microsoft, Sybase, etc?

I've got interfaces to the databases I use, most often postgresql. Oracle
is the only one of that list I can see me using any time soon, but it's not
imminent.

> _Any_ real world task is most likely going to require accessing a
> database (and web programming in particular).

No, most tasks do not, especially not GUI desktop and network applications.

> In the time I spent
> looking, other than BRL (which cheats by going through JDBC), Guile
> (which has modules that "are no longer supported")

Which ones? simplesql works.

> and PLT (which
> requires ODBC, which is not much help for Linux boxes),

Are you living in a cave? Sorry, but there are at least two ODBC
implementations for Linux and unixodbc definitely works with PLT's driver,
because I've used it.

> SIOD is the
> _only_ implementation that seems to have a direct interface to Oracle.

Can anyone tell me which RnRS SIOD is near? Is it dead now?

> (If anybody knows a good general _supported_ system for use
> with the PLT derivatives, I would be interested!)

Everything is supported if you have the money... ;-)

>While Scheme is more elegant than Perl, Perl is _much_ more useful to
>get things _done_ (and not just play).

Apart from Perl's major task, string processing, I must disagree.

>Where is the DBI equivalent for Scheme?

If you're using DBI naked in your application, I will come looking for you
with a big hunting knife if I ever have to work on it. ;-) Passing SQL
statements should be abstracted away at least once, at which point DBI is a
fairly trivial problem. Even though Perl's system is called "DBI", it
usually isn't used in a database-independent way, IME.

>Don't get me wrong, I think Scheme is much more powerful, but only in a
>theoretical sense. However, it only took me 5 minutes to download the CPAN
>stuff and have a working connection to my database with Perl!

Yes, database connectivity is the current weak spot, I think, but there
seems to be the will there to remedy that.

Anyway, surely all databases will be talking XML over TCP/IP sockets before
long now? ;-)

--
MJR

Anton van Straaten

unread,
Nov 14, 2001, 9:34:44 PM11/14/01
to
Bruce Lewis wrote:

>In a word, macros.

I agree with that one, but as I've said in a reply to MJ Ray, that's not an
easy sell to a programmer who's already comfortable with a syntax like
Perl's.

>You can give an HTML coder a JSP page and say, "everything outside the
><% and %> markers is yours." But that's not entirely true. Some of
>what's his/hers is inside those markers, double-quoted and
>backslash-escaped.
>
>You could have used %> <% to mark those strings in your example, but you
>didn't because the notation isn't convenient. Neither does anybody
>else. What's the point of using a template engine if you hardly use
>its notation?

These are valid points, to an extent, but JSP, ASP, Cold Fusion et al are
definitely a case of "worse is better". They work, and provide say 80% of
what people need, and the question is how important the remainder is. Your
objections to it are really an example of this: if the HTML coder situation
is an issue, one could simply mandate that the <% %> tags be used
religiously. It's also an exaggeration to say that "you hardly use its
notation" - in this particular example, where there was a single output line
embedded within pure script code, it's pretty common to do what I did. But
if you look at any complete JSP page, you'll see plenty of use of the tags,
so there's definitely a "point" to using the engine. It serves the purpose
and does the job.

As an aside, I deliberately avoided using a feature which I think may be
Resin-specific, which is the interpolated string, similar to Scheme's
quasiquote. One of our example lines would then be written as:
@"<li><strong>$(row.color.charAt(0))</strong>\n<ul>". It doesn't address
all of your objections, but it is easier to write than the fully-tagged
equivalent.

>What you couldn't have done is use %> and <% to mark static content that
>is part of an e-mail message, or for that matter anything other than
>output to the web page.

Unless I'm misunderstanding, that's not correct - JSP supports a contentType
directive and can certainly be used to generate XML, or comma-delimited
data, or any arbitrary data. The only real restriction that I'm aware of is
that it delivers its output via HTTP, with an HTTP header. As long as the
client is capable of receiving the data in that format, it can contain
anything you like.

>A non-programmer can
>just hit C-s ] in emacs to find something s/he can change.

We apparently live in different universes, which no doubt explains some of
our difference in perspective. I don't know any non-programmers who use
emacs. I don't even know any non-programmers who've *heard* of emacs. For
that matter, I know many *programmers* who've never heard of emacs...

>The example code we've played with involved relatively simple HTML. The
>more complex the markup, the more advantageous BRL's notation becomes.
>And its convenience stays constant as code complexity increases.

Just to be clear, I'm not saying that I don't think BRL is useful - on the
contrary, it looks as though you've done an excellent job with it. This
started out as a question of how to demonstrate the virtues of Scheme to a
Perl programmer who thinks that having some Scheme features in Perl is all
they'll ever need. I simply think that to address that question properly,
it is necessary to look beyond syntax and punctuation. I don't mean to
interfere with the promotion of BRL, though, and will try to refrain from
that in future! :)

Anton

Jeffrey Siegal

unread,
Nov 14, 2001, 9:43:36 PM11/14/01
to
Anton van Straaten wrote:
> These are valid points, to an extent, but JSP, ASP, Cold Fusion et al are
> definitely a case of "worse is better". They work, and provide say 80% of
> what people need, and the question is how important the remainder is.

They each do one thing well, perhaps even just as well as Lisp-based
approaches. That's fine, if you want to use a different tool for every
application. In 10 or 20 years, when many of us are still interested in
developing software, I have a feeling JSP, ASP, Cold Fusion, etc. will all be
a distant memory for everyone but legacy maintainers, yet Lisp-family
languages will still be going strong.

How many generations of special-purpose tools and non-extensible languages
has Lisp already outlasted?

Anton van Straaten

unread,
Nov 14, 2001, 9:49:49 PM11/14/01
to
MJ Ray wrote:
>If you really want to show off Scheme's unique capabilities, you really
need
>something like send/suspend from the PLT scheme webserver. Hopefully the
>paper by Graunke et al, "Programming the Web with High-Level Programming
>Languages" can be found by starting at http://www.plt-scheme.org/

I agree, and this is exactly what I was thinking of in my first response on
this thread. I used Queinnec's PS3I as an example, simply because it's
"released" and there's material on the web about it. I'm hoping to start
using PLT's send/suspend myself pretty soon, thereby hopefully eliminating a
bunch of icky state logic and global variables in the application in
question.

>The biggest challenge for scheme is that library support for useful
>real-world tasks has been poor. This seems to be being addressed now and
>I've found many of the libraries I need. Others I am developing without
too
>much difficulty and will release to the world when I can. Please do the
>same.

I plan to.

Anton

Anton van Straaten

unread,
Nov 14, 2001, 10:00:52 PM11/14/01
to
Jeffrey Siegal wrote:

An inarguable point, and one of the best yet, IMO.

Although, I have a horrible suspicion that in 10 or 20 years, the opening
message of a thread like this will go: "My friend is using Perl 12, and he
that says since it has continuations, exceptions, closures, tail calls,
static typing, dynamic typing, soft typing, polymorphic type inferencing,
macros, generics, templates, security sandboxing, and support for the APL
character set, why should he want to use or learn Scheme?" I think I'll sit
that thread out...

Anton

Ed Dengler

unread,
Nov 14, 2001, 9:46:33 PM11/14/01
to
Greetings all!

In article <w7dherw...@cs.brown.edu>,


Shriram Krishnamurthi <sk...@cs.brown.edu> wrote:
>I find arguments about the number of Scheme implementations quite
>unnecessary. Nobody reasonably complains that there's an
>implementation called Python when there's already one called Perl.
>They're different languages. They share some keywords and ideas, and
>they differ in others. Why should we view PLT Scheme and Guile
>differently? They don't even have a word in common in their names!

It isn't so much that there exists multiple implementations (from the
viewpoint that this allows experimentation, there is an argument that
many implementations are good). It is mostly that the effort of people
who like to put together libraries of stuff in Scheme are spread across
many (incompatible) versions. The libraries of Guile are not easily
ported to PLT or Chicken or Bigloo or ... (fill in favorite version
here). There are probably at least ten different foreign function
interface methodologies, ten different module systems, ten different
ways of how to code up a C function that can return data integratable
with Scheme functions, etc, etc, etc. All of these depend on which version
you want to run.

Look, CPAN is a great undertaking that has only been managed because
there is one (count them, one) standard implementation of Perl. Yes,
stuff breaks when they go up a notch, but the majority of effort is
concentrated. There are slight variants (eg, ActiveState) but they
attempt to stay very close to the standard and even back-contribute. I
do not have to worry about which operating system I am using, or which
system. Although some modules are specific to an architecture (the
ODBC support and stuff for DLLs), in general most of the functionality
to glue bits and pieces together are available from one spot. Even
ActiveState mostly supports the CPAN community.

This means great leverage. There is a community that can talk
specifics rather than just generalities (eg, how do I get this to call
a C function in Perl?). Scheme is broken up into many small
communities and each has their own ways of doing things. It requires
quite a bit of effort _on the part of an outsider_ to get to a
productive point. I cannot easily say to somebody, "You want to try
this out? Go to here, this is all the info you need, and here is _the_
standard that everybody is using in production." I can choose a couple
of implementations for people to play with, but they are _not_ complete,
and they do not look like they will be soon.

Please not that many of the functional languages are in the same boat.
Both Haskell and Miranda have multiple implementations, once again with
no standard libraries to get stuff done. Sad to say, Java may be leading
the way as more stuff gets placed into a common repository.

>I've said several times on this newsgroup that I don't consider Scheme
>a language. It's an idea. Or, A&S might say, it's a notation for
>expressing algorithmic concepts. Turning that idea into a language
>takes a lot of work. People will disagree on how to do that. Why
>should they agree?

As I said, as an idea, multiple implementations are great for
experimentation. But if you want to convince the greater community
_out there_, there has to be some consensus on what is good. Granted,
the two of us can agree to use PLT. But if there are ten strong
implementations, each implementation has only a 10th of the effort that
could be expended on putting together the things that really need to
make a system acceptable to the outside world. You don't have to
convince me to use it. You need to convince the Perl hacker, the web
programmer, the system admin writing scripts (eg, to use SCSH). In
todays world, there is no buy-in without either (a) a lot of money to
throw at the problem (ala Sun), or (b) a convincing production-level
system (and I don't mean just the core).

> but I don't think too many users stopped using TP
>because some Pascal written by a college student in the 70s didn't
>have the necessary i/o operations ...

I probably over-exaggerated a bit here (I used to work on Cybil which
was a Pascal-derivative from Control Data). However, even with Delphi,
Pascal is not a "mainstream" language. I mean this in the sense of
what people are looking forward to taking over the future, and what
people "expect" will live (I am pragmatic enough to believe that pretty
much any language that is actually used in industry will probably still
be around in 50 years). By this standard, Java is becoming a clear winner.

Perl is useful because people can get stuff done easily. There are
lots of examples, there are more and more libraries and tools coming
that can be integrated. Java is the same (and in many ways, more
"respectable"). If we want Scheme to be up there, we need to promote a
more united vision. Do I expect this? Realistically, no. Oh, there
will be implementations which get better, and Scheme will be used here
and there. But I do not expect it to break into the mainstream because
_it is too difficult to get started_.

I would love to see a standardized scheme plug-in for browsers. I am
sure it would blow away any current client-side scripting. Include the
ability for code migration. Put in a better sandbox. Integrate this
into Oracle or another database so we can have PL/Scheme. But which
version do we use? On which system will it run? Will it have all the
support needed? Will it provide database support (out of the box)?
Expert system support (out of the box)? XML support (out of the box)?
Security signing (out of the box)? Ability to do common web tasks like
fetch another page (out of the box)?

Regards,
Ed

Kaz Kylheku

unread,
Nov 14, 2001, 11:24:26 PM11/14/01
to
In article <EdGI7.42024$S4.37...@newsread1.prod.itd.earthlink.net>,
Anton van Straaten wrote:

>Jeffrey Siegal wrote:
>>How many generations of special-purpose tools and non-extensible languages
>>has Lisp already outlasted?
>>
>
>An inarguable point, and one of the best yet, IMO.
>
>Although, I have a horrible suspicion that in 10 or 20 years, the opening
>message of a thread like this will go: "My friend is using Perl 12, and he
>that says since it has continuations, exceptions, closures, tail calls,
>static typing, dynamic typing, soft typing, polymorphic type inferencing,
>macros, generics, templates, security sandboxing, and support for the APL
>character set, why should he want to use or learn Scheme?"

Any decent support for macro programming will likely mean that Perl will
have to expose its parse trees as a data structure. And, of course,
those trees will have a printed representation that uses parentheses...

Michael J. Fromberger

unread,
Nov 15, 2001, 12:07:07 AM11/15/01
to
In <58562558.01111...@posting.google.com> lambd...@yahoo.com (Brian Campbell) writes:

>I've been learning a lot of perl in my current job, and have found
>that it supports a lot of the same features that scheme does. [...]

>Can anyone describe some real, useful cases in which scheme is
>quantitatively better than perl, especially for the kind of thing I'm
>doing right now, which is web services as an interface to a database,
>or at least some ways in which you can express things so much more
>easily in scheme than in perl that anyone reasonable would have to
>admit that the scheme way is better? I realize what tail recursion
>and continuations add, but for what we're doing, it wouldn't help us
>very much, and perl seems to be catching up in all the areas that
>scheme has been traditionally good at.

Aw, man, Brian -- you had to know you were opening up a serious can of
worms when you wrote this one... :)

In my opinion, what Scheme has over Perl in spades is the combination
of clean, well-defined semantics, and a memory and execution model
that can actually be apprehended by reasonable human beings (well,
okay, most reasonable human beings don't really grok continuations,
but everything else is quite straightforward.

But in a very real software engineering sense, Scheme has a lot of
significant limitations, and I think you put your finger right on it
with CPAN. It's not just CPAN, but what it represents -- a large,
pretty well maintained library of code for Just About Everything. The
SRFI's are a pretty decent attempt at standardizing some of the things
Scheme is lacking to be a full-fledged development language, but the
fact remains, it's incomplete _as is_.

Given a choice, I'd program in Scheme rather than Perl any day of the
week. But I just can't afford to do that, and still get all my work
done. [So instead I try to fill young and impressionable minds with
the beauty of functional programming, so that in a couple of
generations, maybe I _will_ be able to do that]

*grin*

Cheers,
-M

--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/

"I think sex is better than logic, but I can't prove it."

Ozan Yigit

unread,
Nov 15, 2001, 12:40:18 AM11/15/01
to
eade...@mud.uwaterloo.ca (Ed Dengler) writes, amongst other good
things:

> ...Sad to say, Java may be leading


> the way as more stuff gets placed into a common repository.

why is this sad? it is something to learn from. we all know java's
deficiencies; one of them is that it sacrifices the rewards of diversity
through incompatible, self-satisfied implementations [reminiscent of the
twisty adventure mazes] that would make an adult cry in exchange for that
totally silly write-once-run-anywhere idea. it seems to work just fine for
now countless happy programmers getting work done. [i know this too is
called worse-is-better, in a humpty-dumpty sort of "worse" and "better"
and i sometimes think deep-is-shallow would be appropriate also... :)]

sorry for rambling again.

oz
---
www.cs.yorku.ca/~oz | if you couldn't find any weirdness, maybe
york u. computer science | we'll just have to make some! -- hobbes

Friedrich Dominicus

unread,
Nov 15, 2001, 3:00:53 AM11/15/01
to
sk...@cs.brown.edu (Shriram Krishnamurthi) writes:

> eade...@mud.uwaterloo.ca (Ed Dengler) writes:
>
> > (1) Too many implementations. There is not a single stock reference
> > implementation that is accepted as the base for all others. Is there
> > a reason why there cannot be an agreed upon (rich!) implementation?
>
> I agree to use PLT Scheme. You can do the same. Then neither you nor
> I needs to worry about what anyone else uses. (You can pick a
> different implementation if you wish; you will still find others who
> agree with you.)

Well I have to agree with Shiriam here. It's up to you to decide which
Scheme to use. But and this is a big but you can special adapted
Schemes. This is quite unique. E.g if you need full-fledges Schemes
you can take (please forgive me if I forget some)
- MzScheme (DrScheme)
- MIT-Scheme
- Open Scheme
- probably Guile too.
- anyother scheme + slib is quite a powerful Scheme too.

if you want to have an easy interface to Java you may check
- Kawa
- and or Silk

If you do web-programming (or the like) use
- BRL
- LAML

You'll find specilices Schemes e.g for GUI-Skripting. (STK?)

etc etc.

Anyway what did you gain. You got in principle a family of languages
which share much.

>
> > (2) Database support (and the corollary of better libraries for many tasks
> > such as CPAN).
>
> PLT Scheme is getting there. Given the amount of time you probably
> spend switching between implementations, I suspect you could just as
> easily help us hack up whatever support is necessary to make life easy
> enough for you on Linux. You could post on our user's list -- perhaps
> others are in your boat. They may be interested in helping out.
> Maybe we can just lift the code from SIOD?

That seems to me quite reasonable.

On the other hand you can switch to other Lispis or Schemeish
languages and got one of the largest standards available e.g in Common
Lisp. I do not say you should do that, just you should decide what's
necessary for you. If you decide that Perl is fine for you, it's your
choice. But why do you blame Scheme for things which are
"implementation" issues? As was pointed out elsewhere, Scheme is easy
to extend. Scheme can be the base for a billion of other languages if
that does not count for you, well don't use Scheme than.

Regards
Friedrich

Friedrich Dominicus

unread,
Nov 15, 2001, 3:13:10 AM11/15/01
to
eade...@mud.uwaterloo.ca (Ed Dengler) writes:

>
> Look, CPAN is a great undertaking that has only been managed because
> there is one (count them, one) standard implementation of Perl.

If you want either one implementation and/or a standard you can
- choose which Scheme fits you needs best
- choose Common Lisp
- choose another langauge

It's up to you. I find it ridicolous to ask programmers to work on one
thing if they don't feel so. Their decision is e.g to use MzScheme, if
the do not like the Mzscheme Way they take another Scheme. It's a
degree of freedom more that others offer, be it for good or bad.


>
> As I said, as an idea, multiple implementations are great for
> experimentation. But if you want to convince the greater community
> _out there_, there has to be some consensus on what is good.

Well we're talking about Schemes. So people have decided what is
good. You can see it in the RxRS documents. All Schemes share this
common ground (more or less) So the consensus is obvious
- Scheme should be small
- Schemes does just offer base elements, but does not take away you
freedom of how to combine that base elements (if you do not like that
than look at Common Lisp
- Functions, and Macros are essential parts.

>Granted,
> the two of us can agree to use PLT. But if there are ten strong
> implementations, each implementation has only a 10th of the effort that
> could be expended on putting together the things that really need to
> make a system acceptable to the outside world. You don't have to
> convince me to use it. You need to convince the Perl hacker, the web
> programmer, the system admin writing scripts (eg, to use SCSH). In
> todays world, there is no buy-in without either (a) a lot of money to
> throw at the problem (ala Sun), or (b) a convincing production-level
> system (and I don't mean just the core).

I do not have to convince anyone of anything. I can say it would be
nice if there were more Scheme programmers. But if I think it's good
for me, who else should care. I have to live with my decisions and
it's my freedom to choose.

>
> I probably over-exaggerated a bit here (I used to work on Cybil which
> was a Pascal-derivative from Control Data). However, even with Delphi,
> Pascal is not a "mainstream" language.

Wel than the only languages are Fortran and Cobol.

>I mean this in the sense of
> what people are looking forward to taking over the future, and what
> people "expect" will live (I am pragmatic enough to believe that pretty
> much any language that is actually used in industry will probably still
> be around in 50 years).

Well Lisp is around for more than 50 years. Scheme for around 30.


>By this standard, Java is becoming a clear winner.

That is damn wrong. Java in 50 years? Java has an extreme short
history in comparison to Schemes and especially for Lisps. It is far
younger than Smalltalk, C, Cobol, Fortran etc. So Java has no history
and if it will have a future is still open.

>
> Perl is useful because people can get stuff done easily.

I can do things easily with Scheme too. It depends on what I want to
do.

>Do I expect this? Realistically, no. Oh, there
> will be implementations which get better, and Scheme will be used here
> and there. But I do not expect it to break into the mainstream because
> _it is too difficult to get started_.

This is you opinion, and I fully disagree. It's totally easy to start
with Scheme.

>
> I would love to see a standardized scheme plug-in for browsers. I am
> sure it would blow away any current client-side scripting.

Use what is available. If it isn't available well than use something
else.

Friedrich

MJ Ray

unread,
Nov 15, 2001, 6:21:20 AM11/15/01
to

A couple of highlights. I don't pretend to disagree with everything you
say, not to endorse all the bits I don't quote.

On 15 Nov 2001 02:46:33 GMT, Ed Dengler <eade...@mud.uwaterloo.ca> wrote:
>There are probably at least ten different foreign function
>interface methodologies, ten different module systems, ten different
>ways of how to code up a C function that can return data integratable
>with Scheme functions, etc, etc, etc. All of these depend on which version
>you want to run.

Yes, for a while, I thought the guile API was going to win out, but
apparently not. I'm not too concerned about the FFIs being the same, as
that would be too restrictive for the implementations, nor even the module
systems, but it would be nice if some of the common modules could present a
common interface. I think this is happening with scsh ports, but not for
other things like databases yet.

>Look, CPAN is a great undertaking [...]

CPAN is bunk. It encourages people who don't know what they're doing to
destroy their system integrity by splattering files over an area that should
be under package manager control.

The notion of "one Perl" is bunk. The rapid version expenditure and
incompatibilties of extensions between them of Perl and Python irritate me.

>[...] But if there are ten strong implementations, each implementation has


>only a 10th of the effort that could be expended on putting together the
>things that really need to make a system acceptable to the outside world.

This is not a zero-sum game. If there was only one strong implementation,
we would certainly not have as many implementers exchanging ideas.

>(I am pragmatic enough to believe that pretty much any language that is
>actually used in industry will probably still be around in 50 years).

Come on, "industry" drops fashionable things as soon as they are out of
fashion. Java will probably be nowhere in 50 years. Lisps have already
been here nearly that long (I think).

> [...] But which version do we use? On which system will it run? Will it


>have all the support needed? Will it provide database support (out of the
>box)? Expert system support (out of the box)? XML support (out of the
>box)? Security signing (out of the box)? Ability to do common web tasks
>like fetch another page (out of the box)?

Kitchen sink (out of the box)?

Seriously, I'd like to see more work done on SLIB extensions, I think, but
I'm waiting to see if there's a reason why they're not used.
--
MJR

Ed Dengler

unread,
Nov 15, 2001, 10:24:56 AM11/15/01
to
Greetings all!

In article <874rnwo...@frown.here>,
Friedrich Dominicus <fr...@q-software-solutions.com> wrote:


>sk...@cs.brown.edu (Shriram Krishnamurthi) writes:
>
>Well I have to agree with Shiriam here. It's up to you to decide which
>Scheme to use. But and this is a big but you can special adapted
>Schemes. This is quite unique. E.g if you need full-fledges Schemes
>you can take (please forgive me if I forget some)
>- MzScheme (DrScheme)
>- MIT-Scheme
>- Open Scheme
>- probably Guile too.
>- anyother scheme + slib is quite a powerful Scheme too.
>
>if you want to have an easy interface to Java you may check
>- Kawa
>- and or Silk
>
>If you do web-programming (or the like) use
>- BRL
>- LAML
>

And this is _exactly_ what I am trying to point out. Look, I like
Scheme, I think it beats the heck out of all the XML garbage that is
getting promoted out there (anybody for programming using XML syntax,
*shudder*). I _personally_ appreciate the fact that there are many
_experimental_ implementations, that allow the testing of ideas. But
come on, let us be realistic. There is probably as many module systems
as there are Scheme implementations. This means if I build a custom
library using modules, I cannot count on this being easily ported to
another Scheme implementation. ("So don't use modules/namespaces/..."
Then where is the advantage to using Scheme?). Perl may have an awful
module system, but at least it is consistent.

>Anyway what did you gain. You got in principle a family of languages
>which share much.

And which disagree on any number of fundamental issues such as modules
and FFIs.


I have been hearing the old "why is not Scheme used more?" and its many
incarnations for a long time. If we want to be _realistic_ about this,
then we have to address the issues that people _who do not use Scheme
now_ see. And one of the big ones _is_ the fact that there is not a
single implementation that can be considered the _standard_, and which
will likely be supported by a community for a long time. We have many
different ideas, and many different approaches, and this is all _good_
from the theoretical sense. But if you want to talk to people who
believe that Java is heaven's language, then you need to address their
viewpoints. Otherwise, Scheme/Lisp will continue to exist for many
years to come, but will probably not make it to the mainstream.

Regards,
Ed

Bruce Lewis

unread,
Nov 15, 2001, 11:05:20 AM11/15/01
to
"Anton van Straaten" <an...@appsolutions.com> writes:

> These are valid points, to an extent, but JSP, ASP, Cold Fusion et al are
> definitely a case of "worse is better". They work, and provide say 80% of
> what people need, and the question is how important the remainder is.

Here I beg to differ. We've been talking in this thread about
interesting things that are easy in Scheme but hard in other languages.
However, the systems you list are missing features that web developers
need and are easy to implement in any language. In a few years they
will likely reach the "good enough" stage (except probably ASP/VBscript
won't), and it will be harder to advocate BRL.

Sure, *you* can implement a RowGroup object to get most of the way
there, but most programmers would prefer stuff like that built in. Even
a simple facility to escape <, >, & in HTML is something average
programmers would rather not implement themselves. With JSP they have
to, last I checked.

Cold Fusion is reputed to have easy, intuitive syntax. Actually it's
just easy to confuse with the static markup of the page. Here's an
example of real-world CF confusion I've been pointing to for years:

http://www.mbta.com/text-only/schedmaps/bus/bus.cfm?routenumber=85

Note that the title of this page is "MBTA Bus Route #routenumber#
Schedule". Obviously somebody didn't find CF syntax intuitive. The
same error would not have occurred with BRL. However, the CF parser
might someday be modified to warn of a possible error in such cases, and
it would be "good enough".

PHP has all the little knicknacks a web developer would want, but the
PHP community is too busy pointing out its superiority to ASP to notice
deficiencies in the database interface. Database independence is still
not common practice. It's still easy for newbies (or sleepy experienced
programmers) to do an infinite loop while processing database rows, just
by leaving out a line. Not good for server resources. It's
straightforward to create a construct analagous to BRL's sql-repeat that
prevents such problems. Expect PHP to get such a construct in the next
couple years.

Server-side web programming is an area where there's no single dominant
technology, and where the most prevalent technologies still have some
distance to go before reaching the "good enough" stage. I think it's
the best area for Scheme to shine. I write this as someone who came
back to Scheme because I needed a good language for server-side web
work, not as someone who went into server-side web work in order to show
off Scheme.

> As an aside, I deliberately avoided using a feature which I think may be
> Resin-specific, which is the interpolated string, similar to Scheme's
> quasiquote. One of our example lines would then be written as:
> @"<li><strong>$(row.color.charAt(0))</strong>\n<ul>". It doesn't address
> all of your objections, but it is easier to write than the fully-tagged
> equivalent.

Yes, the "there's more than one way to do it" philosophy. Doesn't the
Perl cookbook start with a half-dozen different ways to write string
literals? Scheme has one string syntax. BRL adds one more and is done
with it.

> >What you couldn't have done is use %> and <% to mark static content that
> >is part of an e-mail message, or for that matter anything other than
> >output to the web page.
>
> Unless I'm misunderstanding, that's not correct - JSP supports a contentType
> directive and can certainly be used to generate XML, or comma-delimited
> data, or any arbitrary data.

You're misunderstanding, perhaps because I wasn't clear. You can write
a single BRL page for form submission that writes "thanks for the info"
back to the browser, puts the data in the database, and sends an
e-mail. Within that BRL page, the same template syntax is used to
specify both the format of the HTML sent back to the browser, and the
format of the HTML or plain text sent in e-mail.

> >A non-programmer can
> >just hit C-s ] in emacs to find something s/he can change.
>

> I don't know any non-programmers who use emacs.

Ok, say they use their eyes to scan ahead for the ] character. I
would assert that it's easier to pick out than %> where there's a lot of
HTML.

> Just to be clear, I'm not saying that I don't think BRL is useful - on the
> contrary, it looks as though you've done an excellent job with it.

Thanks. I've been working on it and with it since 1997, so I think it's
more persistence than genius that's turned it into such a convenient
means of expressing server-side web applications.

> I don't mean to interfere with the promotion of BRL, though, and will
> try to refrain from that in future! :)

Quite the opposite; I feel as if I've been talking to a skilled
interviewer. Hopefully this is good practice for Saturday's Lightweight
Languages workshop, where I'll be on the "What's Next" panel that closes
out the workshop. I'll feel somewhat like Forrest Gump sitting next to
the likes of Paul Graham and some MIT research scientist. Nonetheless,
I plan on using my unique perspective to bring something interesting to
the table.

I look forward to meeting some comp.lang.scheme folks there!


--
(for-each (lambda (str) (display (string-append (make-string (- 40
(quotient (string-length str) 2)) #\space) str)) (newline)) '(""
"Bruce Lewis" "MIT 1990" " http://brl.sourceforge.net/
"))

Ed Dengler

unread,
Nov 15, 2001, 10:30:09 AM11/15/01
to
Greetings all!

In article <slrn9v69ij.k...@cloaked.freeserve.co.uk>,


MJ Ray <markj...@cloaked.freeserve.co.uk> wrote:
>There are libraries and CPAN's mere existance doesn't make it any easier to
>locate the right library for the job, IME. There appears to be not much of
>a barrier to entry to CPAN and no easily-accessible ratings guides.

I am not saying that CPAN should be the guide of all that is good. I
am sure a dedicated group could come up with a better method. But on
the other hand, I can sit at my unix box, run the fetch/compile and voila,
it's on my system, extending functionality, like a proper library.

Wouldn't it be nice to see a similar (or better) system available for
Scheme code?

Regards,
Ed

Paul Steckler

unread,
Nov 15, 2001, 11:02:55 AM11/15/01
to
Ed Dengler <eade...@mud.uwaterloo.ca> wrote:
: ...
: (2) Database support (and the corollary of better libraries for many tasks

: such as CPAN). Is there a reason that there is not a supported,
: all (or as much as reasonable) done in Scheme, interface to the
: common databases such as Oracle, Paradox, Microsoft, Sybase, etc?
: _Any_ real world task is most likely going to require accessing a
: database (and web programming in particular). In the time I spent
: looking, other than BRL (which cheats by going through JDBC), Guile
: (which has modules that "are no longer supported"), and PLT (which
: requires ODBC, which is not much help for Linux boxes), SIOD is the
: _only_ implementation that seems to have a direct interface to
: Oracle. (If anybody knows a good general _supported_ system for use
: with the PLT derivatives, I would be interested!)

I've successfully compiled PLT SrPersist with unixODBC on a stock Red Hat
installation. See http://www.unixodbc.org. There are DB2, Oracle,
Sybase, Informix, Postgres, and MySQL drivers for the unixODBC
driver manager.

Why do you think Linux is an issue?

-- Paul

Bruce Lewis

unread,
Nov 15, 2001, 11:55:54 AM11/15/01
to
sk...@cs.brown.edu (Shriram Krishnamurthi) writes:

> I agree to use PLT Scheme. You can do the same. Then neither you nor
> I needs to worry about what anyone else uses. (You can pick a
> different implementation if you wish; you will still find others who
> agree with you.)

I'm staying out of this "pick one implementation" club. I'll continue
to use Kawa for BRL since it works well, and you can't beat JDBC for
database access. I'll continue to use DrScheme when training others in
Scheme. If I ever get around to converting one particular shell script
to Scheme, I'll almost certainly use scsh. If Per Bothner suddenly
decides to become a Tibetan monk[1], I'll start porting BRL to
bigloo-JVM right away.

> I've said several times on this newsgroup that I don't consider Scheme
> a language. It's an idea.

Heresy! R5RS says "Language" right on the front. Forget any chance of
getting your Scheme club card reinstated now![2]


Bruce

[Practicing being controversial for Saturday. It will be hard to keep
up with Shriram's talk title, "The Swine Before Perl", which with one
blow offends Perl fans because of the juxtaposition of "Swine" and
"Perl", and irritates Erik "Scheme is a religious cult" Naggum because
it's a (warped) Biblical reference.]


[1] I have no reason to think Per will make such a decision, but I
really think the "hit by a bus" scenario has gotten trite.

[2] For newcomers, Shriram's Scheme club card was revoked a year or two
ago when he admitted that static typing was useful for certain
applications.

MJ Ray

unread,
Nov 15, 2001, 12:12:40 PM11/15/01
to
On 15 Nov 2001 11:55:54 -0500, Bruce Lewis <brl...@yahoo.com> wrote:
>[Practicing being controversial for Saturday. It will be hard to keep
>up with Shriram's talk title, "The Swine Before Perl", which with one
>blow offends Perl fans because of the juxtaposition of "Swine" and
>"Perl", and irritates Erik "Scheme is a religious cult" Naggum because
>it's a (warped) Biblical reference.]

I hope that these talks will be put online, for those of us who can't find
time or money to be there, or don't want to set foot in the USA for fear of
being arrested for legal overseas activities. ;-) [Free Dimitry!]

--
MJR

MJ Ray

unread,
Nov 15, 2001, 12:15:11 PM11/15/01
to
On 15 Nov 2001 15:24:56 GMT, Ed Dengler <eade...@mud.uwaterloo.ca> wrote:
>come on, let us be realistic. There is probably as many module systems
>as there are Scheme implementations. This means if I build a custom
>library using modules, I cannot count on this being easily ported to
>another Scheme implementation. ("So don't use modules/namespaces/..."
>Then where is the advantage to using Scheme?). Perl may have an awful
>module system, but at least it is consistent.

This is why I am saying "use slib". No-one's told me that I'm mad yet.

I think there's no practical way to present a single FFI, especially given
that what is foreign to one implementation is native to another (esp given
the JVM and native schemes), but presenting a uniform interface to them
would be a big help.

I should do as I say, I guess. Maybe then I'll see why people don't do it,
or I can then really take the high ground and get out the sniping rifle.
;-)

MJR

MJ Ray

unread,
Nov 15, 2001, 12:18:50 PM11/15/01
to
On 15 Nov 2001 15:30:09 GMT, Ed Dengler <eade...@mud.uwaterloo.ca> wrote:
>I am not saying that CPAN should be the guide of all that is good. I
>am sure a dedicated group could come up with a better method. But on
>the other hand, I can sit at my unix box, run the fetch/compile and voila,
>it's on my system, extending functionality, like a proper library.

Yes, it's on your system, damaging functionality, like something that an
application decided to arbitrarily splatter into the system tree at runtime.
Have you seen how much tweaking is needed to make CPAN play nicely and not
do that? Far too much :-/

>Wouldn't it be nice to see a similar (or better) system available for
>Scheme code?

No. :-)

Personally, I quite appreciate reading a little and having to *think* before
introducing a dependency to my code. It encourages me to select the best
possible library for the job, and I can try them out a little without
splattering them into the system tree, or bending stuff to make them not do
that.

--
MJR

Friedrich Dominicus

unread,
Nov 15, 2001, 12:53:13 PM11/15/01
to

> And this is _exactly_ what I am trying to point out. Look, I like
> Scheme, I think it beats the heck out of all the XML garbage that is
> getting promoted out there (anybody for programming using XML syntax,
> *shudder*). I _personally_ appreciate the fact that there are many
> _experimental_ implementations, that allow the testing of ideas. But
> come on, let us be realistic.
You can easily interface Scheme to Java e.g
can you do that with Perl?

YPerl may have an awful


> module system, but at least it is consistent.

Well use slib and you got what you want.

>
> >Anyway what did you gain. You got in principle a family of languages
> >which share much.
>
> And which disagree on any number of fundamental issues such as modules
> and FFIs.

This is not fundamental and it fully depends to what you interface. Please
interface Perl to Java and see how it worked.

Regards
Friedrich


Mario Latendresse

unread,
Nov 15, 2001, 11:58:13 AM11/15/01
to

Shriram Krishnamurthi wrote:

> I've said several times on this newsgroup that I don't consider
> Scheme a language. It's an idea. Or, A&S might say, it's a
> notation for expressing algorithmic concepts. Turning that idea
> into a language takes a lot of work. People will disagree on how to
> do that. Why should they agree?

I have a similar point of view. Scheme as described by R5RS is, among
other things, incomplete as a programming language: programming in the
large (module), it has no provision for interaction with an operating
system, other languages and tools, etc. Most implementers add the
necessary requirements to do so and we have this diversity of
implementations.

May be the future of Scheme (R5RS) lies in its capacity as an
intermediate form between a language and its implementation. Already,
this approach has been taken by some, like Marc Feeley in his Erlang
compiler. Yet, we are far from it as Scheme (R5RS) shuns from any
binary representation of its base types, and provides construct that
are too general (call/cc).

But are the ongoing efforts on Scheme (RnRS, srfi, implementers) have
a similar point of view? I think partly. Although this is rarely
explicitly mentioned.

--
Mario Latendresse

Anton van Straaten

unread,
Nov 15, 2001, 3:14:46 PM11/15/01
to
Bruce Lewis wrote:

Thanks.

I agree that the commercial web template engines leave much to be desired.
But they do work, and are being used to produce useful stuff. That's
exactly why they satisfy the "worse is better" criterion.

The example of row grouping is a good one - I've seen many pages which
simply compare fields to a variable to decide when a new group is starting.
I would think it's a PITA to write code like this all the time, and it's
less maintainable and readable, but the people writing that sort of code
often don't even think about it - it's just part of a routine for them.
They'll often cut & paste what they need from somewhere else, and can easily
end up with hundreds of thousands of lines of template code (including the
HTML) of which perhaps 20% is unique. Worse is better works because that's
how most people work. While it might be fairly easy to sell someone on the
idea that they need an abstracted row grouping mechanism, it's a lot less
easy to convince them that it's worth switching languages and tools for.

>Server-side web programming is an area where there's no single dominant
>technology, and where the most prevalent technologies still have some
>distance to go before reaching the "good enough" stage. I think it's
>the best area for Scheme to shine.

To truly "shine", though, Scheme will need more than simply incremental
advantages, which can often be relatively easily duplicated in other
environments. That's exactly why I mentioned PS3I and someone else
mentioned PLT's new send/suspend feature - turning the conventional
architecture of state-challenged web application servers on its head is
quite revolutionary, so much so that it will probably take five or ten years
or more before anything like it becomes widespread.

>Yes, the "there's more than one way to do it" philosophy. Doesn't the
>Perl cookbook start with a half-dozen different ways to write string
>literals? Scheme has one string syntax. BRL adds one more and is done
>with it.

Heh. I think Scheme could do with a bit more of this, actually. This is
one of those things with no mathematical or formal basis, except possibly in
psychology. For example, some Schemes support optional alternate bracketing
characters, like "[" instead of "(", intended for use in let statements and
the like. This is a pure concession to human pattern-recognition
limitations. There's not a lot of this kind of thing in Scheme precisely
because Scheme isn't used much in the real world - or vice versa. If a
Scheme-like language ever finds wide use, you can bet it'll grow a lot of
this kind of hair in the process. R12RS will be full of statements like
"there are six different ways to quote a string...", and the r13rs-authors
list will be discussing "do we really need this 'lambda' thing?"

>Here's an
>example of real-world CF confusion I've been pointing to for years:
>http://www.mbta.com/text-only/schedmaps/bus/bus.cfm?routenumber=85
>Note that the title of this page is "MBTA Bus Route #routenumber#
>Schedule". Obviously somebody didn't find CF syntax intuitive.

Nice example!

>You can write
>a single BRL page for form submission that writes "thanks for the info"
>back to the browser, puts the data in the database, and sends an
>e-mail. Within that BRL page, the same template syntax is used to
>specify both the format of the HTML sent back to the browser, and the
>format of the HTML or plain text sent in e-mail.

I get it now. Actually, I wish I had a template capability more like that
in regular Scheme, i.e. not inside a web server. It could be useful, for
example, for constructing a complex SQL expression which contains many
conditional bits.

>Ok, say they use their eyes to scan ahead for the ] character. I
>would assert that it's easier to pick out than %> where there's a lot of
>HTML.

Hmm. I would have said the opposite. <% stands out almost too much.

> Quite the opposite; I feel as if I've been talking to a skilled
> interviewer. Hopefully this is good practice for Saturday's
> Lightweight Languages workshop, where I'll be on the
> "What's Next" panel that closes out the workshop. I'll feel
> somewhat like Forrest Gump sitting next to the likes of
> Paul Graham and some MIT research scientist.

If I'd know I was supposed to be grilling you, you wouldn't have gotten off
so lightly! ;) I thought I might make it to that workshop, but it doesn't
look like I'm going to. I would have been stuck in the overflow room,
anyway. Good luck, and if all else fails, saying things like "Scheme is
like a box of chocolates..." is sufficiently enigmatic to sound like it
might be profound!

Anton

Bruce Lewis

unread,
Nov 15, 2001, 3:21:24 PM11/15/01
to
Bruce Lewis <brl...@yahoo.com> writes:

> PHP [...] It's still easy for newbies (or sleepy experienced


> programmers) to do an infinite loop while processing database rows, just
> by leaving out a line.

Oops. My confusion of PHP with ASP/VBscript and some other language I
can't remember which. I just checked a PHP tutorial and it's actually
safe from this as normally used.

Anton van Straaten

unread,
Nov 15, 2001, 3:25:08 PM11/15/01
to
I wrote:
>Bruce Lewis wrote:
>
>Thanks.
>...

I did just a tad too much cutting and pasting there... that was a leftover.


Ed Dengler

unread,
Nov 15, 2001, 3:01:33 PM11/15/01
to
In article <9t0vcn$b92$02$1...@news.t-online.com>,

Friedrich Dominicus <fr...@q-software-solutions.com> wrote:
>
>You can easily interface Scheme to Java e.g
>can you do that with Perl?
>

Actually, I will show my ignorance here and ask if there is any Scheme
implementation that interfaces to Java directly (ie, RPC or some
equivalent intermediate ORB technique can work for many language <=>
language interfacing, but it is not efficient) which is not built on
top of Java (ie, Kawa doesn't count).

Perl interfaces to C since the underlying implementation is C, same
with many of the Scheme systems that interface to C. If there was a
Perl on top of Java, I believe (big assumption, I know) that it would
have this feature also. In particular, I am not aware of any
fundamental limitations for this.

Regards,
Ed

David Feuer

unread,
Nov 15, 2001, 3:43:53 PM11/15/01
to
I don't see how it would hurt scheme if there were a set of standards
(like SRFIs, but possibly more formal) for doing all sorts of things.
Not all implementations would implement everything, but "full-fledged"
implementations would be expected to implement most of them. This would
create a common base on which more specialized libraries could be built
without sacrificing portability. The SRFIs may provide this sort of
thing, but it seems clear that there are not enough of them for many of
the people on this list.

--
/Times-Bold 40 selectfont/n{moveto}def/m{gsave true charpath clip 72
400 n 300 -4 1{dup 160 300 3 -1 roll 0 360 arc 300 div 1 1 sethsbcolor
fill}for grestore 0 -60 rmoveto}def 72 500 n(This message has been)m
(brought to you by the)m(letter alpha and the number pi.)m(David Feuer)
m(David...@brown.edu)m showpage

David Feuer

unread,
Nov 15, 2001, 3:50:36 PM11/15/01
to
Ed Dengler wrote:
<snip>
> And one of the big ones [issues people not using Scheme see]
> _is_ the fact that there is not a
> single implementation that can be considered the _standard_, and which
> will likely be supported by a community for a long time.
<snip>

I disagree thoroughly with this. The problem is not that there is no
single "standard" _implementation_, but that there is no standard set of
library _capabilities_. Unix has managed to remain popular for a long
time despite having many different implementations. But without the
POSIX (and later) standards, it may well have died.

Jeffrey Palmer

unread,
Nov 15, 2001, 5:21:42 PM11/15/01
to
David Feuer wrote:

> I don't see how it would hurt scheme if there were a set of standards
> (like SRFIs, but possibly more formal) for doing all sorts of things.
> Not all implementations would implement everything, but "full-fledged"
> implementations would be expected to implement most of them. This would
> create a common base on which more specialized libraries could be built
> without sacrificing portability. The SRFIs may provide this sort of
> thing, but it seems clear that there are not enough of them for many of
> the people on this list.
>

I agree. A very similar conversation occurred recently in the Haskell
community, where it was decided that Haskell adoption was suffering
because of a confusing abundance of utility/library implementations (gui
libraries, etc.). To their credit, they are now making a concerted
effort to standardize the library hierarchy so that it can be relied
upon to work consistently across the various Haskell implementations.

However, I suppose they started from a position that acknowledged the
importance of libraries to the language. Someone interested in learning
Haskell not only has to read the language report, but the *library*
report as well. Of course, with such an approach already in place, it
seemed natural to examine the state of other software engineering
systems and determine the approach that best fit within the Haskell
approach.

I believe that Scheme, especially from a software engineering
perspective, could benefit from a similar approach. Several people have
mentioned the SLIB, which is a great collection of portable Scheme
libraries. Should we take the current SLIB and document it as the
"Scheme 2001 Library Report", and move on from there? Apparently real
people are interested in using Scheme for software engineering, and in
this environment libraries are almost more important than the language
itself.

Or perhaps not. Perhaps, as was suggested in an earlier post, if you
want standardized libraries, developer productivity and the like you
should simply use Common Lisp, and leave Scheme to the people who are so
proud of the size of their 50 page spec.

- j

--
Jeffrey Palmer
Curious Networks, Inc.
http://www.curiousnetworks.com

Brian Campbell

unread,
Nov 15, 2001, 5:24:13 PM11/15/01
to
eade...@mud.uwaterloo.ca (Ed Dengler) wrote in message news:<9t0mo8$soj$1...@watserv3.uwaterloo.ca>...

Well, wouldn't this be an ideal case for SRFI's? A module system SRFI
would probably not be that hard to do, as most of the module systems
I've seen support most of the same feautres. FFI would probably be
considerably harder, as all schemes map to C in different ways. It,
too, might be possible however, with some suibtable high level
abstractions. Would anyone be interested in working on these with me?
I would of course start on the module system first, and if that were
successful, maybe move on to a C-FFI.

With these, we could then begin work on a scheme version of CPAN, with
maybe a little bit more quality control. Does anyone else think that
this is feasible, or am I just dreaming?

-- Brian Campbell
to email me, send to lambda (at) world (dot) std (dot) com

David Feuer

unread,
Nov 15, 2001, 7:09:58 PM11/15/01
to
Brian Campbell wrote:

>
> Well, wouldn't this be an ideal case for SRFI's? A module system SRFI
> would probably not be that hard to do, as most of the module systems
> I've seen support most of the same feautres. FFI would probably be

Different module systems have very different features. Read 3 language specs. Get 3 definitions of a
module.

> considerably harder, as all schemes map to C in different ways. It,
> too, might be possible however, with some suibtable high level
> abstractions. Would anyone be interested in working on these with me?
> I would of course start on the module system first, and if that were
> successful, maybe move on to a C-FFI.

Foreign function interfaces are really messy. The interface will depend on the language whose
functions are being called, and also on the details of how function calls work on each architecture.
For FFI with C, one significant issue is garbage collection. For other languages (C++, Java, Haskell,
...) things could get much more complicated. It seems that this should be one of the last things on
the list to try to standardize. OS interaction, database access, and even GUI access would seem to be
more reasonable starting points.

David Feuer

Jeffrey Siegal

unread,
Nov 15, 2001, 7:34:56 PM11/15/01
to
David Feuer wrote:
> Foreign function interfaces are really messy. The interface will depend on the language whose
> functions are being called, and also on the details of how function calls work on each architecture.
> For FFI with C, one significant issue is garbage collection. For other languages (C++, Java, Haskell,
> ...) things could get much more complicated. It seems that this should be one of the last things on
> the list to try to standardize. OS interaction, database access, and even GUI access would seem to be
> more reasonable starting points.

The thing is, a C FFI gets you most or all of that for free if you're using a
system that already has those things.

Yeah, GC is messy. The C FFI's that are easiest to use are on systems that
use the Boehm collector, so cross-language GC works (mostly) ok.

MJ Ray

unread,
Nov 15, 2001, 7:04:47 PM11/15/01
to
On Thu, 15 Nov 2001 22:21:42 GMT, Jeffrey Palmer <jeffrey...@acm.org> wrote:
>[...] Several people have mentioned the SLIB, which is a great collection
>of portable Scheme libraries.

It's probably just me mentioning it several times. Is it really that great?
I'm waiting for a good answer. :-/

>Should we take the current SLIB and document it as the "Scheme 2001 Library
>Report", and move on from there? Apparently real people are interested in
>using Scheme for software engineering, and in this environment libraries
>are almost more important than the language itself.

Would it be better to do that, or to make SLIB the basis of a SRFI? Has
such a thing been attempted before? Then future extensions could be
written to work on many schemes, with only the ffi part needing porting to
different implementations.

I suspect some of the language researchers here will be against using a
non-module-based system for an extension mechanism, though. It's a shame,
as slib-style looks as though it would suffice for the real world.

>Or perhaps not. Perhaps, as was suggested in an earlier post, if you
>want standardized libraries, developer productivity and the like you
>should simply use Common Lisp, and leave Scheme to the people who are so
>proud of the size of their 50 page spec.

Inverse of the normal size psychology?

--
MJR

Ed Dengler

unread,
Nov 15, 2001, 8:24:59 PM11/15/01
to
Greetings!

In article <3BF42A9C...@brown.edu>,


David Feuer <David...@brown.edu> wrote:
>I disagree thoroughly with this. The problem is not that there is no
>single "standard" _implementation_, but that there is no standard set of
>library _capabilities_. Unix has managed to remain popular for a long
>time despite having many different implementations. But without the
>POSIX (and later) standards, it may well have died.

Actually, I'll agree with this. It should be remembered that to the
real world, a system for development is the entire package of base
language, libraries, and bits of code they can borrow to modify. It
isn't just the language, it is all the stuff that comes with it.

Regards,
Ed

Shriram Krishnamurthi

unread,
Nov 15, 2001, 11:52:50 PM11/15/01
to
eade...@mud.uwaterloo.ca (Ed Dengler) writes:

> It isn't so much that there exists multiple implementations (from the
> viewpoint that this allows experimentation, there is an argument that
> many implementations are good). It is mostly that the effort of people
> who like to put together libraries of stuff in Scheme are spread across
> many (incompatible) versions. [...]

I don't want to insult you by repeating my previous message, though I
am tempted to. I don't see how this refutes my previous argument. I
doubt you'd have much luck going on a Tcl newsgroup and telling them
how much you wish they would unify with Python.

> This means great leverage. There is a community that can talk
> specifics rather than just generalities (eg, how do I get this to call
> a C function in Perl?).

Have you been on the PLT Scheme mailing list?

> It requires
> quite a bit of effort _on the part of an outsider_ to get to a
> productive point.

I routinely hear from former Guile users who write to tell me that
they've switched or are switching to PLT Scheme, and like what they
see. So apparently it's not *that* imppossible for outsiders to get
in, and they find the rewards of getting in high even when they
already have an (incompatible) code base.

> I cannot easily say to somebody, "You want to try
> this out? Go to here, this is all the info you need, and here is _the_
> standard that everybody is using in production." I can choose a couple
> of implementations for people to play with, but they are _not_ complete,
> and they do not look like they will be soon.

Pick the one that looks most likely to become complete. Send users
there. Believe me -- a sudden influx of *contributing* new users will
make a huge difference to any Scheme you pick.

> >I've said several times on this newsgroup that I don't consider Scheme
> >a language. It's an idea. Or, A&S might say, it's a notation for
> >expressing algorithmic concepts. Turning that idea into a language
> >takes a lot of work. People will disagree on how to do that. Why
> >should they agree?
>

> As I said, as an idea, multiple implementations are great for
> experimentation.

I think you're missing my point (which goes back to my first comment
in this post): I do NOT think of these as N different implementations
of the same language. I think of these as N different languages.
Period. I truly, literally mean that.

Nobody mistakes an ML for being a Scheme system, even though you can
probably put parens in some places like you can in Scheme, and you
don't have to write down types explicitly. In the same way, there are
deep, philosophical differences between the Scheme systems also: just
consider SIOD vs Guile vs PLT Scheme. Look at their module systems
and object systems (or lack thereof). Who would reasonably argue that
these are the same language?

> But I do not expect it to break into the mainstream because
> _it is too difficult to get started_.

This is a distressing conclusion for those of us trying to combat
these problems. PLT complements its academic textbook with a
"cookbook"-style guide; Dorai Sitaram even publishes "Scheme in Fixnum
Days". In addition, beyond a textual REPL, we put out a
beginner-friendly programming environment. I could give you many
arguments for why it's beginner friendly, but the best one is also the
most concise: see how much it frustrates the experienced Schemers on
this newsgroup. (-:

Shriram

Ray Dillinger

unread,
Nov 16, 2001, 1:37:30 AM11/16/01
to
MJ Ray wrote:
>
> On Thu, 15 Nov 2001 22:21:42 GMT, Jeffrey Palmer <jeffrey...@acm.org> wrote:
> >[...] Several people have mentioned the SLIB, which is a great collection
> >of portable Scheme libraries.
>
> It's probably just me mentioning it several times. Is it really that great?
> I'm waiting for a good answer. :-/

SLIB is actually pretty darn good. Because it's actually
written in scheme, it's portable across many implementations.

However, since most implementations don't compile all the way to
machine code and optimize the machine code like crazy, the
implementor can usually provide a builtin function that's faster
than the equivalent SLIB function. And this has hindered the
adoption of SLIB, somewhat.

Fundamentally, the problem here is not with SLIB, it's with the
implementations. SLIB, and all other scheme code, ought in an
ideal world to compile into machine code that runs just as fast
as any builtin function. If a compiler were really that tight,
there'd be no drawback to using SLIB at all.

Aside from the efficiency issue, SLIB is a great high-level
library. However, there are certain low-level operations that
scheme simply provides no support for. These include installing
interrupt handlers, issuing interrupts, handling hardware ports,
getting command line arguments, memory operations, hardware
interrogation via memory-mapped IO, arranging things into static
record structures and passing raw pointers to them to operating
system functions, getting and issuing system messages, accessing
system variables, etc. You can't write a library that does any
of this stuff in portable scheme, by definition.

For any particular scheme implementation, there is usually
some way to access some subset of this low-level binary crap
-- but we've never abstracted that access into "standard"
library forms that we expect to be available across multiple
implementations, the way it's done in C. Mind you, there's
a lot of that stuff that can't be done in C either. Hell,
C by itself can't even print "hello world!" It can count to
50, but without a library to handle IO, it can't tell you that
it's finished counting. But the C standard demands that an
implementor provide an stdio.h that allows linking to standard
input/output functions. Some bits of the functions have to
be written in machine code, or are OS or machine-specific,
but whatever.

But SLIB doesn't address that, really. It implements in scheme
only those things that can be implemented in scheme. It provides
a lot of convenience, but fundamentally, it doesn't provide
anything you couldn't have written yourself.

In order to be successful for creating commercially useful
artifacts, a language *MUST* have some standard way of doing
this kind of low-level bitfiddling, and here is where all
our standards are completely silent and everybody is inventing
their own. SLIB covers high-level libraries; but we suffer badly
from the absence of any standard, even general guidelines, about
the shape of library functions that do low-level stuff.


Bear

Ray Dillinger

unread,
Nov 16, 2001, 1:46:35 AM11/16/01
to
Jeffrey Siegal wrote:

> Yeah, GC is messy. The C FFI's that are easiest to use are on systems that
> use the Boehm collector, so cross-language GC works (mostly) ok.

Uh, not for the last six or eight months they don't. The Boehm
collector goes through your C stacks and records looking for
things that might be pointers, so it knows what to *not* collect.
The problem is that with 4-gigabyte and larger memory spaces,
which are increasingly common in the last year, there are no
integers that don't look like pointers, so Boehm's "conservative"
collecting behavior tends toward "no" collecting behavior....

Bear

Jeffrey Siegal

unread,
Nov 16, 2001, 2:02:20 AM11/16/01
to

I'm not sure what you're getting at here. It is virtual addresses that
matter, not the physical address. And the virtual address space hasn't
changed significantly in the last six or eight months.

Besides, small integers still don't look like pointers, and medium-sized
integers always had the risk of looking like pointers, but in practice
this wasn't that big a deal for most programs. If programs grow to where
they use most or all of a 4 GB virtual address space, then negative
integers will start to be a problem, but I still don't see this as being
that serious a problem where you are going to get "no" collecting
behavior. You'd have to have a lot of different integers sitting around
to do that, and even then you can work around the problem by telling the
collector that certain memory regions (large matrices, etc.) don't
contain pointers.

Can you post a pointer to some discussion of what you're referring to?

Friedrich Dominicus

unread,
Nov 16, 2001, 2:15:23 AM11/16/01
to
eade...@mud.uwaterloo.ca (Ed Dengler) writes:

> In article <9t0vcn$b92$02$1...@news.t-online.com>,
> Friedrich Dominicus <fr...@q-software-solutions.com> wrote:
> >
> >You can easily interface Scheme to Java e.g
> >can you do that with Perl?
> >
>
> Actually, I will show my ignorance here and ask if there is any Scheme
> implementation that interfaces to Java directly (ie, RPC or some
> equivalent intermediate ORB technique can work for many language <=>
> language interfacing, but it is not efficient) which is not built on
> top of Java (ie, Kawa doesn't count).

Well this is a pretty much demanded. If I can use all the facilities
of Java directly than the interfacin is as direct as can be. And Silk
is a Scheme directly written in Java. So can you expect more directness?

Regards
Friedrich

Stephan H.M.J. Houben

unread,
Nov 16, 2001, 3:38:49 AM11/16/01
to
In article <3BF4B6E9...@sonic.net>, Ray Dillinger wrote:
>Mind you, there's
>a lot of that stuff that can't be done in C either. Hell,
>C by itself can't even print "hello world!" It can count to
>50, but without a library to handle IO, it can't tell you that
>it's finished counting. But the C standard demands that an
>implementor provide an stdio.h that allows linking to standard
>input/output functions.

Actually, the C standard I/O functions are an extremely weak
library. In fact, the R5RS I/O procedures, weak as they may be,
provide some functionality that isn't even in the C standard,
namely char-ready?. The only thing in the C I/O library not in Scheme
is the ability to access files in non-sequential ordering, but as it
turns out, this facility is also extremely underspecified.

E.g. in ANSI C, you cannot rely on ftell() giving you any meaningful
information, the only thing that is guaranteed is that fseek() will
restore the file position when given the result of ftell().

Of course, hordes of programmers have written supposedly portable
programs in which ftell() is believed to return the file position
in bytes.

And C++ doesn't improve the situation. Similarly for Fortran, Pascal, etc.

So my point is that supposedly "succesful" languages actually are no
stronger in I/O than pure R5RS Scheme. The only programming language
I know of that actually goes substantially further than Scheme in
this respect is Java, but that was only because a single vendor could
set the standards there. (Not unlike PLT deciding tomorrow to
rename PLT Scheme into Fred, submit Fred for ECMA standardisation and
requiring the whole PLT Scheme libraries as "standard libraries").

Now I'm not saying that standardised libraries are not important.
I think they are important. On the other hand, there are many people
who want to use Scheme as a simple extension language, and do not
want a big standard. The standard, as it is, is weak, but not weak
compared the standards of some "Real-World" programming languages.
I.e. I sincerely believe that the set of useful programs that can
be written in 100% R5RS Scheme is at least as big, if not bigger,
than the set of useful programs that can be written in 100% pure
ANSI C or ANSI C++.

Stephan

Jeffrey Siegal

unread,
Nov 16, 2001, 4:43:22 AM11/16/01
to
"Stephan H.M.J. Houben" wrote:
> E.g. in ANSI C, you cannot rely on ftell() giving you any meaningful
> information, the only thing that is guaranteed is that fseek() will
> restore the file position when given the result of ftell().

Yes, but ANSI C is not the only relevant specification. The POSIX
specification is much stronger and more useful. And then there are
other useful similarly useful specifications such as SVID and SUS.

That's why I would really like to see a standard C FFI, at least for
calling out to C functions. Most useful portability standards have
already C bindings, but not Scheme bindings. C++, Fortran, Pascal, etc.
all have more-or-less standard mechanisms for accessing the existing C
APIs on various to write portable code to these standards.

Ji-Yong D. Chung

unread,
Nov 16, 2001, 7:30:15 AM11/16/01
to
Hi

If I understand conservative collection correctly,
I don't think there is any problem with integers.

If an integer can be a gc-heap pointer (meaning that its value is
within an gc-heap address range) and it is reachable, it will be considered
alive,
and it will be left alone (Mark-and-sweep collector touches only "garbage").
If the integer is not within the range, it is not even considered for
garbage collection, so again, it is not touched.

In either case, the size of memory does not make any difference.

In terms of efficiency, of course, there _could_ be a problem
with a large memory space, if (1) mark-and-sweep collector
were implemented naively _and_ (2) it were actually managing
large memory. A naive mark-and-sweep, in its sweep phase,
would scan through _all_ of gc-heap in order to collect unmarked
memory fragments. This could take a long time, if gc-heap is large.

I don't think Boehm collector does that. Does
anyone know how Boehm collector minimizes it sweep phase?


MJ Ray

unread,
Nov 16, 2001, 6:59:58 AM11/16/01
to
On Fri, 16 Nov 2001 06:37:30 GMT, Ray Dillinger <be...@sonic.net> wrote:
>SLIB, and all other scheme code, ought in an ideal world to compile into
>machine code that runs just as fast as any builtin function. If a compiler
>were really that tight, there'd be no drawback to using SLIB at all. [...]

There's one demand. We need something at least as good as python's
byte-compiler for scheme. A couple of schemes have compilers, but which
ones can mix compiled and non-pre-compiled code?

>Aside from the efficiency issue, SLIB is a great high-level library.
>However, there are certain low-level operations that scheme simply provides

>no support for. [...]

How does scsh do at this "low-level binary crap"? I don't recall using scsh
recently, but I think there are at least three implementations of this
interface for different schemes, so maybe it's a candidate? However, I'm
not aware of a standard way to load in scsh functionality at present. :-/

Very irritatingly, I can't even get scsh to load into guile1.4 here.

Are we making progress here? Are any implementors willing to endorse such
moves, or are we just whistling in the wind?

--
MJR

MJ Ray

unread,
Nov 16, 2001, 7:12:01 AM11/16/01
to
Shriram,

I think that while you are doing some great things with PLT Scheme, you are
also doing Scheme itself a great disservice and hindering wider adoption
with your denial that PLT Scheme is not Scheme (or is it a claim that PLT
Scheme is the One True Scheme?).

On 15 Nov 2001, Shriram Krishnamurthi <sk...@cs.brown.edu> wrote:
>I routinely hear from former Guile users who write to tell me that
>they've switched or are switching to PLT Scheme, and like what they
>see.

Do you hear from PLT users switching back to guile because various things in
PLT needed for real work are broken or in seemingly perpetual beta? Good
working database interfaces are a huge omission from the current system (and
HTUS). Writing my own ODBC interface is not something I have time to do
right now.

>Pick the one that looks most likely to become complete. Send users
>there. Believe me -- a sudden influx of *contributing* new users will
>make a huge difference to any Scheme you pick.

No, let's build on standards and have many good schemes for different jobs.
I know that the "market leader" tag for Free Unix Schemes has to be between
bigloo, PLT and guile at the moment, but I'd like to see standardisation of
existing schemes rather than further balkanisation.

I'd love never to have to learn another single-implementation scheme
extension. I shouldn't need to: I'm writing application code, not low-level
extensions, but some of the egos involved make me wonder whether this is
ever going to be possible.

And that's a very depressing thought.

--
MJR

Jeffrey Siegal

unread,
Nov 16, 2001, 7:35:21 AM11/16/01
to
"Ji-Yong D. Chung" wrote:
> If an integer can be a gc-heap pointer (meaning that its value is
> within an gc-heap address range) and it is reachable, it will be considered
> alive,
> and it will be left alone (Mark-and-sweep collector touches only "garbage").
> If the integer is not within the range, it is not even considered for
> garbage collection, so again, it is not touched.

The issue, I think, is that if you have enough integers in memory, with
a wide range of values, they'll tend to accidentally point to lot of
blocks of memory, which then won't be collected (along with anything
pointed to, directly or indirectly, by those blocks). In the extreme,
this could potentially result in most memory in use not being collected.



> In either case, the size of memory does not make any difference.

I didn't follow that part either.

Jon K Hellan

unread,
Nov 16, 2001, 8:39:13 AM11/16/01
to
markj...@cloaked.freeserve.co.uk (MJ Ray) writes:

> Do you hear from PLT users switching back to guile because various things in
> PLT needed for real work are broken or in seemingly perpetual beta? Good
> working database interfaces are a huge omission from the current system (and
> HTUS). Writing my own ODBC interface is not something I have time to do
> right now.

PLT does have an ODBC interface. It's called srpersist. Guile doesn't.

Jon KÃ¥re

--
Jon KÃ¥re Hellan Trondheim
Clustra AS Norway

Ji-Yong D. Chung

unread,
Nov 16, 2001, 9:02:36 AM11/16/01
to
Hi
"Jeffrey Siegal" <j...@quiotix.com> wrote in message
news:3BF50809...@quiotix.com...

> "Ji-Yong D. Chung" wrote:
> > If an integer can be a gc-heap pointer (meaning that its value is
> > within an gc-heap address range) and it is reachable, it will be
considered
> > alive,
> > and it will be left alone (Mark-and-sweep collector touches only
"garbage").
> > If the integer is not within the range, it is not even considered for
> > garbage collection, so again, it is not touched.
>
> The issue, I think, is that if you have enough integers in memory, with
> a wide range of values, they'll tend to accidentally point to lot of
> blocks of memory, which then won't be collected (along with anything
> pointed to, directly or indirectly, by those blocks). In the extreme,
> this could potentially result in most memory in use not being collected.

Thanks for the clarification. That makes sense.


Stephan H.M.J. Houben

unread,
Nov 16, 2001, 9:44:56 AM11/16/01
to
In article <3BF50809...@quiotix.com>, Jeffrey Siegal wrote:
>"Ji-Yong D. Chung" wrote:
>> If an integer can be a gc-heap pointer (meaning that its value is
>> within an gc-heap address range) and it is reachable, it will be considered
>> alive,
>> and it will be left alone (Mark-and-sweep collector touches only "garbage").
>> If the integer is not within the range, it is not even considered for
>> garbage collection, so again, it is not touched.
>
>The issue, I think, is that if you have enough integers in memory, with
>a wide range of values, they'll tend to accidentally point to lot of
>blocks of memory, which then won't be collected (along with anything
>pointed to, directly or indirectly, by those blocks). In the extreme,
>this could potentially result in most memory in use not being collected.

Have you any empirical evidence of this happening? Scheme's that
use Boehm GC typically still need to tag fixnums for typing reasons.
So fixnums typically don't look like pointers at all.

IIRC, there are sometimes real problems with conservative GC, but
they stem from stray pointers being left on the stack, and then
possibly copied into the heap by call/cc.

Stephan

Shriram Krishnamurthi

unread,
Nov 16, 2001, 9:40:03 AM11/16/01
to
markj...@cloaked.freeserve.co.uk (MJ Ray) writes:

> I think that while you are doing some great things with PLT Scheme, you are
> also doing Scheme itself a great disservice and hindering wider adoption
> with your denial that PLT Scheme is not Scheme (or is it a claim that PLT
> Scheme is the One True Scheme?).

The ML language makes a very nice distinction between the core
language and the module language. They are really two different
languages, with different type structures, different constructs,
different expressive powers. This lets you layer many module and
object systems on top of the base language, as well as many
user-friendly libraries.

Scheme can make the exact same distinction. There's a core language,
defined by (say) R5RS. Anything written in terms of it is universally
usable. As Mario Latendresse points out, however, it's difficult to
structure large systems in that language. You may need modules; you
may need classes and objects. R5RS is silent about all of these.
You've chosen Guile to provide these services; I've chosen PLT Scheme.

In short, I am making neither claim that you proffer.

> Do you hear from PLT users switching back to guile because various things in
> PLT needed for real work are broken or in seemingly perpetual beta? Good
> working database interfaces are a huge omission from the current system (and
> HTUS). Writing my own ODBC interface is not something I have time to do
> right now.

You shouldn't have to write your own ODBC interface given that
SrPersist exists and has been tested out on numerous platforms
(including Linux, using OpenODBC). The absence of a tutorial on it is
dissatisfying, but does not in any way suggest that the library
doesn't exist. Indeed, for new users, the page

http://www.plt-scheme.org/software/

says, amongst other things,

SrPersist connects to ODBC drivers for database access.

and it's been around for some time now (I remember using it back when
I was still at Rice, so that would have been ~2 years ago).

So, could you tell us what features Guile's ODBC interface has that
PLT Scheme's doesn't have? A brief enumeration would help.

> I'd love never to have to learn another single-implementation scheme
> extension. I shouldn't need to: I'm writing application code, not low-level
> extensions, but some of the egos involved make me wonder whether this is
> ever going to be possible.

You're a smart guy; surely you see that most Schemes differ in no
small part because of fundamental philosophical differences? Last I
heard, Bigloo didn't support full tail calls; you don't think it's
because Manuel Serrano (an incredibly smart implementor!) doesn't know
about them or because his "ego" got in the way? Have you ever studied
PLT Scheme's combination of units and mixins and, if you have, can you
tell us how we would accomplish the same effect in Guile? And on the
other hand, can you explain how your present favored implementation,
Guile, is *anything but* an exercise in ego by Stallman and Lord?

Thanks,
Shriram

MJ Ray

unread,
Nov 16, 2001, 9:51:26 AM11/16/01
to
On 16 Nov 2001 14:39:13 +0100, Jon K Hellan <Jon.H...@clustra.com> wrote:
>PLT does have an ODBC interface. It's called srpersist. Guile doesn't.

Sorry, I meant writing my own interface to talk to ODBC is more difficult
than writing an interface to a simple database connection that speaks SQL.

It seems srpersist has come on a little since I last looked, though. The
tutorial is still a little brief, though.
--
MJR

MJ Ray

unread,
Nov 16, 2001, 10:19:11 AM11/16/01
to
On 16 Nov 2001 09:40:03 -0500, Shriram Krishnamurthi <sk...@cs.brown.edu> wrote:
>You've chosen Guile to provide these services; I've chosen PLT Scheme.
>In short, I am making neither claim that you proffer.

I am not making that choice, other than on a per-task basis. I long for the
day where we have portability of code between the different implementations.

>You shouldn't have to write your own ODBC interface given that
>SrPersist exists and has been tested out on numerous platforms

Yes, it seems that it has moved on a little and maybe I can create a similar
interface to it to that which I have created on top of guile's database
connectors.

Really what killed it for me for that project was the sheer length of time
that it took to open a unixODBC connection to localhost, as against guile's
postgresql connections. The only real viable option I could see was to use
the PLT webserver to keep the connections open, but how to do it was just
too damn frustrating for someone without a degree in pure computer science.

>You're a smart guy; surely you see that most Schemes differ in no

>small part because of fundamental philosophical differences? [...]

Should these differences be so rudely visible to the application author,
though? I'm not asking for you to go and reimplement your systems in a
different way, just to present a uniform interface for us poor programmers
where it is possible and appropriate. *That*, and the calls of "use my
scheme", are where I think the egos get in the way.

>can you explain how your present favored implementation,
>Guile, is *anything but* an exercise in ego by Stallman and Lord?

As I said above, Guile is just the tool I am using for some current
applications. I have PLT scheme at work in other applications where it is
better suited to the task (and doesn't use databases).

Anyway, as I'm sure you know, Guile is still the most widely used tool for a
particular type of task, embedding scheme interpreters into common C
applications. It's not going anywhere soon. Its GUI libraries also seem
not too bad... does PLT scheme have an interface to fltk?

Finally, how does one obtain a multipart/digest format digest of the PLT
scheme mailing list? I guess I should rejoin it, but the web site is not
clear on how to do this.

--
MJR

Jeffrey Siegal

unread,
Nov 16, 2001, 1:58:09 PM11/16/01
to
"Stephan H.M.J. Houben" wrote:
> Have you any empirical evidence of this happening?

I wasn't the one claiming that the problem had gone all out of control
in the past several months. I'm still waiting for that evidence.

> Scheme's that
> use Boehm GC typically still need to tag fixnums for typing reasons.
> So fixnums typically don't look like pointers at all.

The discussion was about using a C FFI with Boehm GC, so you also need
to consider C integers, not just Scheme fixnums.

Ray Dillinger

unread,
Nov 16, 2001, 5:09:28 PM11/16/01
to

"Stephan H.M.J. Houben" wrote:
>
> In article <3BF4B6E9...@sonic.net>, Ray Dillinger wrote:
> >Mind you, there's
> >a lot of that stuff that can't be done in C either. Hell,
> >C by itself can't even print "hello world!" It can count to
> >50, but without a library to handle IO, it can't tell you that
> >it's finished counting. But the C standard demands that an
> >implementor provide an stdio.h that allows linking to standard
> >input/output functions.
>
> Actually, the C standard I/O functions are an extremely weak
> library. In fact, the R5RS I/O procedures, weak as they may be,
> provide some functionality that isn't even in the C standard,
> namely char-ready?. The only thing in the C I/O library not in Scheme
> is the ability to access files in non-sequential ordering, but as it
> turns out, this facility is also extremely underspecified.

I probably picked a bad example. I agree that the library I/O
functions in C are weak, but for stuff like I was actually concerned
about, scheme's standard libraries are infinitely weaker than C's.

To reiterate (in fact quoting my earlier message):

>>However, there are certain low-level operations that
>>scheme simply provides no support for. These include installing
>>interrupt handlers, issuing interrupts, handling hardware ports,
>>getting command line arguments, memory operations, hardware
>>interrogation via memory-mapped IO, arranging things into static
>>record structures and passing raw pointers to them to operating
>>system functions, getting and issuing system messages, accessing
>>system variables, etc. You can't write a library that does any
>>of this stuff in portable scheme, by definition.

> So my point is that supposedly "succesful" languages actually are no
> stronger in I/O than pure R5RS Scheme.

Perhaps, but with a litany like the above of ways to interface
with the operating system, who really cares if scheme's I/O is
stronger? Without a whole lot of stuff besides console I/O,
scheme winds up being a "sandbox" language, unable to affect
anything outside its tiny context in the runtime environment of
the host machine.

> On the other hand, there are many people
> who want to use Scheme as a simple extension language, and do not
> want a big standard. The standard, as it is, is weak, but not weak
> compared the standards of some "Real-World" programming languages.
> I.e. I sincerely believe that the set of useful programs that can
> be written in 100% R5RS Scheme is at least as big, if not bigger,
> than the set of useful programs that can be written in 100% pure
> ANSI C or ANSI C++.

I don't think so. If someone is willing to throw enough C code
at a problem, and enough debugging effort, there is *NO* program
purely about manipulation of information that cannot be written
in C. This is provable, because it's a Turing-complete language.
(the poor sod may have to implement scheme or equivalent on the
way if the problem is of a particularly twisted type, but whatever...)
So I assert that there is no program that cannot be written in C
that can be written in scheme.

What that leaves, though, is the range of programs that do things
that scheme gives us no way to do, a few of which I list above.
Because C has standard libraries that interface with the operating
system there are standard ways to do these things in C. Because
scheme doesn't, there is no standard way to do these things in
scheme. Hence, the useful programs that can be written in
portable C exceed the useful programs that can be written in
portable scheme.

Bear

Jeffrey Siegal

unread,
Nov 16, 2001, 5:20:08 PM11/16/01
to
Ray Dillinger wrote:
> Because C has standard libraries that interface with the operating
> system there are standard ways to do these things in C.

His point was that the "standard libraries" for C don't interface with
the operating system very much. Most C real-world C libraries do, but
that's because they exceed "standard C" by a wide margin.

Bill Richter

unread,
Nov 17, 2001, 10:04:33 PM11/17/01
to
can you explain how your present favored implementation, Guile, is
*anything but* an exercise in ego by Stallman and Lord?

Shriram, I thought this was a gratuitous insult, at the end of a long
thoughtful post. I'm certainly willing to believe that Guile is
"worse" than PLT Scheme, that Guile has made a series of "bad" design
choices. It doesn't follow that Stallman and Lord are egoizing (as
they say in The Dispossessed).

I figure Stallman and Lord are pursuing a Gabriel "worse is better"
strategy: we can write tons of "bad" code, backwardly compatible with
tons of other "bad" code. Kind of like Microsoft maybe ("We ship
buggy code fast!") The success of Emacs & Gcc & the GNU project shows
that it's been a successful strategy.

So far, I haven't heard that Guile is wildly successful, but it's
definitely a "worse is better" strategy: instead of writing 10,000
line Tcl/Python/Perl programs, write 'em in Guile. Guile isn't nearly
as nice (I'm sure) as PLT Scheme, but it's at least good as Emacs
Lisp, which is the standard of success.

Doesn't everyone here use Emacs as an editor? It's not good Scheme,
it's not even good Lisp, but it's good enough for a text editor, and
it's got full kitchen sink capability.

PLT Scheme has higher aims: you're not content with better-than-Python
code, you want to write truly good code, which means good design
decisions from the beginning, but that limiting, it's not a "worse is
better" strategy. I imagine the Guile idea is no matter how bad the
existing code is, we can extend it with Guile. I imagine the PLT
Scheme would be to junk the existing code if it's bad enough. I'm
sure there's room for both.

--
Bill
<http://www.math.nwu.edu/~richter>

Jeffrey Siegal

unread,
Nov 17, 2001, 10:24:10 PM11/17/01
to
Bill Richter wrote:
> can you explain how your present favored implementation, Guile, is
> *anything but* an exercise in ego by Stallman and Lord?
>
> Shriram, I thought this was a gratuitous insult, at the end of a long
> thoughtful post. I'm certainly willing to believe that Guile is
> "worse" than PLT Scheme, that Guile has made a series of "bad" design
> choices. It doesn't follow that Stallman and Lord are egoizing (as
> they say in The Dispossessed).

It also doesn't follow that they're not, and he's entitled to claim they
are, if he wants. Certainly there is some evidence to support it.



> I figure Stallman and Lord are pursuing a Gabriel "worse is better"
> strategy: we can write tons of "bad" code, backwardly compatible with
> tons of other "bad" code. Kind of like Microsoft maybe ("We ship
> buggy code fast!") The success of Emacs & Gcc & the GNU project shows
> that it's been a successful strategy.

Emacs and Gcc have never followed a "worse is better" strategy. If
Guile is, that would represent a significant strategy shift, not a
continuation of past practices.

Maybe it is just "worse."

> Doesn't everyone here use Emacs as an editor?

I'd seriously doubt that, though I do.

Shriram Krishnamurthi

unread,
Nov 18, 2001, 12:20:24 AM11/18/01
to
Bill Richter <ric...@poincare.math.northwestern.edu> writes:

> Shriram, I thought this was a gratuitous insult, at the end of a long
> thoughtful post.

I think it was neither gratuitous nor necessarily an insult. It
wasn't gratuitous because I was merely responding to MJ Ray's comment
about egos. Whether or not it was insulting is a matter of opinion:
to me, it was a statement of fact. If you consider Stallman's
attitude toward the Scheme community as anything less than insulting,
perhaps you need to consider recaliberation.

> I figure Stallman and Lord are pursuing a Gabriel "worse is better"
> strategy: we can write tons of "bad" code, backwardly compatible with
> tons of other "bad" code.

In my opinion, based on many years of trying to get at the heart of
the sofware process, this sounds like a pretty dumb strategy.

I am also unsure of exactly where this legacy code (the "tons of other
`bad' code") is coming from. Presumably you mean the Elisp codebase.
That was certainly the original promise of Guile, but has it borne
out? Is anyone actually doing large-scale integration of Elisp code
with Guile/Scheme? Can you point me to a few such applications?

> Kind of like Microsoft maybe ("We ship
> buggy code fast!")

I certainly agree that this appears to be Guile's strategy. I've seen
several Guile library snippets that make my digestive system want to
surrender my lunch. Like I've said before, I'd sooner program in Perl
than I would in Guile. There's simply no win there. Guile appears to
me to be a weak Perl with a sub-optimal syntax.

If Worse is indeed Better, than Perl is Best. Give it up.

> The success of Emacs & Gcc & the GNU project shows
> that it's been a successful strategy.

Worse is Better has never, in my estimation, been the strategy of
Emacs or gcc. Indeed, it has always seemed that GNU has made a
reputation for absolutely solid products. The Fuzz Testing results
out of Wisconsin bear this out.

> So far, I haven't heard that Guile is wildly successful, but it's
> definitely a "worse is better" strategy: instead of writing 10,000
> line Tcl/Python/Perl programs, write 'em in Guile.

The ONLY -- O-N-L-Y -- benefit to Worse is Better is that it can help
you become wildly successful. Given that Guile hasn't become wildly
successful, what good is it?

> Doesn't everyone here use Emacs as an editor? It's not good Scheme,
> it's not even good Lisp, but it's good enough for a text editor, and
> it's got full kitchen sink capability.

Emacs is a great editor. It runs on a ton of platforms, it runs with
and without fancy graphics, it has lots of useful libraries, it is
easy to reconfigure, and it's highly robust, stretching far beyond the
breaking point of most other editors. The fact that is has a crappy
extension language is unfortunate, but I've long since given up
writing Elisp code (beyond a few lines of initialization -- for which,
it works just great). In fact, the original version of DrScheme was
written entirely as an Emacs extension. We learned fast.

It's nonsensical to compare Emacs to Scheme: one is an editor, the
other is a language. You could unfavorably compare Elisp to Scheme,
but who cares? If I had to find a language analog to Emacs the
editor, it might be Common Lisp, and I think Common Lisp is one of the
great accomplishments of CS.

> PLT Scheme has higher aims: you're not content with better-than-Python
> code, you want to write truly good code, which means good design
> decisions from the beginning

I've never said that, nor has anyone else I know associated with the
project. Indeed, we're all deeply appreciative of the software
evolution process, which tells us that software products are never
finished, and good designs are impossible to predict. I swear by
Perlis's epigram, "Design everything top-down -- except the first
time". Indeed, because we recognize the fragility of code and the
constant evolution of requirements, we build tools such as static
program analyzers and type inference engines.

> I imagine the Guile idea is no matter how bad the
> existing code is, we can extend it with Guile.

That's an incredibly naive statement. Indeed, I'm quite sure you
don't mean that. There is a point beyond which code is impossible to
extend. There is a much earlier point beyond which, while a program
can be extended, it probably shouldn't be.

Shriram

Shriram Krishnamurthi

unread,
Nov 18, 2001, 12:30:09 AM11/18/01
to
markj...@cloaked.freeserve.co.uk (MJ Ray) writes:

> The only real viable option I could see was to use
> the PLT webserver to keep the connections open, but how to do it was just
> too damn frustrating for someone without a degree in pure computer science.

A great criticism. That's why we're putting out How to Use Scheme.
We'll be writing Web programming modules that include neat
applications that use our server. If there's user interest, those
things will happen sooner rather than later.

> >You're a smart guy; surely you see that most Schemes differ in no
> >small part because of fundamental philosophical differences? [...]
>
> Should these differences be so rudely visible to the application author,
> though? I'm not asking for you to go and reimplement your systems in a
> different way, just to present a uniform interface for us poor programmers
> where it is possible and appropriate.

I'm not sure what that uniform interface would be. Evidence suggests
it's hard to agree on one.

There is a problem with the Scheme community, which is everybody's
just a little brigher than desirable. Which means, whenever one
person proposes something, each of the N other people find N things
slightly wrong with it. And of course, we can't adopt anything that
it's the Right Thing (he says not entirely facetiously), so we agree
to not adopt anything at all.

That said, there is no shortage of excellent (if incompatible) module
systems already in place for various quality Schemes, with fine
justifications for differing from the others. Did the latest kid on
the block, Guile, adopt any of these wholesale?

> does PLT scheme have an interface to fltk?

That looks like a word you can't use in polite company. An interface
to what? I'm sure we don't. Roughly every few months someone new
asks us if we've got an interface to their favorite GUI library. Just
once, I'd like to see one of these people come back with an actual
binding ... (Who do they think would define it? Us? We're (somewhat)
happy with the GUI library we've got!)

> Finally, how does one obtain a multipart/digest format digest of the PLT
> scheme mailing list? I guess I should rejoin it, but the web site is not
> clear on how to do this.

I'm not sure; I'll find out and augment the site.

Shriram

Tim Josling

unread,
Nov 17, 2001, 11:47:32 PM11/17/01
to
Would you mind summarizing the faults you find with Guile, specifically.
Generalisations like "makes my stomach turn" "monument to X's ego" etc
are not really helpful. But if there are good reasons to avoid it I
would like to hear.

I just started using scheme. I started with umb-scheme and dropped it
because it seems to have a hard wired and unchangeable heap limit of
under 1mb. Also it is slow. Currently I am using mit scheme. My only
gripe is the inability to call user-written C functions in Unix.

As a general rule, 'when there are many solutions, none are any good'.
This applies to software development methodologies, hangover cures, etc.
Is it true of scheme implementations?

Tim Josling

IsraelRT

unread,
Nov 18, 2001, 3:39:28 AM11/18/01
to
On Sat, 17 Nov 2001 19:24:10 -0800, Jeffrey Siegal <j...@quiotix.com>
wrote:

>Emacs and Gcc have never followed a "worse is better" strategy

The nature of elisp suggests that may not be entirely true.

Lauri Alanko

unread,
Nov 18, 2001, 6:07:41 AM11/18/01
to
In article <w7d3d3e...@cs.brown.edu>,

Shriram Krishnamurthi <sk...@cs.brown.edu> wrote:
> And on the other hand, can you explain how your present favored
> implementation, Guile, is *anything but* an exercise in ego by
> Stallman and Lord?

As a former guile user turned mzschemer, I think I can point out some
of the things I miss from guile.

* Terminal interface. Usually I run mzscheme in an emacs buffer, but when
I do something from a plain (x)terminal, it's a pain when you cannot do
proper command line editing. Guile has full readline support. Tab
expands to names in current scope. There's paren matching. And online
help. Mzscheme's text interface is not very fun for interactive use.

(No, I won't use DrScheme. Firstly, I want to do all my editing stuff in
the same emacs, and secondly, DrScheme often gets stuck at startup with
my window manager, Ion, probably because Ion often will not give the
application the window size it requests. (Yes, I know I should have
reported this as a bug. Sorry.))

* Simple modules. Mzscheme's unit system is very powerful, but it is also
very very clumsy. It's great if you want to do mixins, but more often
than not, I think, one just wants a simple namespace where stuff is
defined, but only some of it is exported. In guile, one just needs to
write the file, start it with (define-module (my module) :use-module (my
import)), and define the exported stuff with define-public, and put the
file in the right place, and say (use-modules (my module)) where I want
to use it. None of this mess with separately defining signatures, units
and linkages. I ended up writing my own module system using mzscheme's
namespaces.

* Eval. The main reason I use scheme is eval. If I don't need eval, I'll
use ML or Haskell. I also want to be very strict about what kind of an
environment an expression is evaluated in. In guile, I can create
modules at runtime at will, and specify what modules they import. In
mzscheme, I can only do this for stuff written for my own module system
(since units aren't namespace objects), and even then the lack of
first-class locations (which guile has) makes this imperfect. Guile also
allows you to set a hook to eval, which means that you can create
bindings only when they are needed.

* Space. In guile, a cons cell takes two words. In mzscheme, it takes
four. This is quite a difference, considering that a cell is probably
the most common heap object.

* Backtraces. This has been mentioned before. A good backtrace is pretty
essential for debugging.


Now, I still _did_ convert to mzscheme, for good reasons. Guile is
really slow, and the implementation is an utter mess. But guile is by no
means clearly inferior in every way.


Lauri Alanko
l...@iki.fi

Bill Richter

unread,
Nov 18, 2001, 9:37:38 PM11/18/01
to
Thanks, Shriram.

The ONLY -- O-N-L-Y -- benefit to Worse is Better is that it can
help you become wildly successful. Given that Guile hasn't become
wildly successful, what good is it?

Good point.

> I figure Stallman and Lord are pursuing a Gabriel "worse is
> better" strategy: we can write tons of "bad" code, backwardly
> compatible with tons of other "bad" code.

In my opinion, based on many years of trying to get at the heart of
the sofware process, this sounds like a pretty dumb strategy.

I agree! But it's a "tried & true" strategy, right? No reason to
accuse folks of egoizing for pursuing this "pretty dumb strategy",
which makes one oblivious to questions of good design.

> Kind of like Microsoft maybe ("We ship buggy code fast!")

I certainly agree that this appears to be Guile's strategy. I've
seen several Guile library snippets that make my digestive system
want to surrender my lunch.

That's great! OK, but it worked for Microsoft, right?

> The success of Emacs & Gcc & the GNU project shows that it's been
> a successful strategy.

Worse is Better has never, in my estimation, been the strategy of
Emacs or gcc. Indeed, it has always seemed that GNU has made a
reputation for absolutely solid products.

I agree that GNU is solid, and I attribute that to Stallman's
completely admirable obsession for bug fixing. That doesn't mean it's
elegant code!!! Having pretested Emacs for 8 years or so, I say it's
not elegant. Not that I'm an expert. Consider the way that Mule (not
Unicode) was shoved into Emacs 20 (not XEmacs) to the chagrin & dismay
of all the Emacs internals. That's shows a real disregard for elegant
design that makes #f vs () look like child's play.


> Doesn't everyone here use Emacs as an editor?

Emacs is a great editor. It runs on a ton of platforms, it runs


with and without fancy graphics, it has lots of useful libraries,
it is easy to reconfigure, and it's highly robust, stretching far
beyond the breaking point of most other editors. The fact that is

has a crappy extension language is unfortunate ...

It's nonsensical to compare Emacs to Scheme: one is an editor, the
other is a language.

I mean that Elisp, the "crappy extension language", is according to
Stallman the real gem of Emacs! In his seminal Guile manifesto ("Why
you should not program in Tcl"), Stallman explained how original Emacs
was written in TECO and so it couldn't be extended. Switching from
the (completely busted) TECO to the (crappy) extension language Emacs
Lisp was a *huge* advantage! The purpose of Guile is to extend the
Emacs Lisp "miracle" to the rest of the software world.

I don't expect (or want) you to share this aim. In fact, I want to
replace Emacs by an editor written in good Scheme, such as DrScheme.
Now so far, this is a "non-goal", as Matthias said, and maybe that
shows there's no real use to it. But lots of folks, including duffers
like me, have written lots of Emacs Lisp code. Why shouldn't we be
writing Scheme instead, with good abstraction guidelines... Might not
improve the editor much, but we might learn some Scheme...

Here's a dumb example. I didn't like the way you cited my letter, so
I added some spaces by

M-x query-replace-regexp >\([a-z,A-Z]\) RET > \1 RET

to turn

">Kind of like Microsoft" => "> Kind of like Microsoft"

I don't know how to do things like that in DrScheme. I also don't
know how to extend it in Emacs. The Emacs Lisp code for `C-s' (which
is related but simpler) is beyond me. If it was written in good
Scheme, I bet I could read it. I want to turn the Shift key into a
prefix key. And that works except in an isearch (`C-s') or things
like `C-x (' (begin keyboard macro (also unavailable in DrScheme)).
So, there are certain places in Emacs where my prefix key bombs out,
so I have to have a real shift key somewhere else. It's some sort of
`catch & throw' problem I think. I'm sure you'll agree that Emacs
Lisp doesn't do a good job with exceptions & continuations :)


> PLT Scheme has higher aims: you're not content with
> better-than-Python code, you want to write truly good code, which
> means good design decisions from the beginning

I've never said that, nor has anyone else I know associated with
the project. Indeed, we're all deeply appreciative of the software
evolution process, which tells us that software products are never
finished, and good designs are impossible to predict. I swear by
Perlis's epigram, "Design everything top-down -- except the first
time". Indeed, because we recognize the fragility of code and the
constant evolution of requirements, we build tools such as static
program analyzers and type inference engines.

OK, sorry, I misunderstood. That sounds good.

> I imagine the Guile idea is no matter how bad the existing code
> is, we can extend it with Guile.

That's an incredibly naive statement. Indeed, I'm quite sure you
don't mean that. There is a point beyond which code is impossible
to extend. There is a much earlier point beyond which, while a
program can be extended, it probably shouldn't be.

I'm certainly in agreement with your last 2 statements! But if Guile
is gonna be like Emacs, my statement may well be accurate :)

Bill Richter

unread,
Nov 18, 2001, 9:52:29 PM11/18/01
to
Emacs and Gcc have never followed a "worse is better" strategy. If
Guile is, that would represent a significant strategy shift, not a
continuation of past practices.

Maybe it is just "worse."

Sorry, Jeffrey, I wasn't too clear. Gabriel explains in "Worse Is
Better" how Unix & C are the "ultimate computer virus". That's the
sort of "worse is better" that I think Emacs & Gcc represent. After
all, the GNU project (partly successful in conjunction with Linux) was
an effort to replace the "ultimate computer virus" with a free
software version, hopefully better, but freedom was the issue.

Are we in agreement here? Now I'll rant disjointedly:

But the "worse is better" strategy that Gabriel promoted himself was
for the Lisp community to embrace Common Lisp (with all it's supposed
flaws): we should engage the C/Unix enemy instead of infighting
ourselves. So maybe the obvious analogue of Gabriel's message might
be that Guile should accept more established Scheme conventions (with
all their supposed flaws).

So maybe I didn't use "worse is better" as Gabriel's did. But I'm not
in agreement with Gabriel. I don't think that Common Lisp is
infinitely better than C. I think it's significantly better, but what
I really want is Math, including Plotkin & Felleisen's LC_v, and
Scott's point set topology models of LC. And when assigment features
were added to LC_v to produce Lisp/Scheme, the Math took a real hit,
which I don't think it's recovered from yet.

--
Bill
<http://www.math.nwu.edu/~richter>

Jeffrey Siegal

unread,
Nov 18, 2001, 10:22:35 PM11/18/01
to
Bill Richter wrote:

> That's great! OK, but it worked for Microsoft, right?

Not necessarily, no. Microsoft may well have succeeded despite it.


Bill Richter

unread,
Nov 18, 2001, 11:27:28 PM11/18/01
to
> > That's great! OK, but it worked for Microsoft, right?
>
> Not necessarily, no. Microsoft may well have succeeded despite it.

That's interesting, Jeffrey. Still, it was the Microsoft strategy, to
inundate us with quickly written code, which would then be debugged in
later versions, rather than to hatch an elegant design, and use
elegant tools? If you say that Microsoft succeeded in spite of this
strategy, you may be right. We can talk about trade violations...
But my guess is that the strategy worked. If Microsoft had written
better code, a group with even lower standards might have jumped in to
flood the market with still more inferior products.

I figure if you're trying to do a really good job, you should strive
for elegant design and use elegant tools. That's the PLT Scheme
approach, and I'm all for it. But sometimes a bad job suffices. Then
maybe the victory goes to whoever writes enough code quickly enough.

Emacs might be a good example. We all think Emacs & XEmacs are great
editors, even though we scoff at Emacs Lisp. It's good enough! And
take the Mulification of Emacs 20, which forced tremendous internal
changes in the Emacs (not XEmacs). Stallman defended kludging up the
internals: "Right now (several years ago) we don't have a choice.
Unicode isn't here yet, so it's Mule or nothing. Kludge away!" This
sort of strategy often works (unfortunately).

--
Bill
<http://www.math.nwu.edu/~richter>

Jeffrey Siegal

unread,
Nov 19, 2001, 12:48:04 AM11/19/01
to
Bill Richter wrote:

> But my guess is that the strategy worked. If Microsoft had written
> better code, a group with even lower standards might have jumped in to
> flood the market with still more inferior products.

With perhaps trivial exceptions, Microsoft has never been first to the
market with any product. Not even close. And there are few if any
Microsoft products which clearly would not have been about as successful
had they taken longer to come to market.

The web browser is an easy, high profile example. Microsoft's early web
browsers were certainly "worse", but they did little to help MS succeed
in the marketplace. And even those were not first (or even quick) to
the market by any means. By the time MS's browser gained dominance, it
was pretty damn good, and it was both that quality and bundling that
made it successful; having shipped crap "quickly" (but still slower than
others in the marketplace) was of little benefit.

Sander Vesik

unread,
Nov 19, 2001, 5:14:45 AM11/19/01
to
Bruce Lewis <brl...@yahoo.com> wrote:
> Sander Vesik <san...@haldjas.folklore.ee> writes:

>> so make it foreach (sort keys % colorhash) -as a bonus, you get to choose
>> what and how you sort on. Yes, the in which orer we sort is something that
>> is likely to change a couple of times IRL.

> Neither Scheme nor Perl can compete with SQL w.r.t. ease of sorting, so
> it's best to just preserve the order they come in.

No, not really. How do you sort the strings ignoring the first k characters?

--
Sander

+++ Out of cheese error +++

Sander Vesik

unread,
Nov 19, 2001, 5:27:52 AM11/19/01
to

There's also the timy matter of what and why the egcs project was to
cast heavy doubt on that...

MJ Ray

unread,
Nov 19, 2001, 4:51:27 AM11/19/01
to
On 18 Nov 2001 00:20:24 -0500, Shriram Krishnamurthi <sk...@cs.brown.edu> wrote:
>to me, it was a statement of fact. If you consider Stallman's
>attitude toward the Scheme community as anything less than insulting,
>perhaps you need to consider recaliberation.

There's some history here I'm not aware of, clearly. Can someone provide me
with URLs etc, please? In any case, I've not seen RMS post to the guile
list recently, nor seen his name in the guile documentation anywhere.

>I've seen several Guile library snippets that make my digestive system want
>to surrender my lunch.

I think many people see many things that do that. The Good People submit
patches.

>Like I've said before, I'd sooner program in Perl than I would in Guile.
>There's simply no win there. Guile appears to me to be a weak Perl with a
>sub-optimal syntax.

Now, this seems just harsh and totally out of character for you, Shriram.
Tell me: what member of the Guile team ran over your cat?

At the end of it all, guile is scheme (which is nothing like perl) and it
has its uses, especially in the vast armada of contributed libraries. PLT
Scheme is approaching a similar number, but they currently do different
things well, so it's not a straight choice.

It is loading more messages.
0 new messages