Denis Washington scripsit:

> GUIs are not inherently unportable. In fact, if there were something
> like a portable FFI (which, e.g., Common Lisp has with CFFI),

No support on ABCL, though.  Scheme has two JVM implementations (Kawa
and SISC) and one on the CLR (IronScheme).  Consequently, I added "C
FFI", "Java FFI", and "CLR FFI" to the list of possible packages to
support in WG2-Scheme.  The WG decided not to make any of them a WG2
work item; they were postponed to a hypothetical future WG rather than
rejected outright.

(You can see the other packages in this position at
http://trac.sacrideo.us/wg/wiki/ReassignedDocket , and the accepted
work items at http://trac.sacrideo.us/wg/wiki/StandardDocket and
http://trac.sacrideo.us/wg/wiki/ConsentDocket . Proposals are at the
badly named http://trac.sacrideo.us/wg/wiki/RevoteDocket .)

> To be honest, Scheme is one of the few languages I know in which you
> have to tie yourself so intimately with one single implementation to
> write any serious applications. I mean, how often do you write, say,
> a C++ implementation that only works with the Wacom C++ compiler?

Well, you don't, of course (reading "application" for "implementation"
in your last sentence).  Programming languages can be divided into three
groups based on their implementation strategies:

A) Multiple competing implementations, relatively small standard
libraries, many third-party libraries available.  C, C++, Cobol,
Fortran, JavaScript use strategy A.

B) A single dominant implementation which comes with a fairly
large library which everybody uses; typically there is no formal
standardization.  Substantial third-party libraries may or may not
be available.  Ada, Java, Perl, Python, Ruby use strategy B.  So do
most DSLs, research languages, and personal toys.  Haskell used to be
strategy C but is now B due to the increasing dominance of GHC.

C) Multiple implementations, relatively small standard libraries, each
implementation comes with lots of libraries.  Substantial third-party
librarys may or may not be available.  The Lisp languages use strategy
C; so do Forth, ML, and the Posix shell.  Common Lisp and the shell have
fairly large standard libraries (for the shell, it's the Posix utilities
that constitute the library); R5RS and even R6RS have fairly small
ones.  The relative sizes in the Lisp world will be R5RS < WG1-Scheme <
R6RS < CL < WG2-Scheme, but the standard libraries of WG2-Scheme will
be optional for conformance rather than mandatory, so CL may still be
larger in effect.

In a strategy C language, an implementation is more than just an
implementation; it's a community, or even a movement.  Strategy A
languages don't draw this sort of loyalty for the most part; decisions
between implementations are based only on cost, or else technical
criteria such as speed, space, compilation speed, or availability in a
particular environment.  Strategy B languages have only one community
per language, with a few splinter groups; that's what makes them such
juggernauts today.

But to write your code for Chicken or Racket or Chibi involves more
than a cold-blooded decision about the advantages of these particular
environments.  Technical factors may control the choice in some
circumstances.  But where they don't, people end up deciding based on
essentially tribal factors, the same that make people fanatically loyal
to vi or Emacs (or, in my case, "ex").

That's not necessarily a bad thing.  But it would be a good thing,
unqualified, if some of the library code available to Chicken
programmers was also directly available, without fuss, to Racket or
even Chibi programmers.  Essentially everything new in WG1-Scheme is in
pursuit of that goal one way or another.  Likewise, the packages in WG2
are meant to help at a higher level with that interoperability goal.

--
So they play that [tune] on                     John Cowan
their fascist banjos, eh?                       cowan@ccil.org
        --Great-Souled Sam                      http://www.ccil.org/~cowan

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports