[Cuis-dev] Lynn Conway (1938-2024) [was: change image in ImageMorph]

Wed Jun 12 16:51:44 PDT 2024

> So it seems the term "statement" is used in the template for creating new
> methods.

I believe there is a confusion here.
As Hernán correctly pointed out, in the [mostly biologically-inspired]
Smalltalk paradigm we talk about objects communicating by sending
messages to each other.  Conceptually an object is an independent agent;
perhaps an independent thinking entity.
Methods are little programs through which an object is programmed how to
respond to some particular message.

What you see in that System Browser "when you are ready to implement
a new method", is Smalltalk-80's "method pattern".  Smalltalk-80 is an
approximate simulation of Smalltalk in computer technology that was
achievable during The Decade of Research.

[By the last phrase, I am alluding to the book edited by Giuliana
Lavendel.  To those who haven't read that book, I full-heartedly
recommend to read at least Pake's Introduction chapter].

NB that I said "achievable", as opposed to "available".  The people at
PARC were — to quote from Alan Kay — serious about their software and
therefore built their own no-less-revolutionary hardware.  This morning
I learned about the passing of Lynn Conway, the visionary at PARC who
together with Carver Mead invented VLSI.  (See pp.283–294 in the above-
mentioned book).

But even those computers were limited by what was technologically
attainable at the time.  Sadly, these limitations propagate to software,
so the Smalltalk simulator implementations of the time, such as
Smalltalk-76 or Smalltalk-80, were crude approximations, mapping the
massively-parallel world of active objects to a sequential processor
acting on a passive array of bytes as the only conceivable structure.
The design decisions in such implementation are dictated by these
limitations.

Returning back to the subject of method-script.  The Smalltalk-80
method-script is typical of the prevailing languages of the Research
Decade: a method is a temporally-strict sequence of statememts.
A statement may assign a result of a message send to an lvalue
(or mutate the state in some other way).  Between statements, you have
the "statement separator" (e.g. "full stop" (U+002E) in the Cuis
concrete syntax) which acts as a temporal wall: in

  S₁ . S₂

the execution of statement S₁ must complete before the execution
of statement S₂ can begin.

Interestingly, even in the 1970s this was not assumed to be the only
possible form for a method.  For example, to Robin Milner a method is a
strategy for achieving a goal:

> These goal-seeking activities are as widely different as seeking to
> win at chess and seeking to meet a friend before noon on Saturday.
> But the similarity can be articulated in terms of a little theory
> of goal-seeking; a theory that has nothing to do with finding the
> best strategy, or with minimizing the prospect of failure (important
> though these things are), but which tries to make precise how concepts
> like goal, strategy, achievement, failure, etc. relate logically to
> each other [...]
>
> We may discern two prime entity classes in any sphere of goal-seeking
> activity: the goals and the events.  A goal may sometimes be thought
> of as a description that may be satisfied by one or more (or no)
> occurrences, and an event is simply a particular occurrence.
> For example:
>
>        a goal, G₁ : A and B to meet before noon on Saturday;
>      an event, E₁ : A meets B under the clock at Waterloo Station
>                     at 11h53 on Saturday.
>
> It is clear that event E₁ satisfies the description that has been
> designated as goal G₁, i.e. it achieves goal G₁.

So, in a method we might want to express some idea like, "to achieve G₁,
we need both E₁ and E₂"; in your "method-template" syntax, it would be
something like

G₁
  E₁ ∧ E₂

or Gentzen would write

  E₁   E₂
  -------
    G₁

However we notate it, is a question of taste; what's important is that
we can give the tasks E₁ and E₂ to two independent agents in parallel.
This is decidedly NOT the same as writing E₁.E₂.

Or we might want to say "to achieve G₁, it suffices to have E₁ or E₂":

G₁
  E₁ ∨ E₂

and give E₁ to Agent1 and E₂ to Agent2.  Maybe Agent1 segfaults and
crashes; we are still ok if Agent2 achieves E₂.

One exciting thing is that even though such constructs are not
expressible as Smalltalk-80 CompiledMethods, even the Back-to-the-Future
Samlltalk already provides for them:  you could put something like
(newly-written) MilnerStrategy into a MethodDictionary, then method
lookup resolves to the MilnerStrategy, the VM sees it's not a
Smalltalk-80 CompiledMethod, sends #run:with:in: to the MilnerStrategy,
which can respond to it in any generalized way we want.

In fact this is not even difficult (and we use this in MachineArithmetic
to compute values that are not set elements); what I think would be
really really cool, is to generalize the Smalltalk-80 Debugger from
chains of Contexts as executions of CompiledMethods, to trees of
Contexts as executions of arbitrary methods!

On Sun, Jun 02, 2024 at 09:28:49AM -0500, Mark Volkmann via Cuis-dev wrote:
> Thanks for the feedback! I definitely want to learn the proper terminology
> for everything in Smalltalk.
> Interestingly though, in a System Browser when I'm ready to implement a new
> method I see this in the bottom pane:
> 
> messageSelectorAndArgumentNames
> "comment stating purpose of message"
> 
> | temporary variable names |
> statements
> 
> So it seems the term "statement" is used in the template for creating new
> methods.
> 
> On Sat, Jun 1, 2024 at 10:25 PM Hernán Wilkinson via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
> 
> > Just a small comment. In Smalltalk we do not talk about statements but
> > about messages.
> > Everything is done sending messages to objects, and if the object knows
> > how to answer that message, it does it evaluating the related method.
> > At the end they are all bits and bytes, bit conceptually it is not the
> > same, and understanding how objects collaborate sending messages is
> > essential to understand the core of Smalltalk
> >
> > Cheers!
> > Hernan
> >
> >
> > *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
> > *Phone: +54-011*-4893-2057
> > *Twitter: @HernanWilkinson*
> > *site: http://www.10Pines.com <http://www.10pines.com>*
> > Address: Alem 896, Floor 6, Buenos Aires, Argentina
> >
> >
> > On Sun, 2 Jun 2024 at 00:16 Ezequiel Birman via Cuis-dev <
> > cuis-dev at lists.cuis.st> wrote:
> >
> >> There is an example in ImageMorph's comment. You can also look at the
> >> implementation of ImageMorph >> readFromFile. It prompts for a file name
> >> and then does what you are asking for:
> >>
> >>> ... self image: (Form fromFileNamed: fileName)
> >>
> >>
> >> So the statement could be:
> >>
> >>> myImage := Form fromFileNamed:
> >>> '../Cuis/Learning-Cuis/CuisLiftsAboveItsWeight.png'
> >>
> >>
> >> See also
> >> *ImageReadWriter class >> imageMorphFromFileEntry:.*
> >>
> >> Happy hacking!
> >>
> >>
> >> On Sun, 2 Jun 2024 at 01:36, Mark Volkmann via Cuis-dev <
> >> cuis-dev at lists.cuis.st> wrote:
> >>
> >>> I imagine that changing the image displayed in an `ImageMorph` requires
> >>> two statements, one to load an image from a file and one to change the
> >>> `ImageMorph`. I think the second one looks like this:
> >>>
> >>> `myImageMorph image: myImage.`
> >>>
> >>> What's the statement I need to set the variable `myImage` to an image
> >>> object?
> >>>
> >>> --
> >>> R. Mark Volkmann
> >>> Object Computing, Inc.
> >>> --
> >>> Cuis-dev mailing list
> >>> Cuis-dev at lists.cuis.st
> >>> https://lists.cuis.st/mailman/listinfo/cuis-dev
> >>>
> >> --
> >> Cuis-dev mailing list
> >> Cuis-dev at lists.cuis.st
> >> https://lists.cuis.st/mailman/listinfo/cuis-dev
> >>
> > --
> > Cuis-dev mailing list
> > Cuis-dev at lists.cuis.st
> > https://lists.cuis.st/mailman/listinfo/cuis-dev
> >
> 
> 
> -- 
> R. Mark Volkmann
> Object Computing, Inc.

> -- 
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev