Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!tekcrl!tekchips!willc
From: willc@tekchips.UUCP
Newsgroups: comp.lang.smalltalk
Subject: Re: Translating Smalltalk
Message-ID: <1325@tekchips.TEK.COM>
Date: Fri, 12-Jun-87 20:37:58 EDT
Article-I.D.: tekchips.1325
Posted: Fri Jun 12 20:37:58 1987
Date-Received: Sat, 13-Jun-87 19:49:49 EDT
References: <245100008@orstcs> <346@parcvax.Xerox.COM>
Reply-To: willc@tekchips.UUCP (Will Clinger)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 53
Keywords: blocks, funargs, late binding
Summary: It's not blocks that make it slow

>In article <245100008@orstcs> budd@orstcs.cs.ORST.EDU (Tim Budd) writes:
>
>The real problem in translating Smalltalk is the notion of Blocks.  Blocks
>must carry with them the context in which they were defined, and there is
>no way to easily simulate this dynamic binding is a staticly scoped
>language like C.  (This is a classic funarg problem).
>
>Which leads one to wonder if a language similar to Smalltalk, but without
>blocks, could be defined...

I don't see the incongruity between Smalltalk blocks and static scope rules.
Scheme is a statically scoped language with two independent features that,
taken together, dominate Smalltalk blocks.  (Anything a Smalltalk block can
do can be done by some simple combination of Scheme's first class procedures
and first class continuations.)  Scheme can also be made to run significantly
faster than Smalltalk.  So why are blocks an excuse for poor performance, and
what has any of this to do with static scoping?

In fairness to Dr Budd, he was answering a question about translation from
Smalltalk into C, which supports neither first class procedures nor first
class continuations.  My point is that the lack of such support should be
distinguished from a language's scope rules, though one can easily argue
that first class procedures (both "upward" and "downward" "funargs")
_require_ static scope rules.

Dr Budd might also point out that blocks are neither well-defined nor defined
well in Smalltalk-80, and he would be right.

In article <346@parcvax.Xerox.COM> susser@parcvax.xerox.com.UUCP (Josh Susser) writes:
>Likewise for static-typed early-bound method lookup. This strategy will
>indeed give you some performance increase, but it destroys the ideologically
>pure polymorphic nature of Smalltalk.

If I could have a purely polymorphic, statically typed, and early bound
language with good performance, I think I could live without the ideology.
Mr Sasser's argument that followed the sentence quoted above assumed that we
must choose between compile-time ("early") binding and run-time binding.
What's wrong with getting the best of both worlds via link-time binding?
Not that there aren't other ways to win, too, but I don't see why you need
run-time binding unless you like to write programs that create and install
new methods on the fly.

I realize that some people like this sort of thing, but I also understand
why run-time binding is an excuse for poor performance.

>Flames gladly accepted.

And gladly offered.  I'm not anti-Smalltalk by any means.  I'm just trying
to look at things objectively, taking the good and leaving the not-so-good.
Peace,

William Clinger
Tektronix Computer Research Lab