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

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

Path: sparky!uunet!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: 18 Aug 92 14:54:34 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: 147
In-Reply-To: [e-mail]'s message of 17 Aug 92 22: 26:21 GMT
Nntp-Posting-Host: aberdb

On 17 Aug 92 22:26:21 GMT, [e-mail] (Philip Santas) said:
santas> (Piercarlo Grandi) writes:

pcg> [ ... ] it makes a lot of difference which notation
pcg> is used to describe operations on a value because the notation
pcg> strongly influences thought processes and actually constrains them
pcg> (cfr. Dijkstra on BASIC), and that in particular the 'O.M(...)'
pcg> notation by making 'O' visually special suggests that overloading
pcg> should happen only on the first argument

santas> Although I agree partly with this I have a major dissagreement:
santas> you seem to argue that functions receive more than one
santas> arguments.

Ah no, ah no. I have not committed myself on this! (even if a lot of
people would like to commit me! :->). Here I would make the point that
there is some difference between 'function' and 'procedure'. In the case
of 'function' there is some disagreement, dutifully reflected in the
syntax of ML 'procedures' for example, as to whether a function over two
domains is really:

    a function over a cartesian product
    a functional over a function over one domain

in other words, using a Lisp-like notation, whether (plus x y) is really:

    (apply sum-of (list x y))
    (apply (incr-by x) y)

I tend to prefer the latter, also because I like Indian sauces :->, as
it becomes much easier to do things like partial application.

But here we are speaking of 'functions', or maybe of procedures, not of
procedure interfaces.

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

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

santas> Since I do not like the O.M(...) syntax and your functions with
santas> _many_ arguments,

So, I am not really talking about functions/procedures with many
arguments; I am just talking as their interfaces. Then the compiler, on
recognizing an interfaces like

    1 + 2

will either build a record '{1,2}' and pass it to 'operator+', as is
done in most traditional languages (where the activation frame of a
procedure is really a record), or will generate a functional and apply
it, as is customarily done in ML.

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

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

pcg> As far as syntaxes go, everybody have their own personal tastes;
pcg> some prefer infix, some prefix, some postfix, some expression based
pcg> languages, some imperative one.

And let me add: some prefer keyword based, so infix/prefix/postfix does
not matter.

Frankly what I really care about is not the notation itself, but the
fact that the overload resolution agent (aka binder, dispatcher,
messager, etc.) is given an N-uple

    (O,M,A,B,C,...)

which may or may not be ordered (even if usually the A,B,C,... are
positional and thus ordered), and from this it has to find a compatible
implementation/body/etc. to apply. I quite like the prefix lisp notation

    (M O A B C ...)

that more clearly reflects this, and is in some way just a shorthand for

    (apply (resolve M O A B C ...) A B C ...)

And indeed that is the way the Lisp systems reads it.

santas> Can you describe or outline a general purpose method for
santas> automatic subsetting?

That is a fairly ambitious goal, I am afraid, in its full generality.
Church has to say something about it. But, if I am right in thinking
that what you really mean is 'a way where, given a more general set of
interface or specification or implementation components, a more
specialized set can be derived' then a less than general and highly
useful _practical_ solution is possible.

By coupling an interpreter to a compiler, and maybe also adding in an
inference engine, to result in a symbolic reduction compiler. There is
some research being done in this, and I wish it were a more popular
endeavour. A large number of useful cases can be handled even with
fairly simplistic technology.

santas> Concerning specification: I think that subclasses should inherit
santas> it as a whole, otherwise there is no point for making a class
santas> subclass of another.

Maybe, but probably you are still thinking in terms of inheritance, as
your use of the seven letter verb indicates. There is no reason to
believe that if one has a general algebra over interfaces specifications
and implementations, derivation need only happen by subsetting. For
example one could derive a more general class from a less general one,
usually by adding (or substituting) interface and implementation
components, and the specification of the resulting class might well be
weaker.

For example, once one has written interface and specification and
implementation components for fixed length queues, one might want to
reuse (be it ever praised!) them, or parts of them, to build a
dynamically resizable queue class. In this case the derived
specification will not have the assertion that 'items <= maxitems'.

santas> The problem with interface is that current OOPLs do not use
santas> functors for classes, ie. functions which construct new classes
santas> out of older ones.

On this we are thoroughly agreed, actually it is my main point. It is
this that I have in mind when I say that languages should have notation
to cover full general algebras over interfaces, implementations,
specifications; those 'functors' of yours are the operators of such
algebras.

Even if most current languages do have some 'functors' over 'types',
i.e.  type constructors, e.g. 'array', 'struct', 'pointer to', 'union',
etc., as most current OO languages do have some 'functors' over
'classes', e.g. the ':' of C++, or 'inherits' of Eiffel.

But yes, they lack the necessary flexibility and generality.



--
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]