STOP ME before I CODE in C again!!! 
Author Message
 STOP ME before I CODE in C again!!!

                          A Schemer's Lament
                                  or
How I Learned to Stop Worrying and Code in Assembler^H^H^H^H^H^H^H^H^H^H C.
                                  or
            Scheme's 10 Step Program for World Domination.

I. The Introduction.

I've been coding in Lisp for over 10 years now, and Scheme for the
last 3.  At this point Scheme is my favorite language.  It's my
language of choice for any task at hand.

However, I'm becoming more and more disillusioned and depressed when I
consider the prospects for Scheme in the programming world at large.
I'm slowly coming to the conclusion that Lisp and Scheme will always
be fringe languages - that the computer world will continue to be
{*filter*}led by high level assemblers like C and low level objective
monstrosities like C++.  Here's my reasoning - I hope someone can
prove me wrong.

II. The Analysis.

The biggest problem with scheme is that one cannot make an application
written in scheme widely available.  This prevents scheme from
enjoying the explosive growth that C, perl, and Tcl/Tk have benefited
from - the growth that a language enjoys due to lots of people using
the internet to distribute the source code for small but useful
applications.

Sure you can distribute the source code, but what is this going to get
you?  The vast majority of computers have neither scheme interpreters
nor scheme compilers installed.  Sure, if they really want the
application, they'll go and track down a scheme interpreter and
install it and run your app.  But, this is only if they've decided
that they *really* want your app, and they must decide this without
having seen it first.  This is a far cry from downloading a .tar.gz
file, unpacking and running make.  People will only do it for large,
extremely attractive, well advertised applications.

Even if scheme interpreters and compilers *were* installed on every
Unix box on the face of the earth, what good would it do?  Unless I'm
distributing some character based toy app which only talks to the
outside world by reading and writing files, then my app will be
interpreter dependent.  I *cannot* write portable code.

Sure, I could write R4RS compatible code, which will thus run in the
majority of interpreters, but this doesn't give me much - I can read
and write files, I can't append to a file, I can maybe read a
character from the keyboard without getting stuck in a wait state (if
char-ready? isn't broken in this particular interpreter), I can
interact with the user in a line based query/response fashion, and I
can compute stuff.  I can't use select, I can't do any networking, I
can't use X, I can't use curses, I can't fork, I can't run
subprocesses, ...  Basically, I can't write a modern application, or
even a menu driven one!

Chucking R4RS, one *can* write a modern application.  Every version of
scheme has its own (often limited) way of talking to the OS, all
mutually incompatible.  Of course, compatibility also sucks in the
C/Unix world, but a) not on such a grand scale, and b) at least
someone's cataloged the differences - I can use gnu configure, or
xmkmf if necessary.  In the scheme world, I'm lucky to have
compatibility between different *versions* of an interpreter or
compiler.

To some extent, I blame the R4RS committee here.  They go and spec a
language, debating whether or not to include esoteric features such as
dynamic-wind and unwind-protect, but they don't spec an OS interface.
Of course, this isn't really part of the language, and so technically
speaking, shouldn't be in the language spec, but the R4RS committee is
the only committee with the respect necessary to issue an interface
spec - a foreign function interface, or a C library interface, or a
posix interface.  What would have become of C had the C world proposed
the language, but left out the standard C library?  The answer is that
it would be a fringe language like scheme.

Ok, so suppose I chuck portability, chuck R4RS compatibility, I write
for 1 interpreter, 1 compiler, and I don't distribute my source code.
I could still distribute binaries...

Of course, this would greatly shrink availability - I don't have
access to the 60 different flavors of Unix machine in common use, so I
can't provide binaries for them.  Even if I did, this would be a major
burden for me, compared to just uploading cool_app.tar.gz to afew ftp
sites.

None the less, I guess this is possible.  If I want the program (begin
(display "Hello, world") (newline)) to take up 500k of disk space,
allocate 4meg at startup, take 15 seconds to run, and be 10 times
slower than a similar app coded in C, then yes, I can use scheme->C or
bigloo or something to compile and link it, and then distribute the
binary.

This might change once Stalin is ready - I wrote a simple prime number
sieve in scheme, compiled it under scheme->C, bigloo, and stalin.  The
scheme->C version and the Bigloo version were about 300k, the Stalin
version was about 30k.  The scheme->C version took about 3 seconds to
generate all the primes <=100000, the Bigloo version about 1.7
seconds, and the stalin version .53 seconds - comparable to
/usr/games/primes - a C version with lots of tricks to make it fast.

But, I want to distribute applications *now*!

Where does all this this leave scheme apps?  It means that scheme apps
will mostly be developed for personal use by programmers who prefer
programming in scheme to programming in other languages.  I can write
apps in scheme, and even put the code into scheme repositories, but
the apps won't get wide usage.  If I want to do anything other than
write toy applications, I'll have to write to a particular interpreter
so as to get the needed OS & GUI access.

This indicates to me that scheme will never have widespread usage and
acceptance.  Because of this lack of portability, usage will be
restricted to personal use, and isolated proprietary use.  It will
never have the kind of growth that C and perl have exhibited because
the scheme source code for applications can only be distributed
amongst the users of a particular interpreter - developers working
with one particular interpreter, not the masses.

III. The Solutions.

How could this be changed?

The very barest minimum needed is a scheme standard library
specification, and scheme interpreters which support it.  The standard
library spec must include a simple and straight forward foreign
function interface.  Everything else is basically syntactic sugar.

This is the minimum necessary to allow people to build serious
applications in portable scheme code.  The portability would be
guaranteed by the scheme programmer restricting himself to a portable
class of foreign functions.  One would be able to write scheme
programs which are portable to posix compatible platforms, for
example.  At this point, a C foreign function interface would be
sufficient.

Once one has direct access from scheme to the underlying OS, people
can easily build their own abstracted schemish interfaces to it.  A
schemish posix interface, for example, or a generalized schemish OS
interface.  The latter is more of a research project, and so is
unlikely to make it into a standard, but the former shouldn't be too
hard for people to hammer out and agree on, and should give a cleaner
posix interface than straight use of the foreign function interface.

In any case, with this bare minimum, at least people would be able to
release portable scheme libraries for access to various OS services -
a scheme sockets library, or networking library, or WWW library.
We'd finally have a portable foundation to work from.

Given this bare minimum, at least scheme would have a chance against
perl.  It would have the capabilities to compete with powerful
scripting languages.

(Of course, scsh is scheme's answer to perl.  However, because it's big
and non-standard, I can't distribute neat little scsh scripts the same
way people distribute nice little perl scripts.  Once the FFI is
standardized, it'd be nice to see some of scsh's OS interfaces to be
standardized into a scheme library, perhaps added to SLIB, and then
scsh might start to become a serious competitor.)

Given this one small addition - a standardized FFI, all the scheme
programmers out there will be able to start distributing there
wonderful applications.  Since scheme is presumably so efficient to
program in, there should be a flood of wonderful apps which are head
and shoulders above anything written in C or perl.  This will increase
demand for scheme interpreters to run all these wonderful apps, and
any FFI compliant interpreter will do.  There'll be an explosion in
the number of machines with scheme interpreters, building on the
number of applications, ...  At least, that's the theory.

Thus, it's my opinion that a standardized FFI would at least enable
scheme to compete in the scripting world with perl, and later with sh,
and even Tcl.

As far as I can see, the reason for Tcl's popularity is not its small
size (it's *big*).  It's not it's speed (it's *slow*).  It's not its
elegance (no need for parenthetical comments here).  Aside from the Tk
GUI (a *big* aside), it's the ease of adding C code to the
interpreter.  Or, to think of it in the other direction, it's the ease
of using it to add a scripting language to a body of C routines.

With Tcl, there's no need to ever write a complicated main() again -
one can just develop afew specialized C routines, link it into the Tcl
interpreter, and start using them.  Write some circuit analysis and
layout routines, and use them immediately.

With scheme+standardized simple FFI, the above would be just as easy
using any scheme interpreter.

To finish off the other interpreters/scripting languages, we need
scheme interpreters with particular properties.  They must be *small*,
*fast*, and load libraries *quickly*.  This is where we lose alot of
the currently available interpreters.  Perl, bash, wish, scm, and snow
(the no-Tk version of STk) all take up about the same amount of disk
space (actually, scm ...

read more »



Mon, 14 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

... lots of stuff ...

HJS> Even if scheme interpreters and compilers *were* installed on every
HJS> Unix box on the face of the earth, what good would it do?  Unless I'm
HJS> distributing some character based toy app which only talks to the
HJS> outside world by reading and writing files, then my app will be
HJS> interpreter dependent.  I *cannot* write portable code.

You might come to the same conclusion when reading the ANSI C specs.

HJS> Sure, I could write R4RS compatible code, which will thus run in the
HJS> majority of interpreters, but this doesn't give me much - I can read
HJS> and write files, I can't append to a file, I can maybe read a
HJS> character from the keyboard without getting stuck in a wait state (if
HJS> char-ready? isn't broken in this particular interpreter), I can
HJS> interact with the user in a line based query/response fashion, and I
HJS> can compute stuff.  I can't use select, I can't do any networking, I
HJS> can't use X, I can't use curses, I can't fork, I can't run
HJS> subprocesses, ...  Basically, I can't write a modern application, or
HJS> even a menu driven one!

But the interfaces to all of these packages are not specificed by the
language designers, either.  They're specified by the library
providers.  You'd better spend your time talking to library providers
to implement Scheme bindings.  Some of that has been done, eg. by the
STk people or the scsh folks.

... more stuff

HJS> (Of course, scsh is scheme's answer to perl.  However, because it's big
HJS> and non-standard, I can't distribute neat little scsh scripts the same
HJS> way people distribute nice little perl scripts.  Once the FFI is
HJS> standardized, it'd be nice to see some of scsh's OS interfaces to be
HJS> standardized into a scheme library, perhaps added to SLIB, and then
HJS> scsh might start to become a serious competitor.)

Huh?  In what way is Perl smaller than scsh?  Last time I looked, Perl
was piggishly big, a much worse memory hog than scsh, and Perl scripts
still run dog-slow compared to scsh scripts.  It was even worse with
Perl 4, and that didn't keep people from using it.

Cheers =8-} Mike



Mon, 14 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

Well, the GNU extension language, Guile, does have all that you asked for.
It's derivative from SCM, with well-defined FFI, and interfaces to
curses, regexp, Tcl/Tk, and OpenGL (!!!) already done. I did significant
ammount of work using hybrid C/SCM approach (planning the move to Guile
soonish) and I think that SCM is the easiest thing to interface to C
that I've ever seen (and I looked into Perl, Python, SIOD, several
flavors of Common Lisp, and tcl).

        Miro



Mon, 14 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!
Perhaps one step forward is the Scheme HTTP server of Olin
Shivers, for wich I discovered the existance today (check the
news). In the LISP world there are a couple of LISP-HTTP
servers. another, radical solution, is a Java-based Scheme
compiler (check the other news from Alex Milowsky). The two
are quite different, though: one adopts the mobile code idea
(Java), the other the distributed collaborating agents.
Whithin my limited resources, I'll try to follow both.  


Mon, 14 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

Quote:

>Well, the GNU extension language, Guile, does have all that you asked for.

Except for the fast startup, maybe.  Whatever kind of machine hjstein was,
it's obviously faster than mine.  Even so:

# time perl -e 'print 1+1,"\n"'
2
0.118s real  0.060s user  0.060s system  100% perl -e 'print 1+1,"\n"'

# time guile -e "(begin (display (+ 1 1)) (newline))"
2
1.023s real  0.900s user  0.100s system  97% guile -e "(begin (display (+ 1 1)) (newline))"

I ran both of these several times, to give the disk cache a chance.  The
output shown is for the last invocation of each.

Quote:
>It's derivative from SCM, with well-defined FFI, and interfaces to
>curses, regexp, Tcl/Tk, and OpenGL (!!!) already done. I did significant

It could do with a well-_documented_ FFI, too.  In fact, it could do with
rather more documentation than it currently has, full stop.

(Yes, I know this is being worked on.  I'm looking forward to seeing it)

Quote:
>ammount of work using hybrid C/SCM approach (planning the move to Guile
>soonish) and I think that SCM is the easiest thing to interface to C
>that I've ever seen (and I looked into Perl, Python, SIOD, several
>flavors of Common Lisp, and tcl).

Daniel
--

 ``Consistency is the last refuge of the unimaginative''      --- Oscar Wilde



Mon, 14 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!
HJS is generally correct about the problems associated with
using scheme for real-world programs.  R4RS defines the core
of the language, but leaves too much of the OS interface out.
SLIB doesn't help much here, either.  

A scheme standard library is the way to go; people could quit
worrying about the incompatibilities between different implementations.
The best starting point here is probably scsh.

As for the FFI issue, I agree with HJS that simplicity of
embedding is important.  I have tried the Guile, SIOD, libscheme,
Elk, and STk FFIs.  I was discouraged from trying to extend Scsh
by the documentation.

In my experience, the libscheme interface is the simplest, and is
the only one that equals the simplicity of tcl.  Maybe it could
serve as the starting point for a standard.  There are only
two prototypes for extensions;  one for primitives and one for
syntax.

A nearly complete libscheme extension:

#include "scheme.h"

static Scheme_Object *
my_nifty_proc(int argc, Scheme_Object *argv[]) {
    int i = some_c_stuff();
    return(scheme_make_integer(i));

Quote:
}

void init_my_ext(Scheme_Env *env) {
    scheme_add_global("my-nifty-proc",  
                      scheme_make_prim(my_nifty_proc),  
                      env);

Quote:
}

There are some limitations to libscheme that would discourage one from
using it as a stand-alone interpreter.  The problems include
rudimentary error handling, no dynamic loading, no code compilation.
Memory management is clean thanks to the Boehm convervative gc (fewer
headaches than Guile or Elk, for instance).

    H> With Tcl, there's no need to ever write a complicated main()
    H> again - one can just develop afew specialized C routines, link
    H> it into the Tcl interpreter, and start using them.  Write some
    H> circuit analysis and layout routines, and use them immediately.

I use libscheme as you describe above, with even better results
(I get to use scheme).

-russ

p.s. kudos to brad benson for libscheme.



Tue, 15 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

        .... lots of good stuff deleted ....

I think this brings up two separate issues.

   1) Scheme as a general purpose programming language ala C, C++

   2) Scheme as an extension language ala Tcl, perl

Since number 1 is an uphill battle I'll concentrate on number 2.
I think the only major problem with making Scheme an exceptable
extension language is the syntax (Wait! don't shoot!). This is
not a criticism of Scheme, but to be realistic, to many people,
the syntax seems unnatural.  Another problem which is easier to
solve is that Scheme is a language, whereas Tcl, Perl etc.
are all language/implementations.  This makes code written
for them infinitely more portable.

Now that you all think I'm a Scheme hater I'll go on. I've been
working on a Scheme interpreter for the past 3+ years. Our goal
was to make Scheme into an acceptable extension language for
building technology CAD applications.  We originally started out
with ELK.

Initially we received a lot of resistance from users who objected
to the Lisp syntax.  We took the usual solution of implementing a
second reader that provided an alternate syntax. Our syntax is
very C like but also allows for some command style coding and
maintains access to all Scheme features.

Our second task was to improve the FFI. The biggest problem with
the ELK FFI is the ease at which you can create insidious fatal
bugs with a minor programming error. We decided to switch to a
non-moving reference counting garbage collector.  This enabled
us to design an interface that was portable yet in almost all
cases let users ignore the implications of GC.

Our next major hang-up was debugging. Those damned users always
wanted to know on what line and in what file their error occurred,
so we had to add debugging information.

Portability is still somewhat of a hang-up. Since Scheme supports
continuations, possibly the best solution is to avoid implementing
the Scheme stack with the implementation language stack. (I know,
other Schmeme implementations don't do this).

Of course some of these changes have an adverse effect on
performance. But in an extension language I think this is a secondary
consideration.  Take Tcl, it's bull dog slow (I have a Pharaoh hound
(Greyhound cousin) so I can't just say "dog slow") but still gets
the job done.

Documentation is of the utmost importance for promoting any
extension language. You can buy Ousterhout's book on Tcl covering
the language, FFI, Tk Toolkit etc.  Implementation specific Scheme
documentation is somewhat scanty.

To summarize I think what Scheme needs is a standard interpreter that
has these qualities.

PORTABILITY

   Implement Scheme in standard C with minimal #ifdefs only used to
   support special features such as dynamic loading.

EASY TO USE FFI

   Requires minimal dealings with the GC. Comes with an automated C/C++
   function/class wrapper generator.

STANDARD LIBRARIES

   GUI interfaces, math libraries etc. just to grab people's attention.

GOOD DOCUMENTATION

   'nuff said.

GOOD ALTERNATE SYNTAX

   I have found once you hook people into the system it's easier to get
   them to try the standard Scheme syntax.

GOOD DEBUGGING

   ARRRRG! just give me a line number.

DECENT PERFORMANCE

   without sacrificing any of the above.

With such an implementation I think Scheme could build up a critical
mass of users possibly enough force issue number 1.  People are not
going to use Scheme because of some haughty notion of language elegance.
It has to provide them with a real advantage.

                             .  .  .  .  .  .  .  .  .  . __---____
                            /| /| /| /| /| /| /| /| /| /|/ / ./  ./~~-.
                   ________/_|/_|/_|/_|/_|/_|/_|/_|/ |/ / / /  ./  _-~ ~-_
        ____----~~~\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ ~~~~~----__/ _-~   __---.

   O`*_             |\ \ \ \ Ram "Polypterus" Firestone\ \ \ \ \*__________--*.
    `*_~~~--       /\__----_\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \~__          .'
       ~~--___    /$$,      ~\ \ \ \ \ \ \ \ _--_\ \ \ \.-----~__ ~~---_  _-
              ~~~-.$$$       |~~~~~~~~~~~~~~~-_  ~.~~~~~-_  ~-_ ~~-----~~~
                   ~$'       |                 ~--_$*     ~--__*
                     ~-_    /
                        ~~~~

 Intel Corporation M/S RN2-40, 2200 Mission College Blvd Santa Clara CA, 95092



Tue, 15 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

How often do you write Hello world programs anyway?

You should take a look at guile.

Aldy



Wed, 16 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

Quote:

> In my experience, the libscheme interface is the simplest, and is
> the only one that equals the simplicity of tcl.  Maybe it could
> serve as the starting point for a standard.

You may want to take a look at libmzscheme, which is produced by
compiling MzScheme (http://www.cs.rice.edu/CS/PLT/packages/mzscheme/).
This was originally based on libscheme, but has many more goodies now,
such as real (if slow) call/cc and tail calls.

Quote:
> There are some limitations to libscheme that would discourage one from
> using it as a stand-alone interpreter.  The problems include
> rudimentary error handling, no dynamic loading, no code compilation.

MzScheme gives you each of these in some respect.  We have noticed the
speed of MzScheme, in most cases, to be better than that of most other
free Scheme systems, though not as good as a native-code compiling
system like Chez.

Quote:
> p.s. kudos to brad benson for libscheme.

Indeed.  To Brent Benson too. (-:

'shriram



Wed, 16 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!


Quote:
[Mr. Preprocessor]) writes:


   ... lots of stuff ...

   HJS> Even if scheme interpreters and compilers *were* installed on every
   HJS> Unix box on the face of the earth, what good would it do?  Unless I'm
   HJS> distributing some character based toy app which only talks to the
   HJS> outside world by reading and writing files, then my app will be
   HJS> interpreter dependent.  I *cannot* write portable code.

   You might come to the same conclusion when reading the ANSI C specs.

Well, we have in The C programming Language, by Kernighan and Richie
(2nd edition), Appendix B: Standard Library:

   This appendix is a summary of the library defined by the ANSI
   standard.  The standard library is not part of the C language proper,
   but an environment that supports standard C will provide the function
   declarations and type and macro definitions of this library...

This includes stdio.h (fopen, ..., fscanf, fprintf, fseek, ...),
stdlib.h (system, getenv, qsort), signal.h, time.h, ...

I guess this isn't really that much, but it does have afew useful
things that can't be gotten in a standard way from scheme
implementations (system, getenv, fseek, signals, time fcns ...) and
which cannot be written from within R4RS.

But, one can still write to posix, and get reasonally portable code
that's reasonably full functioned.

   HJS> Sure, I could write R4RS compatible code, which will thus run in the
   HJS> majority of interpreters, but this doesn't give me much - I can read
   HJS> and write files, I can't append to a file, I can maybe read a
   HJS> character from the keyboard without getting stuck in a wait state (if
   HJS> char-ready? isn't broken in this particular interpreter), I can
   HJS> interact with the user in a line based query/response fashion, and I
   HJS> can compute stuff.  I can't use select, I can't do any networking, I
   HJS> can't use X, I can't use curses, I can't fork, I can't run
   HJS> subprocesses, ...  Basically, I can't write a modern application, or
   HJS> even a menu driven one!

   But the interfaces to all of these packages are not specificed by the
   language designers, either.  They're specified by the library
   providers.  You'd better spend your time talking to library providers
   to implement Scheme bindings.  Some of that has been done, eg. by the
   STk people or the scsh folks.

Right.  The point is that some versions of scheme have some interfaces
into some common libraries, but there's no standard way to go into a
library.  If there was such a standard way (i.e. - a standard FFI),
then scheme programs could interface to these common libraries and the
programs would be portable across scheme interpreters.  The current
situation requires the end user to have a half dozen or more scheme
interpreters on his machine if he wants full access to the source code

more details.

   ... more stuff

   HJS> (Of course, scsh is scheme's answer to perl.  However, because it's big
   HJS> and non-standard, I can't distribute neat little scsh scripts the same
   HJS> way people distribute nice little perl scripts.  Once the FFI is
   HJS> standardized, it'd be nice to see some of scsh's OS interfaces to be
   HJS> standardized into a scheme library, perhaps added to SLIB, and then
   HJS> scsh might start to become a serious competitor.)

   Huh?  In what way is Perl smaller than scsh?  Last time I looked, Perl
   was piggishly big, a much worse memory hog than scsh, and Perl scripts
   still run dog-slow compared to scsh scripts.  It was even worse with
   Perl 4, and that didn't keep people from using it.

Well, maybe I did something wrong, but I installed scsh on my machine
(486dx33, Linux, 16mb ram), and scsh takes something like 5 seconds to
start up, scsh.image is over 2mb, and the interpreter has a footprint
of 9.9mb (2.5mb resident set size).

And yes, I agree that in the best of all possible worlds, we'd have
standard scheme bindings for standard libraries which were more scheme
suitable and abstract than making direct calls to socket, bind,
select, etc.

But in any case, that's all more of an aside than the main point,
namely that without some sort of standard FFI (either stock or through
SLIB) enabling most schemes to have the same interface to libc,
libX11, libtk, libdbm, ..., then the burden on the distribution of
scheme applications is too great to get wide usage.

--
Dr. Harvey J. Stein
Berger Financial Research



Thu, 17 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

Quote:
(Miroslav Silovic) writes:

   Well, the GNU extension language, Guile, does have all that you asked for.
   It's derivative from SCM, with well-defined FFI, and interfaces to
   curses, regexp, Tcl/Tk, and OpenGL (!!!) already done. I did significant
   ammount of work using hybrid C/SCM approach (planning the move to Guile
   soonish) and I think that SCM is the easiest thing to interface to C
   that I've ever seen (and I looked into Perl, Python, SIOD, several
   flavors of Common Lisp, and tcl).

Well, ok, I can build an scm interpreter with added C calls in it.  In
fact, I just did it last night to test the speed of the code that
hobbit produces...  And I agree it isn't too hard to do.

But how does this make scheme applications portable and available in a
way approaching perl scripts or C code?

When people distribute Tcl/Tk apps, they expect libtcl.a and libtk.a
to be in standard places.  They supply some additional C code and a
Makefile for compiling it and linking it with libtcl.a and libtk.a.
So, my application just needs to include my own code.

First of all, with scm, the install procedure is doesn't lead to such
a clean installation at the user's side of things.  To distribute my
application in a reasonably fool-proof fashion, I'd have to distribute
it along with a copy of scm (unless I rely on the user having
installed scm with some sort of dld support).  Now, multiply this by
everyone on the net doing the same.

But, I'll grant you this.  Let's assume that scm gets cleaned up a bit,
and I can merely send out my mods & link against libscm.a & get a
working modified scm interpreter (a la those Tcl/Tk wish hackers).

So, what do we end up with on the net?  We have scm apps, STk apps,
scheme->C apps, bigloo apps, Elk apps, guile apps, and apps based on
whatever other particular scheme interpreter I've forgotten to
mention.

For the end user, this requires he have installed a half dozen scheme
systems!  Or, he restricts himself to one interpreter, one sixth of
the apps, and the scheme world has to be 6 times bigger than the
Tcl/Tk world to give the user a comparable selection of applications.
Or, each application distributes itself with a copy of one of the
above interpreters, making each little application large, and long to
install.

The point is that without a standardized library that everyone can
write to, the application set will be fractured for the end user, thus
limiting availability.

But, I'm going to relax my previous position.  I had been thinking
that we need a standardized FFI so that people can distribute serious
applications and the user need only install one version of scheme.

It would suffice if most schemes have FFIs (which can load object code
or pull in procedures from shared libraries into a running
interpreter), and if SLIB has a standardized interface into all these
FFIs.  Then, at least, any scheme program written to R4RS+SLIB
standard FFI+C lib XYZ would be portable to any scheme
interpreter+SLIB+C lib XYZ.

So, if not a common standardized FFI amongst all schemes, at least a
common interface from SLIB.

--
Dr. Harvey J. Stein
Berger Financial Research



Thu, 17 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

Quote:
> another, radical solution, is a Java-based Scheme
> compiler (check the other news from Alex Milowsky)

I'm interested in hearing more about Java-VM-based scheme
efforts. Please, anybody  having results/plans in this area
drop a word.

-Dmitry



Fri, 18 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

Quote:
>So, what do we end up with on the net?  We have scm apps, STk apps,
>scheme->C apps, bigloo apps, Elk apps, guile apps, and apps based on
>whatever other particular scheme interpreter I've forgotten to
>mention.
>For the end user, this requires he have installed a half dozen scheme
>systems!  Or, he restricts himself to one interpreter, one sixth of
>the apps, and the scheme world has to be 6 times bigger than the
>Tcl/Tk world to give the user a comparable selection of applications.
>Or, each application distributes itself with a copy of one of the
>above interpreters, making each little application large, and long to
>install.

why is it that tcl, perl, python do not have many variants? imho, these
scripting languages do not suffer from this problem because each has been
created, championed, and nutured by a single leader- respectively, ousterhout,
wall and rossum. the many contributors help port, extend or make the
language widespread, rather than write yet another version.            
scheme seems to suffer the lack of strong leadership, everyone wants
to roll their own, everyone wants to make it their own perfect little
language.  


Fri, 18 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!

Quote:
(Charles Kung) writes:


 >
 > >So, what do we end up with on the net?  We have scm apps, STk apps,
 > >scheme->C apps, bigloo apps, Elk apps, guile apps, and apps based on
 > >whatever other particular scheme interpreter I've forgotten to
 > >mention.
 >
 > >For the end user, this requires he have installed a half dozen scheme
 > >systems!  Or, he restricts himself to one interpreter, one sixth of
 > >the apps, and the scheme world has to be 6 times bigger than the
 > >Tcl/Tk world to give the user a comparable selection of applications.
 > >Or, each application distributes itself with a copy of one of the
 > >above interpreters, making each little application large, and long to
 > >install.
 >
 > why is it that tcl, perl, python do not have many variants? imho,
 > these scripting languages do not suffer from this problem because
 > each has been created, championed, and nutured by a single leader-
 > respectively, ousterhout, wall and rossum. the many contributors
 > help port, extend or make the language widespread, rather than
 > write yet another version.  scheme seems to suffer the lack of
 > strong leadership, everyone wants to roll their own, everyone wants
 > to make it their own perfect little language.

Why is it that C doesn't have many variants?  It's because there's
basically a standard OS interface.  You have the standard C library,
the standard Unix interfaces (SVR4 & BSD), the POSIX standard, etc.
Not to imply there's one complete an anointed standard OS interface,
but it started with 2 basic unix flavors, which over time split and
segmented and evolved into various standards.  In any case, the
differences in flavors and subflavors were big enough to give porting
headaches, but not so large as to completely prevent the source code
from being portable.

It seems that portability across implementations can be gotten 2 ways
Either develop a language with *no* standard, but freely distribute an
implementation, and add features that people need/demand, or develop a
language, and include both a standard and a standard OS interface.

Unfortunately what happened with Scheme is that a middle ground was
taken - a language standard was developed, but no standard library was
included.  This caused lots of people to write R4RS compatible
interpreters, but they had to add features to enable the interpreters
to support more than CS101 exercises.

It's unlikely we'll be able to spontaneously generate a strong
champion of the scheme language to shepard in standard OS interfaces,
so I think we'll have to settle for the scheme implementers
standardizing on a foreign function interface.  Or, maybe some bright
undergrad, or masters or PhD student will make a thesis out of
designing a simple FFI, adding it to all the currently available
scheme interpreters, and submitting the code back to the scheme
maintainers to be folded into their distributions.

 -----------------------------------------------------------------------------
Dr. Harvey J. Stein          Stein's law: Every comp.lang.Scheme thread
Berger Financial Research    devolves to either "my Scheme is better than

 -----------------------------------------------------------------------------



Sat, 19 Sep 1998 03:00:00 GMT  
 STOP ME before I CODE in C again!!!



 >
 >      .... lots of good stuff deleted ....
 >
 > I think this brings up two separate issues.
 >
 >    1) Scheme as a general purpose programming language ala C, C++
 >
 >    2) Scheme as an extension language ala Tcl, perl
 >
 >
 > Since number 1 is an uphill battle I'll concentrate on number 2.
 > I think the only major problem with making Scheme an exceptable
 > extension language is the syntax (Wait! don't shoot!). This is
 > not a criticism of Scheme, but to be realistic, to many people,
 > the syntax seems unnatural.  Another problem which is easier to
 > solve is that Scheme is a language, whereas Tcl, Perl etc.
 > are all language/implementations.  This makes code written
 > for them infinitely more portable.

In the words of one of the vultures at the end of Disney's Jungle
Book,

      OOOOOOHHHHHHHH!!!!  DON'T START THAT AGAIN!!!!!!!!!!

I'm not talking at this point about trying to convert Scheme into
an extension language which the masses would accept.  Converting the
world to Scheme is a different issue.  I'm just concerned at this
point with giving applications written in Scheme equal availability to
those written in C, C++, Tcl and Perl.  In other words, I just don't
want the availability of any application to suffer because it's been
written in Scheme.

The reason that C & C++ come up is that they are widespread compiled
languages.  The reason that Tcl and Perl come up is that they're
widespread scripting languages.

The question I'm trying to answer is "What is the *minimum*
*necessary* to be able to give wide availability to applications
written in Scheme?"  The observation is that Scheme apps can't be made
widely available because of the dependence on a particular
interpreter's OS interface.

Of course, ideally we'd have a standard Scheme library which provides
a Scheme interface to all the standard libraries sitting on your
typical unix workstation, maybe with something like STk's interface to
Tk, scsh's wonderful interface to process manipulation, etc.

However, this will be a *big* thing that will be long in the making.

I think that the *minimum* necessary (which, incidentally, could serve
as a foundation for the above standard Scheme library) is a standard
foreign function interface.

For example, I'd like to be able to load C code from libraries
by doing something like:

(ff-load-C-definitions '("<sys/time.h>" "<sys/types.h>" "<unistd.h>"))
(ff-load-C-procedures '("select" "time")
                      '("/usr/lib/libc.sa" "/usr/lib/libm.sa"))

ff-load-C-definitions could be defined in terms of ff-C-define and
ff-C-deftype, which could be used instead in the cases that one
doesn't want to parse all the .h files each time the program is run
(For example, the user would run make when installing the application,
which would do something like ff-load-C-definitions except would save
the results as calls to ff-load-C-definitions and ff-C-define, instead
of adding them to the environment.  Maybe you'd give a list of the
particular C procedures that you need, and it'd just snarf out the
necessary definitions (the function prototypes and necessary type
definitions).

After doing this, I'd like to be able to call the C library time
function by doing something like:

(ff-C-time ff-C-NULL)

If we could do something like this in the same way in all Scheme
interpreters, then we could write serious applications in Scheme, and
these apps would be portable between interpreters.  I think this is
the minimum that we need to at least give the *possibility* that
Scheme applications could have the same wide availability as C, Tcl
and Perl applications.

Furthermore, if we could do this, then I could, if necessary, also
include some C code (code without restriction) with my app, which
would get compiled at application installation time and loaded into
the interpreter at run time.

   <snip>
 > To summarize I think what Scheme needs is a standard interpreter that
 > has these qualities.
   <snip>

This is exactly what I want to *avoid*.  For once, let's *not*
degenerate into a discussion of which particular Scheme implementation
is best, smallest, fastest, gives the best features, ...  Let's also
*not* degenerate into a discussion of what changes/additions Scheme
needs to {*filter*}le the C/Perl/Python/Tcl/Forth/Awk/Rexx/MIX/<insert
obscure computer language here> world.

All I'd like is to see that applications written in Scheme don't
suffer from a lack of availability.  All I wan't is to be able to take
my Scheme code, stick it on ftp.cool.Scheme.apps.org, and have anyone
with any Scheme interpreter be able to run them.  I shouldn't have
to write to the Scheme du jour, they shouldn't have to have the Scheme
du jour installed, and I shouldn't have to distribute my code along
with the Scheme du jour.

And, as I've been saying, I think that the minimum necessary for this
would be a standard FFI for Scheme.

I'd like the discussion to go into:
   -Examples of good, well documented FFIs which could be incorporated
    into most Scheme interpreters.
   -Discussions of what a good FFI should look like, and how it
    could be implemented.
   -Problems with scheme interpreters calling arbitrary C code (and
    hopefully, solutions).
   -Problems with automatic generation of foreign procedure specs.
   -Refutations of my arguments - maybe show that less (or something
    else small) is all that's needed to make scheme apps widely
    available, or that there already is some scheme OS interface
    that's been ported to lots of Scheme interpreters, or ...

One problem which comes to mind is that C procedures might modify
arguments, and this crucial piece of data isn't in the .h header.  How
can this problem be handled in general?  Make all C procedures
special and destructive?  Have the user add annotations to mark
procedure arguments as destructive?

 -----------------------------------------------------------------------------
Dr. Harvey J. Stein          Stein's law: Every comp.lang.Scheme thread
Berger Financial Research    devolves to either "my Scheme is better than

 -----------------------------------------------------------------------------



Sat, 19 Sep 1998 03:00:00 GMT  
 
 [ 33 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. assume cs:code,ds:code

2. Scheme vs ML again and again and again and again

3. Scheme vs ML again and again and again and again

4. to CS: or not to CS: in F-PC assembler

5. Initializing DX to Code Segment(CS) Memory Address...?!?

6. Initializing DX to Code Segment(CS) Memory Address…?!?

7. Stop small hand-coded process

8. Return code from PL/I STOP

9. How to stop echoing to stdout while assigning values in code

10. Ctrl-C to stop C++ code in python

11. STOP doesn't stop this procedure [TECHNICAL]

12. stop, I repeat, stop replying to nudds you godam dumbfuks

 

 
Powered by phpBB® Forum Software