[comp.lang.smalltalk] declarations vs smalltalk

budd@orstcs.cs.ORST.EDU (06/29/87)

I may be showing my vast ignorance again, but somehow I just don't see how
adding type declarations to Smalltalk helps anything.  It would seem as if
one of the following cases must apply

1. The C philosophy - the user can give declarations, but these are not
checked at run time.  You pass something that doesn't match the
declaration, your program will crash and burn.  Not very nice.

2. The Pascal philososphy - declarations are all checked statically at some
point long before run time.  Either requires declarations everywhere (too
restrictive and limits polymorphism) or requires extensive data flow
analysis (complicated).

3. Hidden code is created to check the conformability of argument types
with declarations prior to method execution.  Why is this any more
efficient than user written code to do the same task?  Allowing the user to
do it would seem to be more flexible.  And what happes when the
declarations are violated?  Does the user have any recourse?

4. Types are considered as part of the message pattern for the purposes of
method lookup.  (This is an extension of object message lookup, where the
types of arguments other than the first may also be important).  This would
seem to be the most general solution, since the only overhead involved is
that of method lookup, not argument checking, and tricks such as caching
can be used to speed up message lookup.  Never the less, the Smalltalk
notion of class is not the most useful concept of type that could be
envisioned, and again this limits polymorphism.

In short, there seems to be an implicit conflict between strong typing, or
typing of any sort, and polymorphism.  Strengthing one limits the other.
Smalltalk has come down strongly on
the side of polymorphism, and even I (Smalltalk heretic than I am) have a
hard time imagining anything similar to Smalltalk that changes this.

I am looking forward to hearing how I am all wrong, and how option number 5
makes all problems go away.

--tim budd (budd@oregon-state)

kempf@hplabsc.UUCP (Jim Kempf) (07/01/87)

An alternative to explicit typing is type inference (inferring the
type from the code). Languages such as ML, which were designed
with type inference in mind, do this very well. The proceedings
of POPL-8 include a paper by Norihisa Suzuki on how to do this in
Smalltalk.
		Jim Kempf			kempf@hplabs.hp.com

delano@calma.UUCP (Pat Delano) (07/01/87)

> 
> In short, there seems to be an implicit conflict between strong typing, or
> typing of any sort, and polymorphism.  Strengthing one limits the other.
> Smalltalk has come down strongly on
> the side of polymorphism, and even I (Smalltalk heretic than I am) have a
> hard time imagining anything similar to Smalltalk that changes this.
> 
> I am looking forward to hearing how I am all wrong, and how option number 5
> makes all problems go away.
> 
> --tim budd (budd@oregon-state)

I highly recommend an article I just finished: "On Understanding Types, Data
Abstraction, and Polymorphism" by Cardelli and Wegner in ACM Computing
Surveys, December 85.  I'm not saying that you are wrong, but I think you
may find the article very interesting.  I thought it was excellent on 
first reading, and I plan to read it again.  Here are a couple of quotes
from the article:

   "Our objective is to understand the notion of type in programming languages,
present a model of typed, polymorphic languages that reflects recent 
research in type theory, and examine the relevance of recent research to
the design of practical programming languages.
   Object-oriented languages provide both a framework and a motivation for
exploring the interaction among the concepts of type, data abstraction,
and polymorphism, since they extend the notion of type to data abstraction
and since type inheritance is an important form of polymorphism."

Toward the end of the article:
   "Smalltalk and LISP Flavors have some idioms that cannot be reproduced
because they are essentially impossible to type check statically. 
...
Generally, the freedom of type-free languages is hard to match, but we
have shown in previous sections that polymorphism can go a long way toward
achieving flexibility, and bounded quantification can extend that flexibility
to inheritance situations."

-- 
---
Patrick DeLano               {sun,ucbvax}!calma!delano
GE Calma Company
525 Sycamore Drive
Milpitas, CA 95035           telephone 408 434-4429
---

kens@hpldola.HP.COM (Ken Shrum) (07/01/87)

>In short, there seems to be an implicit conflict between strong typing, or
>typing of any sort, and polymorphism.  Strengthing one limits the other.
>Smalltalk has come down strongly on
>the side of polymorphism, and even I (Smalltalk heretic than I am) have a
>hard time imagining anything similar to Smalltalk that changes this.
>
>I am looking forward to hearing how I am all wrong, and how option number 5
>makes all problems go away.

>--tim budd (budd@oregon-state)

Smalltalk combines protocol definitions and method implementations into
a class.  Let us consider having a class Protocol whose instances
represent protocols.  Presumably the instances support operations to
join/intersect a set of protocols, etc.  Each class may have an
instance of Protocol associated with it, describing the protocol
presented by instances at runtime.

    5.  Type declarations state that 'the protocol of this object is a
        superset of this protocol'.

This information could be used only for type checking or it could also
be used at runtime.

This solution only solves the syntax problem, but supports polymorphism
as it is presently supported by Smalltalk.

	Ken Shrum
	hplabs!hpldola!kens

bmc@argus.UUCP (Bob Czech) (07/03/87)

 In article <245100009@orstcs>, budd@orstcs.cs.ORST.EDU writes:
 > 
 > 4. Types are considered as part of the message pattern for the purposes of
 > method lookup.  (This is an extension of object message lookup, where the
 > types of arguments other than the first may also be important).  This would
 > seem to be the most general solution, since the only overhead involved is
 > that of method lookup, not argument checking, and tricks such as caching
 > can be used to speed up message lookup.  Never the less, the Smalltalk
 > notion of class is not the most useful concept of type that could be
 > envisioned, and again this limits polymorphism.
 > 

	I see it as a way of cutting out the run time overhead of a message
lookup with typing of variables.  In this way the exact method is bound to the
variable during compile time.  There is no need for a message lookup at runtime
because you have the class of the recevier already specified.

	Are there any versions of smalltalk around that use early binding?

anders@suadb.UUCP (Anders Bj|rnerstedt) (07/04/87)

In article <orstcs.245100009> budd@orstcs.cs.ORST.EDU writes:

>
>2. The Pascal philososphy - declarations are all checked statically at some
>point long before run time.  Either requires declarations everywhere (too
>restrictive and limits polymorphism) or requires extensive data flow
>analysis (complicated).

Declarations (which  may be checked statically) certainly limit
polymorphism, that is the whole point of typing. However declarations
do not exclude polymorphism, as long as the actual (run-time) value
is of a type satisfying the formal declaration, e.g. the value is 
of the same type or a   subtype of the  declaration, then the
expression is type correct. 


>3. Hidden code is created to check the conformability of argument types
>with declarations prior to method execution.  Why is this any more
>efficient than user written code to do the same task?  Allowing the user to
>do it would seem to be more flexible.  And what happes when the
>declarations are violated?  Does the user have any recourse?

Why use high level  languages at all ? Compiler generated  run-time
checks are less errorprone, code easier to maintain.

>In short, there seems to be an implicit conflict between strong typing, or
>typing of any sort, and polymorphism.  Strengthing one limits the other.

I agree that there is a trade-of involved.
Typing can be seen as the limitation of polymorphism 
(though not the elimination of polymorphism). This is at the
expense of flexibility but for the benefit of security. Depending
on the size of a software project or the number of individual 
programmers involved this will be more or less important.

  ---------------------

  Anders Bjornerstedt
  Department of Information Processing & Computer Science
  University of Stockholm
  S-106 91  Stockholm
  Sweden


UUCP:{seismo,mcvax,cernvax,diku,ircam,prlb2,tut,ukc}!enea!suadb!anders
ARPA: enea!suadb!anders@seismo.arpa

 
 

anders@suadb.UUCP (Anders Bj|rnerstedt) (07/06/87)

In article <argus.943> bmc@argus.UUCP (Bob Czech) writes:
>
> In article <245100009@orstcs>, budd@orstcs.cs.ORST.EDU writes:
> > 
> > 4. Types are considered as part of the message pattern for the purposes of
> > method lookup.  (This is an extension of object message lookup, where the
> > types of arguments other than the first may also be important).  This would
> > seem to be the most general solution, since the only overhead involved is
> > that of method lookup, not argument checking, and tricks such as caching
> > can be used to speed up message lookup.  Never the less, the Smalltalk
> > notion of class is not the most useful concept of type that could be
> > envisioned, and again this limits polymorphism.
> > 
>
>	I see it as a way of cutting out the run time overhead of a message
>lookup with typing of variables.  In this way the exact method is bound to the
>variable during compile time.  There is no need for a message lookup at runtime
>because you have the class of the recevier already specified.

Typing may be used by the compiler to make early binding (binding to
the concrete type you might say) in order to gain efficiency. However
you then exclude polymorphism. You may still want typing AND late 
binding (binding to the abstract type you might say) in order
to have both flexibility (polymorphism) and security, i.e. the
object is guaranteed to support a certain protocol.

  ---------------------

  Anders Bjornerstedt
  Department of Information Processing & Computer Science
  University of Stockholm
  S-106 91  Stockholm
  Sweden


UUCP:{seismo,mcvax,cernvax,diku,ircam,prlb2,tut,ukc}!enea!suadb!anders
ARPA: enea!suadb!anders@seismo.arpa

 
 

johna@cognos.uucp (John C. Anderson) (07/06/87)

In article <245100009@orstcs> budd@orstcs.cs.ORST.EDU writes:
>      [... deleted ...]
>In short, there seems to be an implicit conflict between strong typing, or
>typing of any sort, and polymorphism.  Strengthing one limits the other.
>Smalltalk has come down strongly on
>the side of polymorphism, and even I (Smalltalk heretic than I am) have a
>hard time imagining anything similar to Smalltalk that changes this.
>
>I am looking forward to hearing how I am all wrong, and how option number 5
>makes all problems go away.
>

Well, I dont think there is an option 5 which will "make all problems
go away",  however,  there is an option 4.78 which goes a long way in 
the right direction.  A detailed reply would be too lengthy for inclusion
here, but I'll give a brief indication of the flavour of the
solution,  and some pointers to the literature which you can chase
down if you're interested.

To start with,  I have to (mildly) disagree with your statement that
polymophism and strong typing are in conflict.  It is true that strong
typing as exhibited by, eg Pascal, is in conflict with polymorphism.
However,  the real problem here is not strong typing,  but that the
type theory used in Pascal is extremely primitive.  For example,  to 
describe the (polymorphic) concept "pair of t" where t is any type is
quite impossible in Pascal.  You can describe "pair of int", or "pair of real",
etc (as a record or two element array),  but you can never describe the
general concept.  However,  there are languages in existence today which
have a much more powerful notion of type.  These languages are quite capable
of mixing strong typing with polymorphsim and generally can handle concepts
like "pair of t" quite easily and efficiently. 

One such language which is quite well known is ML.  
See "A Proposal for Standard ML" by R. Milner, in the Proceedings of the
Symposium on LISP and Functional Programming Aug/84.  

There is an excellent article in Computing Surveys, December 1985, 
"On Understanding Types,  Data Abstraction,  and Polymorphism", by Cardelli 
and Wegner.  This article covers the key issues,  and is quite readable.  
If nothing else,  I suggest this article.  C & W demonstrate the combination
of polymorphism and strong typing,  and in addition show how the inheritance
mechanism of Smalltalk provides for certain restricted forms of polymorphism.

> [ ... repeated from above ]     
>I have a hard time imagining anything similar to Smalltalk that changes this.

Please have a look at "An Exemplar Based Smalltalk", Lalonde, Thomas, and 
Pugh, in the Proceedings of OOPSLA'86 (Object-Oriented Programming Systems,
Languages and Applications).  
-- 
John Anderson, Cognos Incorporated, 3755 Riverside Drive,
Ottawa, Ontario, CANADA  K1G 3N3
(613) 738-1440	   decvax!utzoo!dciem!nrcaer!cognos!johna

johnson@uiucdcsp.UUCP (07/06/87)

Suzuki's type inference system works only with a subset of Smalltalk.
In particular, it does not work with parameterized classes such as
Collections.

Cardelli and Wegner's paper is must reading for anybody doing research
in type systems or in object-oriented programming.  Unfortunately, it
is not as applicable to Smalltalk as one might think, since ad-hoc 
polymorphism is important in Smalltalk, in my opinion more important
than inclusion polymorphism.  (Actually, I might have gotten that
last kind of polymorphism wrong---it's the kind that Cardelli and Wegner
spend most of their time on.)  However, I learned a lot from reading
their paper and it has greatly influenced my work.

daniels@cae780.TEK.COM (Scott Daniels) (07/06/87)

In article <245100009@orstcs> budd@orstcs.cs.ORST.EDU writes:
>I may be showing my vast ignorance again, but somehow I just don't see how
>adding type declarations to Smalltalk helps anything.  It would seem as if
>one of the following cases must apply
>
>1. C - user gives declarations, not checked at run time.
>2. Pascal - declarations checked statically 
>3. Hidden code checks conformability of argument types with declarations 
>   Why is this any more efficient than user written code to do the same task?
>4. Types are part of the message pattern (Generics)
>
>option number 5?

In response to your comment on (3): How about the value this provides to the
reader of the code?  Given the language guaranteed a certain type was provided,
the code might read much more easily.  This would mean treating the declaration
as a kind of "ASSERT".

As for a (5), how about:
    The type provides advice to the compiler to build code which works more
    efficiently if the given class of object is provided.  A simple check
    and branched code, with slow compact code for the abnormal case, and 
    fast code for the provided declaration.  Thus this might be analogous
    to the "register" declaration in C (and you might also give compile-
    time warnings if messages that the declared class was unable to handle 
    were sent to the objects so declared).

FROM:   Scott Daniels, Tektronix CAE
	5302 Betsy Ross Drive, Santa Clara, CA  95054
UUCP:   tektronix!teklds!cae780!daniels
	{ihnp4, decvax!decwrl}!amdcad!cae780!daniels 
        {nsc, hplabs, resonex, qubix, leadsv}!cae780!daniels