NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/scheme/2045

Internet Message Format | 1992-08-18 | 3.7 KB

Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!agate!anarres.CS.Berkeley.EDU!bh
From: [e-mail] (Brian Harvey)
Newsgroups: comp.lang.scheme
Subject: Re: message passing vs. generic functions
Date: 18 Aug 1992 15:29:39 GMT
Organization: University of California at Berkeley
Lines: 67
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: anarres.cs.berkeley.edu

[There is some nice polite helpful commentary on the next screenful;
don't hit "N" yet...]

===begin flame===

[e-mail] (Barry Margolin) writes:
>This is true.  However, in my experience, automatic delegation like this is
>a dangerous practice, and perhaps it shouldn't be facilitated.
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On the basis of this statement, I move that the CLOS object system be
added to Pascal, and that a non-prescriptive object system be used in
Scheme, which is supposed to be a language for non-anal-fixated people.

===end flame===

Earlier on, I suggested that object dispatch went along with the metaphor
of smart objects better than generic functions, and someone replied along
the lines of "you can still think of the objects as smart if you want."
(Then someone else, not responding to my point, described the two
approaches as "function-centered" and "object-centered" without objection!)

My point, which I think got lost, is that the metaphor that a programming
language actually embodies is NOT irrelevant and NOT trivial.  Yes, you can
think of any mechanism as if it were any other mechanism, once you are
experienced enough to understand all the deep issues, but when you are
learning something, like for example OOP, it makes a *huge* difference
what metaphor is presented *by the language itself*.

What I am saying is that *even if we only had functions of one argument*
[think about adding OOP to pure lambda calculus if that helps :-) ] there
would be an important pedagogic difference between

    (FN OBJ)

and

    (ASK OBJ FN)

even though there would be no significant implementation difference and
either syntax can be written in terms of the other.  There would be no
difference to an experienced OOP programmer, but there would be a big
difference to someone who is just learning how to think about this new
paradigm.  That's what I mean about paying special attention to
educational concerns.

As for functions of more than one argument, I am really not satisfied
with any approach that I know about -- I think the language design
people have more work to do.  I mean, it does feel weird to me to
interpret "3-2" as "ask 3 to subtract 2 from itself" as Smalltalk does,
but with generic functions, I don't want to have to write int-int,
int-float, float-int, float-float, float-rational, etc etc etc.  Maybe
it'd be okay if I wrote int-int, float-float, rational-rational, etc.
and there were some smoothly integrated general raising mechanism.
Does that exist?  If so, I might argue for having BOTH object dispatch
(for OOP) and generic functions (for things like arithmetic) in the
language.  They feel very different to me, even if you can prove that
they're somehow equivalent.

Here's a test case for your rasising mechanism.  I want to implement
Logo-style words in Scheme.  That means that I want an abstract data type
that encompasses symbols, characters, strings, and numbers.  This in turn
means that it should be legal to do arithmetic on strings, provided that the
string turns out to be full of digits and decimal points and so on.

So, I need a raising mechanism that will let me raise "3" to 3,
"3/4" to 3/4, "3.14" to 3.14, and so on.