Typed Systems, Type Inference, etc

Diego Gomez Deck DiegoGomezDeck at ConsultAr.com
Sun Jul 21 11:05:58 UTC 2002


Hi David,

>Just for consideration, here is what the actual point behavior
>declaration looks like in SmallScript (abridged information, various
>methods elided).

Thanks for your really helpful email, I'll give you my point of view.

>Class name: PointObject
>     fields: virtual property x,y;
>{
>     "" Constructor(s)
>     Function [<::(<>,<>)>
>     x: x y: y
>         ^new() x: x; y: y
>     ].
>
>     "" Instance method(s)
>     Method [<'cloning'>
>     + v
>          ^class()(x + v, y + v)
>     ]
>     Method [<'cloning'>
>     + <PointObject> pt
>          ^class()(x + pt.x, y + pt.y)
>     ]
>}
>
>Where the alternate #::(<>,<>) class-method name, allows writing code as
>follows:
>
>Eval [
>     "" SmallScript form
>     |x := 10, y := 12|
>     stdout cr << Point32(x,y).
>]
>
>Eval [
>     "classic form"
>     |x y| x := 10. y := 12.
>     Transcript cr; nextPutAll: (Point32 x: x y: y).
>]
>
>Both of the above, will compile and behave correctly in SmallScript --
>the use of <Transcript> instead of <stdout> requires a reference to the
>"ANSI" library (module).
>
><PointObject> happens to be defined as a base-class (which is indicated
>by the suffix "...Object"). We could just as easily have defined it as a
>mixin with the same virtual field declarations.
>==============
>Translating the PointObject declarations to a more "classic Smalltalk"
>format would read as:
>
>Class name: PointObject
>     fields: virtual property x,y;
>{
>     "" Constructor(s)
>     Function ["removed the alternate method name"
>     x: x y: y
>         "explicitly reference <self> in #new"
>         ^(self new) x: x; y: y
>     ].
>
>     "" Instance method(s)
>     Method ["removed the 'cloning' category-tag annotation"
>     + v
>          ^(self class new)
>              x: (x + v) y: (y + v)
>     ]
>     Method [
>     + <PointObject> pt
>          ^(self class new)
>              x: (x + pt.x) y: (y + pt.y)
>     ]
>}
>
>NOTE: Both forms shown here (original form, classic Smalltalk form) will
>compile and produce the exact same code and behavior. With the noted
>comments where I removed some extra annotations and replaced them with
>comments.

In ST you can write code like that:

Point>>+ anObject
     ^ anObject addToPoint: self.

Point>>addToPoint: aPoint
     ^ (self x + aPoint x) @ (self y + aPoint y)

Number>>addToPoint: aPoint
     ^ (self + aPoint x) @ (self + aPoint y)

String>>addToPoint: aPoint
     ^ (self asNumber + aPoint x) @ (self asNumber + aPoint y)

My point is: The gain don't pay the complexity added to the language.

>Given the above definitions, we can then create a variety of point
>classes.
>
>Class name: Point extends: PointObject
>     fields: auto x,y.
>Class name: Point32 extends: PointObject
>     fields: auto struct int32 x,y.
>Class name: Point16 extends: PointObject
>     fields: auto struct int16 x,y.
>Class name: PointFloat32 extends: PointObject
>     fields: auto struct Float32 x,y.
>Class name: PointFloat64 extends: PointObject
>     fields: auto struct Float64 x,y.
>===============
>
>The significant point here is that we do not need to write *any* methods
>for these various <PointObject> subclasses. They inherit all the
>necessary behavior from the base class

That's true, because you move the complexity to the "fields" part of the 
declaration.

I think that the language must be small as possible and let's the objects 
to create the idioms to talk to them.

[snip]
>Hopefully, this provides some additional food for thought.

Yes... of course, thanks for it!   We ever learn from these type of 
discussions.

>Introducing
>"types" into Smalltalk should be done with care and consideration. It
>offers significant opportunity to enhance Smalltalk -- but there are
>also classic static-typing concepts that may (depending on design goals)
>be undesirable if the objective is to enrich Smalltalk for dynamic
>typing behavior.
>
>-- Dave S. [SmallScript Corp]
>
>SmallScript for the AOS & .NET Platforms
>David.Simmons at SmallScript.com | http://www.smallscript.org

Cheers,

Diego Gomez Deck





More information about the Squeak-dev mailing list