NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3257

Internet Message Format | 1992-08-19 | 7.9 KB

Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!uknet!gdt!aber!aberfa!pcg
From: [e-mail] (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Message-ID: <[e-mail]>
Date: 19 Aug 92 16:13:14 GMT
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail] (USENET news service)
Reply-To: [e-mail] (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth
Lines: 168
In-Reply-To: [e-mail]'s message of 18 Aug 92 21: 54:40 GMT
Nntp-Posting-Host: aberdb


On 18 Aug 92 21:54:40 GMT, [e-mail] (Philip Santas) said:

pcg>       a function over a cartesian product a functional over a function
pcg> over one domain in other words, using a Lisp-like notation, whether
pcg> (plus x y) is really: (apply sum-of (list x y)) (apply (incr-by x) y)

santas> In my opinion you do not need to use 'apply in this case.

Strictly speaking a Lisp implementation will kindly do this for me
automatically, but I need to do it manually, because I want to make the
point later on that there is a hidden overload resolutor somewhere, so I
try to expose something of what is normally left implicit. Another
example would be rewriting:

    [obj message: a and: b]

as

  _objc_apply(_objc_resolve("message:and:",obj),a,b);

which is what Objective C (and Smalltalk) syntax really amounts to, for
example. Once this is clear, one starts to wonder why not have

  _objx_apply(_objx_resolve("message:and:",obj,a,b),a,b);

and arrives thus to CLOS style multimethods:

  (clos_apply (clos_resolve (list 'message-and obj a b)) (list obj a b))

In the interest of brevity I have left all such passages implicit, just
hinting at them by showing the first and last one.

santas> The correct is: ((incr-by x) y).

I made a mistake, but the correct version, for my purposes above, is
'(apply (incr-by x) (list y))', and simply because I did not use apply*
instead of apply, as it is less known. But the intent was well clear, I
hope.

santas> Well, all my functions receive one argument, and I think that
santas> most CS scientists and mathematicians agree with this.

pcg> Uhmm. But I was speaking of notation/syntax/interface. And the
pcg> notation I was commenting about does have multiple arguments. Your
pcg> observation applies to functions or maybe to procedures, not to
pcg> their interfaces.  Their interfarces are just syntax, notation used
pcg> to access such procedures or their underlying functions. As such
pcg> the notation used is not terribly important, as long as it is
pcg> clear, convenient, and proper.

santas> I think that here things are getting mixed up.

That's the same feeling I have been getting for a long time...

santas> I really find pontless to start a discussion of what is syntax
santas> and what semantics, when the one derives to the second at
santas> different levels of abstraction.

Then we should drop this discussion altogether, as we are discussing
syntax and its interactions with pragmatics, and with semantics.

But our discussion has title "O.M() versus M(O) notation" it is entirely
proper to analyze the merits of notation, which is
after all what the overload resolution aqgent has to work with.

santas> This is why you missed the following three different cases.

santas> I propose you to consider (and comment) the following three
santas> cases: M (O,...) [ ... ] (O,...) M [ ... ] O M (...)

pcg> This I have already done :-). Prefix, postfix, infix notation

santas> It is not so superficial as you try to show. I use all these
santas> cases with the same syntax.

Superficially :-)

santas> The first case is a function M with argument the tuple (O,...)
santas> (or): M which receives the tuple (O,...), where we have a
santas> function M with a certain type.

OK, prefix notation. I really dislike the use of 'receives', but let's
not dwell on that. M is applied to a composite value.

santas> In the second case we have (O,...) receiving M. It is not only
santas> superficial change,

Yes, it is postfix notation. M is applied to a composite value, which
happens to come before it.  Unless you want, by some strange device,
have the composite value be/evaluate to a functional, and M be its
argument. In that case this is prefix notation.

santas> we have the _type_ of the _tuple_ and we have added M to its
santas> specification.

So, what's new? Nothing strange really here. For example in C++ one
might well write something like 'complex(0,1).sqrt'. In this example
'sqrt' is part of the 'complex' class, and is applied to a tuple of that
class. One may declare sqrt as "belonging" to the global environment, to
a class that represents a parameter list, to a specific class. But the
substance does not vary, given an invocation syntax of procedure
interface and list of arguments, resolve it to applying a particular
procedure body to it.

santas> In the third case we have O receiving M, producing an instance
santas> (function, object, depending to one's tastes) which operates on
santas> the tuple (...)

In other words, by adding parenthesises, in some kind of C++ like
notation, which differs from yours only because of parenthesis,
'(O.M)(...)', something that is actually a fairly common idiom.

It is also syntactically similar to the most common interpretation of
multiple arguments, as per my example above. In ML things are more less
like this by default, and you can declare infix operators without
formality. When you write '1 + 2' in ML this is really the same for
'(+ 1) 2'. It's still infix notation.


I am perplexed as you seem to confuse syntax and semantics (as in the
ordered arguments vs. commutativeness point above), and to be fixated on
the idea that procedures belong to classes, and that the resulting
alternatives in syntax ('a + b' or 'plus(a,b)' or '(a,b).plus' or
'a.plus(b)' or maybe even '(a.plus)(b)' which all really say the same
thing, even if 'plus' happens to be declared, misleadingly, in a
different place in each case) are fundamental and not incidental. Bah.


On 18 Aug 92 22:57:39 GMT, [e-mail] (Philip Santas) said:

doug> Now, how would this new system help clarify the notions of
doug> abstract types (rectangle and square),

pcg> That's a problem for algebrists to solve. What is the optimal
pcg> conceptual orthogonal base for an algebra that encompasses both?
pcg> It's not a problem for the language designer.  The task of the
pcg> latter is to provide clean, general notation to _describe_ such
pcg> things.

santas> Why not to _construct_ such things? What is the advantage of
santas> having something _just_ described? (notice that by construction
santas> I do not mean necessarily implementation, but definition of
santas> structures).

I have never seen a program that was not a description. I tend to split
hairs and to say that programs describe, and computers read this
description and construct what is described by the program, in the way
described by the program.

In a sense it is the age old distinction between programming languages
and algorithmic languages, and between regarding 'print a + b' as a
command or a description of something that should happen.

Some programmers things that programs are long lists of commands to make
a computer do things; some think that they are detailed descriptions
that might be read by different entities (mechanical or not), which
might or not result in things being done. The first speak of programs
having bugs; the latter speak of incorrect descriptions.


I tend to think that programs are descriptions, and the notation used
for such descriptions is not important in itself, as long as it does not
suggest a blinkered vision, like the 'O.M(...)' does.
--
Piercarlo Grandi                   | JNET: [e-mail]
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: [e-mail]