Tcl & Scheme

[Olin Shivers]

I'll surrender to the temptation to add my two cents to the
tcl/Scheme flameage. Scheme is beautiful. But the standard doesn't
pin down enough for practical programming needs -- no exceptions,
record types, or module system. So everything that's written in the
language is implementation specific -- not portable.

In contrast to tcl, Scheme also lacks a portable C interface. And so on,
and so on.

It's not interesting to flame about why tcl is such a horrible language.
The reasons are all pretty obvious. Tcl solves a problem, horrible though
it may be, and Scheme, although beautiful, is not capable of solving these
problems. So the Scheme community needs to just shut up until and unless
they have a viable alternative to present the world. Less posting; more
hacking.

[ozan s. yigit]

Randy Sims <randa...@srs.gov> writes:

> > So the Scheme community needs to just shut up until and unless they
> > have a viable alternative to present the world. Less posting; more
> > hacking.
>

> What do you suggest for "more hacking"?
>
> Guile
> Scheme 48
> DrScheme
> Kawa
> ...

i think maybe olin means something that lets people use it instead of (say)
perl, and know that there is a whole community supporting that something,
busily writing programs to make life easier on various platforms etc.
[i would give my proverbial arm for a scheme advocate like tom
christiansen... :)]

oz

[Randy Sims]

--Multipart_Fri_Apr_18_13:18:56_1997-1
Content-Type: text/plain; charset=US-ASCII

Olin Shivers <shi...@lambda.ai.mit.edu> writes:

> So the Scheme community needs to just shut up until and unless they
> have a viable alternative to present the world. Less posting; more
> hacking.

What do you suggest for "more hacking"?

Guile
Scheme 48
DrScheme
Kawa
...

I vote for Kawa and for riding the Java wave.

http://www.cygnus.com/~bothner/kawa.html
ftp://ftp.cygnus.com:/pub/bothner/

--Multipart_Fri_Apr_18_13:18:56_1997-1
Content-Type: text/plain; charset=US-ASCII

Randal N. Sims (Randy) | Tel: (803)725-8347
Westinghouse Savannah River Co. | Fax: (803)725-8829
SRS, 773-42A, 129 | Email: randa...@srs.gov
Aiken, SC 29808-0001 USA | URL: "under construction"

DISCLAIMER: The opinions expressed are mine and do not necessarily
represent Westinghouse Savannah River Co. or the
United States Department of Energy.

--Multipart_Fri_Apr_18_13:18:56_1997-1--

[Olin Shivers]

o...@ds9.rnd.border.com (ozan s. yigit) writes:
> > > So the Scheme community needs to just shut up until and unless they
> > > have a viable alternative to present the world. Less posting; more
> > > hacking.
> >
> > What do you suggest for "more hacking"?
> >
> > Guile
> > Scheme 48
> > DrScheme
> > Kawa
> > ...
>

> i think maybe olin means something that lets people use it instead of (say)
> perl, and know that there is a whole community supporting that something,
> busily writing programs to make life easier on various platforms etc.
> [i would give my proverbial arm for a scheme advocate like tom
> christiansen... :)]

Oz has got it. Allow me to illustrate. Last week I wrote a little Web hack
with a friend -- an email reminder service to poke you about your mom's
birthday and such, using email addresses to index into a relational db. (You
can try it out at http://arsdigita.com/bday/)

I hacked in tcl, I'm sorry to say. This is pretty embarassing -- I do research
in Scheme and systems programmming in functional programming languages; I've
even written a Web server entirely in Scheme. Gosh -- obviously it would be
much better to write the service in Scheme. Well, OK. But my Web server was
written in scsh, which runs on top of Scheme 48. Not Scheme. Scheme 48. No
interface to relational databases. No separate compilation of modules. No
threads (in the version S48 I use). I could implement any or all of these
things. But not in an evening. Hmm. Well, how about if I run my Web server
code in a Scheme system that has threads or an SQL interface? Oops -- I
couldn't do that, because my server was written using Scheme 48 record types,
and Scheme 48's Clinger/Rees explicit-renaming low-level macros, and Scheme
48's exceptions, and Scheme 48's modules, and scsh's system calls. You can't
just load it into some other Scheme. You'd have to *port* it.

Programming in Scheme is an extremely unportable task if you do anything
serious. Scheme is much less portable than, say, tcl or C. So we are unable
to build on each other's work, but must instead keep re-inventing the wheel.

If you *union* up the technology and features in all the Scheme
implementations out there, you have an amazing tool. But each implementation
is different, and all lack some important features. You don't hear people
saying, "I wrote my program in SGI's implementation of C -- I can't run
it on your Linux box because the struct declarations are different, and
Linux's C implementation doesn't have do-while loops. Also, the interface
the Unix write() function is different, so I'd have to rewrite all the I/O."

I couldn't solve my problem in Scheme. And I am tolerably well acquainted with
the language and its implementations. I could solve my problem with tcl. The
server we were running had a tcl interpreter linked in, and the tcl system
had hooks to an RDBM interface. Took an evening.

As long as this situation persists, the Scheme community can snipe about
what a lousy, poorly-designed language tcl is, but they aren't in a position
to offer a credible alternative. So it is just empty flaming. So why post?
Go fix the problem.
-Olin

[Bengt Kleberg]

In article <qij3esp...@lambda.ai.mit.edu>, Olin Shivers
<shi...@lambda.ai.mit.edu> wrote:

> I'll surrender to the temptation to add my two cents to the
> tcl/Scheme flameage. Scheme is beautiful. But the standard doesn't
> pin down enough for practical programming needs -- no exceptions,
> record types, or module system. So everything that's written in the
> language is implementation specific -- not portable.
>
> In contrast to tcl, Scheme also lacks a portable C interface. And so on,
> and so on.
>
> It's not interesting to flame about why tcl is such a horrible language.
> The reasons are all pretty obvious. Tcl solves a problem, horrible though
> it may be, and Scheme, although beautiful, is not capable of solving these

> problems. So the Scheme community needs to just shut up until and unless

> they have a viable alternative to present the world. Less posting; more
> hacking.

Since I'm not doing any hacking my view might not be of interest. But I
fully agree with all of the above (thinking that a module system is
prio#1).
And I would like to add an observation: comp.lang.python is almost twice
the size of comp.lang.scheme.

--
Best Wishes, Bengt

Email: ben...@damek.kth.se

[Fernando Pereira]

In article <qij208798...@lambda.ai.mit.edu>, Olin Shivers
<shi...@lambda.ai.mit.edu> wrote:
> [various good reasons why existing Scheme implementations couldn't do the job]

> I couldn't solve my problem in Scheme. And I am tolerably well acquainted with
> the language and its implementations. I could solve my problem with tcl. The
> server we were running had a tcl interpreter linked in, and the tcl system
> had hooks to an RDBM interface. Took an evening.
>
> As long as this situation persists, the Scheme community can snipe about
> what a lousy, poorly-designed language tcl is, but they aren't in a position
> to offer a credible alternative. So it is just empty flaming. So why post?
> Go fix the problem.

This is not just a Scheme problem. Prolog suffered terribly from it, and I
think ML is going the same way with its incompatible SML and CAML camps.
Why? Here are some observations from my experience with the Prolog world
and familiarity with the ML world:

* the proponents of those languages are more interested in ideas than in
solutions; that's natural, because academics and research lab people tend
to be selected for their ability with ideas, not for their practical bend

* confrontation of ideas is the highest form of engagement in the
academic/research lab world; bulding on the creations of others, with the
compromises it requires, is less valued

* languages must fit into the intellectual and cultural environment of
current programmers to be successful; Scheme, Prolog or ML are more remote
from familiar concepts, precluding incremental evolution of programming
skills and practices

* Tcl, Perl and Python are essentially the creation of individual
outstanding programmers who recognized a need and did not let ideological
qualms stand in the way of a convenient, if sometimes quirky, solution;
Java and VB have huge corporate clout behind them, again encouraging
satisficing rather than ideological purity

* It may be too late: Scheme, Prolog and ML have all been around since the
70s. If their advocates could not get their act together when they had
much more mindshare, it's unlikely they will get it together in the
present very competitive environment.

Now for a tale similar to Olin's. I am co-author of a weighted
finite-state transducer library (in C) that has found quite a bit of use
in text and speech processing applications at AT&T and Lucent. It badly
needs an extension language. We have experimented with Scheme, but we
haven't found a Scheme that is sufficiently portable, documented and
unintrusive with respect to memory management and footprint to make it
part of the overall system, even though having an extension language would
help our users substantially. There are several reasons why a basically
functional language is just what is needed for this, but we haven't found
one that we can use in this way without trouble. If programmers like us,
who are sympathetic to such languages, can't find what we need, what's the
chance that more neutral programmers would?

[Richard Coleman]

In article <qij208798...@lambda.ai.mit.edu>, Olin Shivers
<shi...@lambda.ai.mit.edu> wrote:
> [various good reasons why existing Scheme implementations couldn't do the job]
> I couldn't solve my problem in Scheme. And I am tolerably well acquainted with
> the language and its implementations. I could solve my problem with tcl. The
> server we were running had a tcl interpreter linked in, and the tcl system
> had hooks to an RDBM interface. Took an evening.
>
> As long as this situation persists, the Scheme community can snipe about
> what a lousy, poorly-designed language tcl is, but they aren't in a position
> to offer a credible alternative. So it is just empty flaming. So why post?
> Go fix the problem.

I couldn't agree with Olin more. This was the mindset I had, when I
first posted about Ousterhoust's white paper in the Scheme newgroups
(yes, I started this mess). What I was hoping was that the Scheme
community would read this paper and respond by writing code and utilities
to help compete against tcl and perl. Instead, everyone got defensive,
and started attacking the validity of every idea in that paper.

Yes, I realize Ousterhoust's paper was basically an info-mercial, and
wasn't meant to be a serious study on the use of "system" vs. "scripting"
languages. That's the whole point. Selling the sytem.

What's make tcl/tk and perl good languages is that they are general
purpose hammers. They have interfaces or modules for just about
everything. They get the job done. Period. No amount of arguing about
the syntatic/semantic "purity" of languages will change this.

Although many will not agree with this (and this is just my opinion),
the Guile project is the last/best hope for the Scheme community. It is
the only Scheme implementation that could have a high enough profile
(due to FSF) to gather enough support to add all the necessary extras.
I really hope this happens.

Richard Coleman
col...@math.gatech.edu

[Brian D. Carlstrom]

Richard Coleman <col...@math.gatech.edu> writes:

Although many will not agree with this (and this is just my opinion),
the Guile project is the last/best hope for the Scheme community. It is
the only Scheme implementation that could have a high enough profile
(due to FSF) to gather enough support to add all the necessary extras.
I really hope this happens.

I have given up on the elders in the Scheme community. They have never
had the practicality of Larry Wall or John Ousterhout. Guile has been
going off in the wrong direction, making choices based on GPL politics.

Although many will not agree with this (and this is just my opinion),

Cygnus's Kawa is the last/best hope for the Scheme community. It is the
only Scheme implementation that could have a chance to add all the
necessary extras to gather enough support in the form of a user
community. I really hope this happens.

How can Kawa accomplish this? By leveraging industry commitment to Java.
Java 1.1 Reflection will allow Scheme to access many system services
that have been lacking in a single implementation in the past such as
networking, subprocess manipulation, databases, user interfaces, etc.

Kawa also gains a lot more by compiling to Java byte code. What other
language has so many runtimes competing for the best JIT and garbage
collection? How many runtimes offer portability to Windows, Unix, and
Macintosh, in decreasing order of importance...

Having worked with Olin Shivers on the Scheme Shell and having done my
own embedded Scheme interpreter in Java I know the power of combining an
elegant language with a system programming APIs. I would encourage
everyone to take a look.

http://www.cygnus.com/~bothner/kawa.html

-bri

[Martin Cracauer]

Olin Shivers <shi...@lambda.ai.mit.edu> writes:

[...]

>I hacked in tcl, I'm sorry to say. This is pretty embarassing -- I do research
>in Scheme and systems programmming in functional programming languages; I've
>even written a Web server entirely in Scheme. Gosh -- obviously it would be
>much better to write the service in Scheme. Well, OK. But my Web server was
>written in scsh, which runs on top of Scheme 48. Not Scheme. Scheme 48. No
>interface to relational databases. No separate compilation of modules. No
>threads (in the version S48 I use). I could implement any or all of these
>things. But not in an evening. Hmm. Well, how about if I run my Web server
>code in a Scheme system that has threads or an SQL interface? Oops -- I
>couldn't do that, because my server was written using Scheme 48 record types,
>and Scheme 48's Clinger/Rees explicit-renaming low-level macros, and Scheme
>48's exceptions, and Scheme 48's modules, and scsh's system calls. You can't
>just load it into some other Scheme. You'd have to *port* it.

But what's wrong with SLIB's approach? Provide the interfaces you want
on almost every Scheme implementation, either as Scheme code on top of
existing functionality - maybe slow - or you could go and implement a
feature on a given implementation in an efficient manner.

This is not a rethorical question. I'm a Common Lisp user and never
used SLIB (or Scheme, for that matter) in a real project. I.e. why
didn't you use a records interface from SLIB? And can't one define a
useful exception mechanism that could (but doesn't have to) be
implemented using continuations?

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin_...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin

[Samuel S. Paik]

In article <pereira-1904...@baldy.research.att.com>,

per...@research.att.com (Fernando Pereira) wrote:
>We have experimented with Scheme, but we
>haven't found a Scheme that is sufficiently portable, documented and
>unintrusive with respect to memory management and footprint to make it
>part of the overall system,

From time to time, I look at various languages for embedding and scripting
existing programs. Some additional problems I usually see with Scheme
implementations include:

The foreign function interfaces are awkward to use or clashes
with the rest of the system (e.g., we have our own automatic memory
management, which clashes with the Scheme implementation's garbage
collector).

The license terms don't allow us to use it. You can't use anything
with a GPL-like license to embed with, and so many other implementations
say things like "no commercial use allowed". I'd love to use
Objective Caml, but can't/won't for this reason.

TCL on the other hand has a Berkeley style license, and works well with
C--because it was meant to.

Header2Scheme looks like an interesting project, too bad scm is GPLed.
I'm currently experimenting with RScheme and DrScheme though.

Any suggestions for:

A systems programming language to implement a simulator for a VLSI
chip? It must allow commercial use, compile to fast code,
call C/C++, allow explicit control of memory layout down to the bit
level when necessary with precisely sequenced memory writes, produce
standalone executables, produce C/C++ callable libraries, have good
low level and high-level debuggers. An interactive loop would be
nice, as well as a good GUI IDE.

An embeddable scripting language, which addresses the problems mentioned
above. As mentioned, I'm considering RScheme and MzScheme, as well
as Tcl, Python, Siod. I've already rejected Bigloo, Gambit-C,
Objective Caml, Scheme48, Scheme->C.

Oh, both of these needs to run on Win32 and Unix.

Sam

--
Samuel S. Paik / pa...@webnexus.com / 408-749-8798
Guy [Gavriel Kay]'s been living here in Toronto for the last two years. I believe that
means the new book is going to be called THE BLUE JAYS OF AL-SKYDOME ...
- Robert J. Sawyer

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Martin" =3D=3D Martin Cracauer <crac...@wavehh.hanse.de> writes:

Martin> But what's wrong with SLIB's approach? Provide the interfaces you w=
ant
Martin> on almost every Scheme implementation, either as Scheme code on top=
of
Martin> existing functionality - maybe slow - or you could go and implement=
a
Martin> feature on a given implementation in an efficient manner.

The major problem with SLIB is that it imposes a packaging approach
which does not port well to, say, batch-compiled systems such as
Bigloo and Gambit-C.

Here is generally a big problem with the usability of Scheme: How do I
ship a piece of Scheme code and have it install under multiple Scheme
implementations? At least, all major C compilers are batch compilers
and have pretty much isomorphic (read: "make"-customizable)
interfaces.

Admittedly, this problem is a hard one to solve.

--
Cheers =3D8-} Mike
Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla

[Per Bothner]

In article <paik-20049...@192.168.13.2>,

Samuel S. Paik <pa...@webnexus.com> wrote:
> The license terms don't allow us to use it. You can't use anything
> with a GPL-like license to embed with, and so many other implementations
> say things like "no commercial use allowed".

Do note that the Guile license states that "if you link the GUILE
library with other files to produce an executable, this does not by
itself cause the resulting executable to be covered by the GNU General
Public License". The FSF's intention is that you should be free
to use Guile or libguile if unmodified for commercial systems.
This is not obvious - for example the top-level COPYING file does
not mention this exception. Stallman has confirmed my understanding
that the FSF wants Guile/libguile to be usable by non-free projects,
and we have discussed ways to make the license more clear.

(I am not actively involved wih Guile at this point, but this came
up while discussing some "gnu" Java packages and their licensing.)
--
--Per Bothner
Cygnus Solutions bot...@cygnus.com http://www.cygnus.com/~bothner

[Chris Bitmead uid(x22068)]

ben...@damek.kth.se (Bengt Kleberg) writes:

> And I would like to add an observation: comp.lang.python is almost twice
> the size of comp.lang.scheme.

What does this mean? That python users need a lot more hand-holding
than scheme users?

[Russ McManus]

brian-

b...@berne.ai.mit.edu (Brian D. Carlstrom) writes:

>
> I have given up on the elders in the Scheme community. They have never
> had the practicality of Larry Wall or John Ousterhout. Guile has been
> going off in the wrong direction, making choices based on GPL politics.
>

what choices are you referring to? you are painting with a
very wide brush at this point.

> Although many will not agree with this (and this is just my opinion),
> Cygnus's Kawa is the last/best hope for the Scheme community. It is the
> only Scheme implementation that could have a chance to add all the
> necessary extras to gather enough support in the form of a user
> community. I really hope this happens.
>

i also think that the scheme community needs to make scheme
a practicle choice. compiling scheme to the jvm is definitely
part of the answer.

so is a portable way to interface scheme and c, which the guile
project is attempting to establish via the gh interface/library.
details are included in the guile documentation.

so is multi-language syntax, which the guile project is addressing.

so is a standard module system. this one no one has addressed.
the only hope here is that a particular implementation gains
enough mind share to become a de facto standard.

i would anticipate that the guile project is going to continue
it's steady improvement, because of the FSF backing and it's
commitment to provide a practicle programming environment.

i don't know about the long term goals of the kawa project,
or it's prospects for continued improvments. maybe i could
use some education here. why do you think that kawa is the

"only Scheme implementation that could have a chance to add

all the necessary extras to gather enough support"?

-russ

--
Russell D. McManus phone: 212-357-4901
Goldman, Sachs & Co. beep: 917-556-0708
Intl. Equities Technology

[Brian Rogoff]

On 18 Apr 1997, Olin Shivers wrote:
> Programming in Scheme is an extremely unportable task if you do anything
> serious. Scheme is much less portable than, say, tcl or C. So we are unable
> to build on each other's work, but must instead keep re-inventing the wheel.

So the language specification is at fault, for not providing things like
modules, records/structs, threads, exceptions, and an object system?

> <... story of inability to use Scheme deleted...>

> As long as this situation persists, the Scheme community can snipe about
> what a lousy, poorly-designed language tcl is, but they aren't in a position
> to offer a credible alternative. So it is just empty flaming. So why post?
> Go fix the problem.

It sounds like there is a lot of hacking going on, just that you can't use
theirs and they can't use yours, 'cuz Scheme-48 and MzScheme and AcmeScheme
and all of the other Schemes are incompatible. Hacking code won't fix this
problem. Either you have "The Highlander" solution ("There can only be
one!" implementation), like tcl and Perl, or you need a better standard.

-- Brian

[Per Bothner]

In article <ncjd8rp...@nytrdc058.eq.gs.com>,

Russ McManus <mcm...@nytrdc058.eq.gs.com> wrote:
>i don't know about the long term goals of the kawa project,

How about "Continued improvement"? I do have plans to make Kawa
better and faster, and in general make it best all-around
Scheme implementation available!

However, I am also thinking about other source language front-ends
to the Kawa system. One important such language is DSSSL, a
Scheme-derived language for processing SGML.

Since Kawa currently is a one-man unfunded part-time project,
improvements will be limited by available time. Still, if you
look at the features added since it turned from a funded to an
unfunded part-time project (last September), I think it is a
pretty good list (defmacro (in addition to define-syntax);
make-record-type; keywords; #!optional, #!rest, and #!keyword
specifiers in lambda lists); complex numbers; completed exact
rational arithmetic; quantities and units; eval; internal define;
hooks to call arbitrary Java methods; a testsuite; and more).

>or it's prospects for continued improvments.

A number of planned improvements assume a Java implementation
that supports the new JDK 1.1 features. Those improvements
will probably make it so Kawa will no longer work on older
Java implementations. So I am holding off making those
changes until at least Kaffe (a free Java VM we are using)
supports those features.

> "only Scheme implementation that could have a chance to add
> all the necessary extras to gather enough support"?

While those are not my words, it is clear that a lot of standard
libraries and features are being added to Java. These include
"picking", Unicode, portable GUI and other APIs, etc etc.
Those will be available from Kawa too - once you have designed
and implemented a Scheme interface to those features. Of course
that is not necessarily a trivial task. In some cases we can
re-use an existing Scheme API.

[P. Srinivas]

Is there any real reason other than egos that prevents all Schemer's
rally behind Guile? Most Schemers are smart and capable of implementing
their own version of scheme over weekend and start the real project the
monday morning. That is real strength of Scheme/Lisp languages.
But this is acting as a deterrent to any viable single scheme
that can compete other langauges. I suggest one approach
for all Lisp/Scheme lovers.

a) Everybody can implement her own version for
testing various ideas. But at the same time all should
rally for political reasons behind ONE implementation.
b) Whenever somebody asks for suggestion, there should be ONE single
system that I can recomond with my eays closed. Everybody
should stick to this one when a novice asks a question
on the net as to which scheme to use for a project.

c) When some features tested on owns privite scheme and works well,
he should make sure that feature also works for the ONE TRUE
Scheme. That way, we do not need to recomond some other Scheme than
the ONE TRUE SCHEME for the sake of that perticular feature.

We can choose any existing Scheme for this purpose.

Is there any reason not to consider GUILE as the possible candidate
for this?

If we are not politialy smart, Scheme will die as a practical programming
langaues. It will stuill survive in select group of lingo people.

Just my thoughts.

srini

[Alaric B. Williams]

On 22 Apr 1997 04:31:34 GMT, sr...@skorpio3.usask.ca (P. Srinivas)
wrote:

>b) Whenever somebody asks for suggestion, there should be ONE single
> system that I can recomond with my eays closed.

What's an eay? An eye, or an ear?

ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."

(Windows for Early Warning and Defence User's manual P26)

Alaric B. Williams Internet : ala...@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>

[Marc Wachowitz]

P. Srinivas (sr...@skorpio3.usask.ca) wrote:
> Is there any real reason other than egos that prevents all Schemer's
> rally behind Guile?

There are very different purposes and environments for using Scheme,
and Guile - or any other current implementation I know about - simply
doesn't support each of those sufficiently well. It may even be very
hard to have a single implementation support the variety of reasonable
requirements well at all, though technically one can surely provide
much more flexibility than existing implementations. However, even a
great programmer wouldn't program that over a weekend; several months,
if not years, would be a more realistic time frame for a very broad
spectrum including e.g. _both_ excellent optimization and an excellent
interactive development environment, and interoperability with other
systems. Strong preferences for only some subset of the reasonable
requirements can simplify this considerably, but this will make the
result a poor choice for some different preferences.

Without the alluded giant effort, the best one might hope for is a good
consensus on interfaces for desirable facilities/properties, which should
be supported by any implementation which is supposed to provide such a
facility at all, and doesn't narrow the implementation choices more than
necessary (e.g. allow a _gradual_ movement from simple static translation
to almost arbitrary run-time modification, by providing layers which can
stand well on their own). Crafting such interfaces isn't something which
most people I know would do well by just throwing together some ideas
and implementing them in a single system. Careful design requires study
of existing approaches and their problems, and the will to question both
what one learned and what appears "intuitively" appealing. I'm afraid you
won't get that by making propaganda for "the one and only true system".
Of course, if you just want to attract the masses without fulfilling any
advanced requirements, hacking something together might work - just don't
expect that everyone puts forgets their interests and follows you.

Just to tell with my personal preferences: I want full compilation to
machine code (reasonably efficient C code generation is fine), and
a module model with static semantics, which allows separately compiled
modules to be linked just like one would do with compiled C files,
integrating an excellent macro system (something like syntax-case). I
like the complete numerical tower (including exact/inexact variants)
to be available, with decent efficiency, and a means to declare cases
where fixnum or flonum arithmetic is sufficient and expected for good
performance. Interfaces to system libraries - including those with more
complicated C types than the predefined ones - should be sufficiently
simple to implement, such that one doesn't have to hesitate if one's
pet library isn't supported, but can easily add interface declarations
as one discovers a need for them. Dynamic loading should be available,
but not necessary for system operation. Debugging the generated code
with a standard system debugger should be acceptable for someone who's
somewhat familiar with the implementation strategies. A system which
doesn't use EVAL, LOAD etc. shouldn't need to link in much more beyond
its actual requirements. The interface between the Scheme libraries
and the operating system should be exchangable, such that one could
merely link with another interface library e.g. to provide a fully
checked safe environment for untrusted code (obviously, this implies
control over the foreign function interface, too), or support the
low-level requirements of something like scsh. The system should be
a conforming superset of R4RS, with the changes agreed upon for R5RS.
It should be object-oriented from the ground up (with a MOP similar
in style to CLOS or EuLisp's, though clarity and efficiency are
preferable over run-time changes; e.g. allowing redefinitions only
in "development mode" may reduce quite a few optimizations compared
to "delivery mode"). I guess it will take more than a weekend ;-)

-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>

[Arturo PŽrez]

In article <1997Apr18....@srs.gov>,
Randy Sims <randa...@srs.gov> wrote:

>Olin Shivers <shi...@lambda.ai.mit.edu> writes:
>
>> So the Scheme community needs to just shut up until and unless they
>> have a viable alternative to present the world. Less posting; more
>> hacking.
>

>What do you suggest for "more hacking"?
>
> Guile
> Scheme 48
> DrScheme
> Kawa
> ...
>

>I vote for Kawa and for riding the Java wave.
>
> http://www.cygnus.com/~bothner/kawa.html
> ftp://ftp.cygnus.com:/pub/bothner/
>
>

I second. So, what does Kawa need to help it take over the world?

(I haven't done anything in it yet...)

[giacomo boffi]

Richard Coleman <col...@math.gatech.edu> writes:
> What's make tcl/tk and perl good languages is that they are general
> purpose hammers.

may i add that their developers apparently love to write good
documentation?

gb

[Harvey J. Stein]

In article <bengtk-1904...@sl20.modempool.kth.se>

ben...@damek.kth.se (Bengt Kleberg) writes:
And I would like to add an observation: comp.lang.python is almost twice
the size of comp.lang.scheme.

Of course it is. It takes twice as much effort in python to get the
same results as in scheme.

--
Harvey J. Stein
Berger Financial Research
ab...@netvision.net.il

[aaron_...@msn.com]

since python came up...

In article <paik-20049...@192.168.13.2>,

pa...@webnexus.com (Samuel S. Paik) wrote:
> TCL on the other hand has a Berkeley style license, and works well with
> C--because it was meant to.

So was Python, and it's a lot better as a language, IMHO.

> Header2Scheme looks like an interesting project, too bad scm is GPLed.
> I'm currently experimenting with RScheme and DrScheme though.
>
> Any suggestions for:
>
> A systems programming language to implement a simulator for a VLSI
> chip? It must allow commercial use, compile to fast code,
> call C/C++, allow explicit control of memory layout down to the bit
> level when necessary with precisely sequenced memory writes, produce
> standalone executables, produce C/C++ callable libraries, have good
> low level and high-level debuggers. An interactive loop would be
> nice, as well as a good GUI IDE.

You're asking a lot :). In principle, Python with enuf C support might
do it, but a lot of things are possible in principle. Happily, writing
C support for Python is easy. If you throw away the "fast" requirement
Python might be okay for everything else. Also, if the simulation
maps onto array or matrix operations Python might be fast too.

> An embeddable scripting language, which addresses the problems mentioned
> above. As mentioned, I'm considering RScheme and MzScheme, as well
> as Tcl, Python, Siod. I've already rejected Bigloo, Gambit-C,
> Objective Caml, Scheme48, Scheme->C.
>
> Oh, both of these needs to run on Win32 and Unix.

Please look to my book "Internet Programming with Python" for
a netscape server API (nsapi) embedding of Python, which runs on Win32
and Unix, might help as an example :). -- Aaron Watters
===
Pay no attention to the man behind the curtain!

-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet

[Richard Cobbe]

I disagree. I own copies of both the Camel and Llama books. The
first one, "Learning Perl", does a decent job as a language
introduction. The second book, I think, tries to be both a tutorial
and a reference manual. This has the result that it does neither
well. There's too much information, and it's too dense, so it's not a
good tutorial/intro. Plus, the material isn't organized in a very
useful or findable fashion, so it's not particularly useful as a
reference. (Yes, I know about the chapter containing function
definitions; I'm referring mostly to syntactic rules, regexps, file
operators, and so forth.)

I haven't read the tcl/tk docs, so I can't comment on those, but I
would have constructed the Perl docs very differently.

Richard

[Tad McClellan]

Richard Cobbe (co...@rice.edu) wrote:

: giacomo boffi (bo...@rachele.stru.polimi.it) wrote:
: > Richard Coleman <col...@math.gatech.edu> writes:
: > > What's make tcl/tk and perl good languages is that they are general
: > > purpose hammers.

: > may i add that their developers apparently love to write good
: > documentation?

: I disagree. I own copies of both the Camel and Llama books. The

^^^^^^^^^^^^^^^^^^^^^

I expect that giacomo was referring to the free documentation
that is included with the perl distribution.

wc -l *.pod

Tells me there are 27164 lines of it.

At 66 lines a page, that is over 400 pages. And it's free!

grepping in there answers about 90% of the questions I get...

: first one, "Learning Perl", does a decent job as a language

: introduction. The second book, I think, tries to be both a tutorial
: and a reference manual. This has the result that it does neither
: well. There's too much information, and it's too dense, so it's not a
: good tutorial/intro. Plus, the material isn't organized in a very
: useful or findable fashion, so it's not particularly useful as a
: reference. (Yes, I know about the chapter containing function
: definitions; I'm referring mostly to syntactic rules, regexps, file
: operators, and so forth.)

--
Tad McClellan SGML Consulting
Tag And Document Consulting Perl programming
ta...@flash.net

[Shriram Krishnamurthi]

sr...@skorpio3.usask.ca (P. Srinivas) writes:

> Is there any real reason other than egos that prevents all Schemer's
> rally behind Guile?

There are plenty of reasons to not rally behind Guile.

Most of us aren't strictly language implementors. We are also in the
business of being language _designers_. The point of using Scheme is
that we get a superb core language (superb for some purposes, anyway)
upon which we can build our languages of choice. Indeed, every major
Scheme system right now -- Chez, Gambit, Scheme 48, RScheme, MzScheme
and others -- each has some specific agenda items it is trying to get
a handle on.

> a) Everybody can implement her own version for
> testing various ideas. But at the same time all should
> rally for political reasons behind ONE implementation.

Yes, and we would each love nothing more than have everyone else rally
behind our own implementations!

It is not feasible to follow the approach you suggest. It would mean
having to duplicate all the effort on the "local" implementation as
well as the True one. If the two differ stylistically, all your test
programs would have to be written in both (or else how would you
conduct your experiments?). Et cetera. Life is too finite and too
interesting for that.

> c) When some features tested on owns privite scheme and works well,
> he should make sure that feature also works for the ONE TRUE
> Scheme. That way, we do not need to recomond some other Scheme than
> the ONE TRUE SCHEME for the sake of that perticular feature.

Assuming, that is, that the feature will work in that Scheme. For
instance, Scheme 48 has a very well developed module system. However,
when we designed MzScheme's system, we had some philosophical
disagreements with what Scheme 48 was doing. In the end, ours
overlapped for the most part, but not entirely. But now, who's to
tell that our system will even implementable on top of the True one?

> We can choose any existing Scheme for this purpose.

So says you. Apparently, the people doing the actual Scheme
implementation work don't quite agree.

> Is there any reason not to consider GUILE as the possible candidate
> for this?

Perhaps, instead, you could explain why we _should_ consider Guile:
what it offers that the other systems that are out there, actively
being developed, and are the targets of many, many hours of research
figuring out how to put them together right, don't offer. Beyond, of
course, the venerable names of the FSF and RMS.

There are Scheme systems that already offer foreign function
interfaces, macro systems, portability across numerous platforms,
platform-independent GUI libraries, embeddable interpreters, object
systems, module systems, type systems, programming environments,
static debuggers, program steppers ... with solid research behind
them, and often all in the same system. Why wait for Godot?

'shriram

[Paul Prescod]

In article <j7vbu6u...@europa.cs.rice.edu>,

Shriram Krishnamurthi <shr...@europa.cs.rice.edu> wrote:
>There are Scheme systems that already offer foreign function
>interfaces, macro systems, portability across numerous platforms,
>platform-independent GUI libraries, embeddable interpreters, object
>systems, module systems, type systems, programming environments,
>static debuggers, program steppers ... with solid research behind
>them, and often all in the same system. Why wait for Godot?

For the same reason that anybody ever lines up behind any language
standard, formal or informal. They want to be able to develop code
(or whatever) and know that it will work on every implementation of X.
Developing in an environment with the world's most wonderful GUI or
module system is not very useful if I can't use the code on the
Scheme system that I must deploy on.

Paul Prescod

[Russell McManus]

Shriram Krishnamurthi <shr...@europa.cs.rice.edu> writes:

> Yes, and we would each love nothing more than have everyone else rally
> behind our own implementations!

this is your main point, as far as i can tell.

> It is not feasible to follow the approach you suggest. It would mean
> having to duplicate all the effort on the "local" implementation as
> well as the True one.

you are right. work would be required that does not immediately
benefit your research goals. i fail to see how that makes it
infeasible, however.

> > Is there any reason not to consider GUILE as the possible candidate
> > for this?
>
> Perhaps, instead, you could explain why we _should_ consider Guile:
> what it offers that the other systems that are out there, actively
> being developed, and are the targets of many, many hours of research
> figuring out how to put them together right, don't offer. Beyond, of
> course, the venerable names of the FSF and RMS.

i guess that's the point, isn't it. having the FSF involved
brings some unity and direction to scheme implementation.
you think this is a bad thing; i think it is a good thing.

> There are Scheme systems that already offer foreign function
> interfaces, macro systems, portability across numerous platforms,
> platform-independent GUI libraries, embeddable interpreters, object
> systems, module systems, type systems, programming environments,
> static debuggers, program steppers ... with solid research behind
> them, and often all in the same system. Why wait for Godot?

who's waiting? i'm using Guile every day ;^)

you are right that there are several powerful scheme systems already
available. the FSF decided to build on top of one of them, SCM.
would you have the same objections if the FSF decided to build
on top of MzScheme? i think not, from your comment above.

Guile brings the prospect of long-term improvement of a particular
scheme implementation. many people are working on the project, and
their goals are mostly to support practical programming rather than
programming language research. that is why people should consider
Guile.

-russ

[Shriram Krishnamurthi]

papr...@csclub.uwaterloo.ca (Paul Prescod) writes:

> For the same reason that anybody ever lines up behind any language
> standard, formal or informal. They want to be able to develop code
> (or whatever) and know that it will work on every implementation of X.
> Developing in an environment with the world's most wonderful GUI or
> module system is not very useful if I can't use the code on the
> Scheme system that I must deploy on.

But Guile is a specific implementation, not a standard. There is no
reason to believe that Guile's interface will be adopted by all the
other Scheme's. So why is that an incentive?

Are you somehow being forced to deploy on Guile? I don't understand
your comments at all.

'shriram