Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!scramble.lm.com!news.math.psu.edu!news.cse.psu.edu!uwm.edu!news-res.gsl.net!news.gsl.net!news.mathworks.com!newsfeed.internetmci.com!news.sprintlink.net!news-stk-200.sprintlink.net!news.sprintlink.net!new-news.sprintlink.net!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!newsfeed.ed.ac.uk!dcs.ed.ac.uk!cnews
From: Juliusz Chroboczek <jec@dcs.ed.ac.uk>
Subject: Re: Scheme or ML? (was Re: multiple values)
In-Reply-To: "Ray S. Dillinger"'s message of Sat, 27 Jul 1996 10:06:18 -0700
X-Nntp-Posting-Host: calvay.dcs.ed.ac.uk
Message-ID: <dh3ivb8tf3e.fsf@calvay.dcs.ed.ac.uk>
To: "Ray S. Dillinger" <bear@sonic.net>
Sender: jec@calvay.dcs.ed.ac.uk
Organization: University of Edinburgh, Department of Computer Science
X-Newsreader: Gnus v5.1
References: <qijn30oeaoq.fsf@lambda.ai.mit.edu> <4t8ag1$rns@ix.cs.uoregon.edu>
	<31F841D5.7638@sonic.net>
	<cc001636-2607960950310001@ip95.van-nuys.ca.interramp.com>
	<31FA4C8A.101C@sonic.net>
Date: Sun, 28 Jul 1996 18:20:05 GMT
Lines: 107

Hello.

Disclaimer: I am a Scheme and Lisp lover.  I simply believe that ML is
a good language (although I don't like the environments I know), and
that bashing ML from a Scheme perspective is as unproductive as
bashing Scheme or Lisp from an ML (or C++) perspective.

In article <31FA4C8A.101C@sonic.net>,
  Ray S. Dillinger <bear@sonic.net> argued against ML:

RSD> My impression of statically typed languages 
RSD> is that you have to actually touch each and every routine you want to 
RSD> work with a new type -- The better the system, the lighter the touch, 
RSD> but you have to touch them *all*.

Nope.  That's the work of the compiler.  You have to *recompile* them
all, but not actually change the source code.  Or, in simple cases,
you can use polymorphism, and not even recompile any code.

An example of polymorphism: you have some type T, an ordering
predicate lessp:T*T->bool and a function 
sort:'a list*('a*'a->bool)->'a list (where 'a is the ML notation for a
type variable).  Then, if some code does:

  sort l lessp

then this code will not need to be changed if you change the
representation of T.  You only need to make sure that lessp is
consistent with T (and the compiler will often barf when it is not the
case).

You don't always want to be polymorphic.  Suppose that you have a
complicated function munge:T->T which never accesses directly a value
of type T except through a well defined (albeit large) set of
low-level functions (such as lessp).  Then, if you change the
representation of T, you will only need to change the low level
functions.  Of course, unlike in Scheme, all of the code will need to
be recompiled (that's one of the reasons why I program in Lisp).

The module system (both in SML and recent versions of Caml) will help
you make sure that this encapsulation is respected (as far as I know,
there is no way to guarantee in Scheme that there are no hidden
dependencies on a particular representation).  It will also allow you
to write the code in such a manner that you will not need to recompile
it, but only relink it (to reapply the functors, in ML parlance).
Would a module system for Scheme give you the same guarantees?  (I
think it could be done, but not without introducing types; I seem to
remember that there was a proposal for such a beast once (Blume?)).

>> SML does not produce a different implementation of a polymorphic routine
>> on a per-type basis.

RSD> Well then what's the point of you having to specify types in the first 
RSD> place? And how does it get any speed edge if its polymorphic routines 
RSD> are in fact untyped?

See the example above.  munge is not polymorphic, but it could easily
be recompiled when the types changed.  On the other hand, sort is
polymorphic, but the type system guaranteed that applying the
functinal argument to a couple of members of the list is safe, so that
no runtime checks were needed (it is not clear to me whether the
compiler needs to tag the types anyway).

(RSD than goes on to refute the myth that Dynamic typing must be slow;
I absolutely agree with him)

>> You can't statically type "eval", but other than that, I don't believe
>> [that dynamic typing is any more powerful than static typing].

Dynamic typing allows you to write many programs that can't be written
in a static type system.  However, usually there is another way to
express the same behaviour.

RSD> I have a function called "compose."  it takes a list of functions as 
RSD> arguments and returns a function which is their composition [the
RSD> functions are of arbitrary types].

This seems impossible to do directly in the SML type algebra.
However, if the types of the arguments/results are in a small finite
set, than you can take a union of the types used (by the way, that's a
simple example of monadic style; it would be clumsy to write in SML,
but quite natural in Haskell).  (By the way, have you had a look at
Objective Caml yet?  It's somewhere on www.inria.fr.)

>> <snip> the real reason dynamically-typed languages
>> have an advantage over statically-typed languages is because there is no
>> one right type system.

That's true from a practical point of view, but wrong from a
theoretical one.  The One Right Type System for functional systems
without first class control operators is second order intuitionistic
predicate calculus.

My opinion is that dynamic type systems provide a worse developing
environment.  It is more difficult to debug your code (what's the type
of that print statement you introduced for debugging?), you can't
change a function on the fly without recompiling all the functions
that use it, it is next to impossible to have a `format' function
(although the original Caml had `printf', hacked in by raping the type
system in an unsafe way), and I've never seen a good debugger for ML
(sorry, Jerome, if you're reading this).  But systems such as
ML/Haskell are in their infancy.  Lisp, on the other hand, has a
mature implementation technology.

This message does not represent the opinions of anyone, not even mine.

                                        J. Chroboczek
