Newsgroups: comp.lang.python,comp.lang.misc,comp.lang.scheme,comp.lang.perl,comp.lang.tcl,comp.object
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!spool.mu.edu!caen!hearst.acc.Virginia.EDU!murdoch!usenet
From: "Steven D. Majewski" <sdm7g@Virginia.EDU>
Subject: Re: "magic" instance variables (was: Comparing syntaxes...)
In-Reply-To: <1994Nov8.151744.18300@wdl.loral.com>
X-Sender: sdm7g@elvis.med.Virginia.EDU
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.A32.3.90.941108123328.15750D-100000@elvis.med.Virginia.EDU>
To: Scott McLoughlin <smcl@sytex.com>, Mark A Biggar <mab@wdl1.wdl.loral.com>
Sender: usenet@murdoch.acc.Virginia.EDU
Organization: University of Virginia
Mime-Version: 1.0
Date: Tue, 8 Nov 1994 18:12:27 GMT
Lines: 97
Xref: glinda.oz.cs.cmu.edu comp.lang.python:2494 comp.lang.misc:18912 comp.lang.scheme:11057 comp.lang.perl:38323 comp.lang.tcl:21546 comp.object:22428

On Tue, 8 Nov 1994, Scott McLoughlin wrote:
 
>         Hmmmm.... For lack of a better phrase, this is a 
> "bunch of hooey", IMHO.  There is no "abstracting out the
> presence or absence of procedure calls" -- they are
> either there or they aren't there.

Scheme and Lisp abstract things another way: everything looks 
like a function call, even if some are actually special forms
or macros that don't behave quite like a function. Which one
they are is not apparent from the language syntax - you have 
to know the name. 

C macros are another "function abstraction" that may or may
not actually call a function. Of course, I agree with the 
schemers who say that unhygienic macros are dangerous. 


>         And of course, you can't _tell_ what the hell is
> going on anymore.  What looks like constant time access to
> a chunk of memory ends up being some ridiculous file/io
> procedure, or side effects causing bugs can't easily be
> chased down, etc. etc.

Of course inline declarations are a sort of hygienic macro for 
C, and some compilers and abstract even more out of you code, 
so I don't think there is a reliable mapping from syntax to 
performance expectations. 


>         Thank goodness GEL will be based on a real language --
> Scheme. Let sanity prevail.
> 

The above are all examples in the other direction: abstracting 
the function call out of the function abstraction/syntax. If 
GEL is also going to have a procedural, algebraic syntax on
top of the scheme S-expressions, as announced, then I assume *it*
will also introduce those same sort of abstractions: e.g. 
    "a[i]"   ==becomes==>  "( vector-ref a i )"
i.e. what looks like array references are actually function calls.
( However, maybe your scheme compiler will abstract the function 
  calls back out again in some cases, and turn function calls into
  variable references. ) 


>         As for Smalltalk's syntax, which presumably is the
> source of these nonsensical "OO" vs. procedural "perspective"
> ramblings -- Smalltalk's syntax is remarkably clear and
> mirror's its semantics quite nicely. Updating a "slot" in an
> object _is_ a procedure call when you want to achieve this
> from outside the scope of the object's slots. 
 

I didn't mean to suggest that something about Smalltalk's syntax 
was the source. But if you think about the problem in an *OBJECT*
oriented way - what does changing a windows background attribute
from "blue" to "green" **DO** ?  For many with an OO perspective,
it's natural to say that an object is a holder of some state, and
the statement: 
        window.background = "red" 
is a change of state in the object 'window', and therefore, it's 
not unnatural to expect that change of state to manifest itself 
visually. To say that the *internal* state is "red" while the 
visible external state remains "blue" is what seems unnatural! 


On Tue, 8 Nov 1994, Mark A Biggar also added:

> 
> The use of tie in perl is really no different that the ability to user define
> member slot accessors in CLOS.  The default accessors functions just read/write
> the object members, but you can redefine them to do any arbitrary functionality.
> 


Now the fact that these abstraction mechanisms are available in Python,
Scheme, Common-Lisp, etc. does not require you to use them. All "Real
Languages" provide these sorts of mechanisms, though. And 
there are clearly different opinions about where and when it is 
appropriate to use them. 

In fact, Tommy Burnette, who was part of the GUI discussion I referred
to still maintains this model ( button.foreground = "red" ) is *dead* 
wrong for his GUI API in Python. <http://server.cs.virginia.edu/~tnb2d/IT/IT.html>.

He strongly agrees with you -- in Python. I disagree. 

So I don't believe there is any grounds for making this a *language*
issue: Real languages like Python, Scheme, etc. that promote abstraction,
versus ... versus WHAT ? 


-- Steve Majewski       (804-982-0831)      <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center        Charlottesville,VA 22908 --

