Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!godot.cc.duq.edu!newsgate.duke.edu!news.mathworks.com!newsfeed.internetmci.com!in3.uu.net!news.biu.ac.il!discus.technion.ac.il!news!qobi
From: qobi@eesun.technion.ac.il (Jeffrey Mark Siskind)
Subject: Re: Scheme or ML? (was Re: multiple values)
Reply-To: Qobi@EE.Technion.AC.IL
Organization: Technion, Israel Institute of Technology
Date: Mon, 12 Aug 1996 07:13:17 GMT
Message-ID: <QOBI.96Aug12101317@eesun.technion.ac.il>
In-Reply-To: Robert Harper's message of Mon, 05 Aug 1996 12:07:31 -0400
X-Nntp-Posting-Host: eesun.technion.ac.il
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>
	<31FE3046.3E93@cs.cmu.edu> <4u38ip$b63@garbo.cs.indiana.edu>
	<32061C42.67A1@cs.cmu.edu>
Sender: news@discus.technion.ac.il (News system)
Lines: 111

This purpose of this message is to ask clarification questions, not to
flame. I find that I do not understand the argument that the ML folks are
raising and I want to try to understand.

   All Scheme programs *do* transliterate directly into ML.  It is a very
   simple matter to write a parser that translates Scheme code into ML
   code.  Every Scheme program will have type sv, where sv is a recursive
   datatype of the form

	   datatype sv = Nil | Cons of sv * sv | Func of sv list -> sv | ...

   The translation will make all tag checking and tag creation explicit,
   precisely as in a Scheme compiler.  For example,

	   fun car (Cons (a, _)) = a
	     | car _ = raise RuntimeTypeError

   and so forth.  It is entirely faithful to the Scheme semantics, and can
   be optimized precisely the same way as a Scheme compiler might.

One can implement the Scheme object system in almost any programming language.
Whether or not it's implementation supports static type inference. That
includes Algol-68, PL/I, C, and ML. And one can transliterate Scheme to such
languages by a local transformation. This is well known. But I don't
understand why this makes these languages strictly more expressive than Scheme
or for that matter why ML would have this property when say Algol-68, PL/I, or
C would not.

   As long as you stick with writing Scheme code, you'll never know the
   difference.  As soon as you try to step outside the strictures of Scheme
   (as you certainly will), you will notice the overhead of all the tag
   manipulations, and move instead to programming with many types, rather
   than one type.

By `the overhead of all the tag manipulations' do you mean programmar overhead
or computational overhead? If you mean programmar overhead than I really don't
understand because I have been writing Lisp/Scheme code for 15 years, defining
my own data types for all of that period, and have never once written explicit
tag checking. If you mean computational overhead than that is a different
story. Yes, my Lisp/Scheme implementations do run-time checking (most of the
time). But that is a language implementation issue, not a language design
issue. One can imagine implementation of ML that do run-time checking (like
SML/NJ did at one point) and one can imagine implemetations of Scheme that do
static inference (like Stalin). Now if by `overhead' you mean computational
overhead then you must be refering to language implementations, not the
languages themselves. And I could understand an argument of the form TIL or
SML/NJ are run programs faster than Chez. But it appears that you are not
making such an argument. Or you could be making an argument that the design of
ML inherently allows for better compilers than Scheme. I could understand such
an argument. And it may very well be true. But I have yet to see such an
argument formulated in a well-expressed fashion. So please clarify this issue
for me. I really want to understand.

   In truth few people actually believe in the doctrine of
   one true type.  As soon as you question this article of faith, you
   quickly realize that you prefer to have a much more refined type system
   as exemplified by ML.  And you realize that all this tag hacking is
   utterly pointless.

I really don't understand what your notion of `type' is that would make ML
types defined by ML datatype constructs distinct types whereas Common Lisp
types defined by DEFSTRUCTs would all constitute a single type. Please clarify
this for me.

   Tag checking is not type checking.  (Sorry to quibble about terminology,
   but we have to make distinctions if we are to get anywhere.)

I agree that without a common terminology we are not going to get
anywhere. But I don't understand the difference that you are making. Please
explain it to me.

   Tags
   cannot possibly supplant static types.  For example, you cannot achieve
   proper data abstraction in Scheme precisely because data abstraction is
   a matter of static typing, and no amount of tag hacking can replace it.

Please give me an example of data abstraction that cannot be performed in
Scheme but can be performed in ML. It will help me understand the point that
you are trying to make.

   Besides the fact that there are only a fixed set of tags in Scheme,
   there is a further weakness of tag-based pseudo-replacements for a type
   system: enforcement *must* be computable. This is a very serious
   limitation not shared by static typing disciplines.  Even if we stay
   within decidable conditions, the run-time overheads of repeated tag
   checks on values (not to mention the very association of tags with
   values) are preposterous.

Can you please elaborate on the above points. I don't understand what you mean.

   In anticipation of the obvious remark, let me say also that languages
   with the ability to generate "new" tags at run-time are ALSO static type
   disciplines, and perfectly transliteratable into ML along precisely the
   same lines.

Again, I don't understand the above remark. It appears that everything is a
static type disipline. If not, than what is not a static type discipline?
Please give me an example. It will help me understand the point that you are
trying to make.

   Summary: ML is strictly more expressive than Scheme because Scheme can
   be faithfully transliterated into ML, whereas the reverse is impossible.

Please give me an example of an ML program that cannot be transliterated into
Scheme. It will help me understand the point that
you are trying to make.

    Jeff (home page http://tochna.technion.ac.il/~qobi)
-- 

    Jeff (home page http://tochna.technion.ac.il/~qobi)
