notes on "Understanding message syntax"

  Hello,

  We started the Japanese translation project of PBE and I signed up
to look at "Messages.tex".  The following is a little note I took
while translating.  (As you can see, the original text is in "...",
and my comments are led by '->'.).

  To my taste, it seems to repeat itself a lot... but probably this is
from the experience of teaching it to students, so it is okay.  Also,
I'd separate the syntactical concepts and behavirol concepts a bit
more clearly.

  But in any case, thank you for writing such a textbook!

-- Yoshiki

----------------------------------------------------------------------------------
"Moreover, you cannot change the arity of a method"

  -> should avoid 'method', and stick with "message"?


"Unary messages are always sent first, then binary messages and finally keyword ones"

  -> To me, this statement is somewhat confusing as it feels like it
    is talking about some concurrency (as it leaves the idea of
    returning values out), or statements separated by periods.  Could
    it be better to stick with "evaluation" and "precedence" or
    "priority"?


"To help you identify the receiver of a message, we will underline it for you."

  -> It'd be nice if the "underlines" are (only) in the figures but
      not other places such as examples.

-> It is disturbing to see that the concepts in the syntax and the
   behavior at runtime is mixed up.  For example, it reads: "A
   receiver can be the first element of a message, such as \ct{100} in
   the message send".  To me "first element" is a syntactical concept.
   But then it goes "a receiver can also be the result of other
   messages".  To me "result" is something at runtime.


"They follow the syntactic template: \ct{receiver messageName}"

  -> "receiver" can be an expression, but "messageName" is a word, so
     it could be in different font.  (It could be called something
     else to signify that it is a word.)


"a sequence of one or more characters from the set: \ct{+}, \ct{-},
\ct{*}, \ct{/}, \ct{&}, \ct{=}, \ct{>}, \ct{|}, \ct{<}, \ct{~}, and
\ct{@}."

  -> Even within the ASCII range, Pharo actually allows ",", "\", "%",
     and "?" (and possibly some other non-printable ones).  The latter
     three may not be common but "," should be included.


"Color r: 1 g: 0 b: 0       --> Color red  "creates a new color""

  -> "Color red" does not craete a new color, but returns an existing
     one.  (Whether it creates a new one or returns exsiting one is an
     implementation detail.  So it'd be better to leave it open.)


"Keyword based messages"

  ->  Perhaps "Keyword-based messages", but I'd not suddenly introduce
      a new terminology, when it is called keyword messages elsewhere.


"Messages in \ind{parentheses} are sent prior to any kind ofmessages. "

  -> Yes...  and the result value is obtained before anything else
      happens.  So, sticking with the idea of "evaluation" may be
      easier to understand.


"Then we bind the argument \ct{aClass} to the concrete value \ct{Boolean}."

  -> Perhaps "... to the actual value" or "actual argument"?


"\mbox{\ct{isAbstract}}"

  -> \mbox is not needed?


"First the message between parentheses is sent: it contains two binary
messages \ct{65@325} and \ct{134@100} that are sent first and return
points"

  -> Even though it is explained right after this subsection, it
     certainly opens and leaves the question about the order of
     evaluation at this moment.


"To get the correct result, ..."
"...which produces the correct behaviour."

  -> In the expression "20 + (2 * 5)" or "20 + 2 * 5", there is
     nothing tells us that the latter is desired or "correct".  The
     numbers should use the readers' intuition, such as "7 * 3 + 365
     * 4" or something like that, to say that there is indeed an
     "expected" result.


"\important{In \st, arithmetic operators such as + and * do not have
different priority. \ct{+} and \ct{*} are just binary messages,
therefore \ct{*} does not have priority over \ct{+}. Use parentheses
to obtain the desired result.}"

  -> Here and a few other places, + and * are not enclosed in \ct{}.


"\section{Hints for identifying keyword messages}"

  -> The section name is about 'keyword messages", but it certainly
      involves other kinds of messages.


"\on{Sounds terribly complicated.}"

  -> ... I might have to agree ^^;


"If you have problems with these precedence rules, you may start
simply by putting parentheses whenever you want to distinguish two
messages having the same precedence."

  -> I cannot help but feeling that there is so much assumptions
      behind this hint.  To say the least, people should put
      parentheses to messages that have different precedence.


"So in \lct{(\emph{expression})}, the \lct{\emph{expression}} will
\emph{always} be evaluated exactly once."

  -> Yes, but "always" means "when execution reaches here".


"both the receiver and the argument of a \ct{whileTrue:} message require the use of square brackets..."

  -> Hmm, but they can certainly be variables, at least.
      (Regrettably, it is not general enough so you cannot use a
      message send that returns a block.)


"Note that the period is a \subind{statement}{separator} and not a
terminator. Therefore a final period is optional."

  -> If it is a separator, it would imply that the final period is an
      error.  Some elaboration may be good.


"Note that the object receiving the cascaded messages can itself be
the result of a message send. In fact ..."

  -> Somewhat hard to understand.


"A message is always sent to an object named the \emph{receiver} which
may be the result of other message sends."

  -> It reads like a receiver has to be named receiver.  Probably
      "called" is better?
_______________________________________________
Sbe-discussion mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion

On Jun 13, 2011, at 7:42 AM, Yoshiki Ohshima wrote:

Thanks for the feedback.
We should retrofit some part of it in the book.

>
> -- Yoshiki
>
> ----------------------------------------------------------------------------------
> "Moreover, you cannot change the arity of a method"
>
>  -> should avoid 'method', and stick with "message"?


yes  (even if we pay really attention method = what is executed and message the name).

>
> "Unary messages are always sent first, then binary messages and finally keyword ones"
>
>  -> To me, this statement is somewhat confusing as it feels like it
>    is talking about some concurrency (as it leaves the idea of
>    returning values out), or statements separated by periods.  Could
>    it be better to stick with "evaluation" and "precedence" or
>    "priority"?


With priority why you would not get the concurrency feeling?

> "To help you identify the receiver of a message, we will underline it for you."
>
>  -> It'd be nice if the "underlines" are (only) in the figures but
>      not other places such as examples.

        why ? this is just to explain after we do not do it anymore.

>
> -> It is disturbing to see that the concepts in the syntax and the
>   behavior at runtime is mixed up.  For example, it reads: "A
>   receiver can be the first element of a message, such as \ct{100} in
>   the message send".  To me "first element" is a syntactical concept.
>   But then it goes "a receiver can also be the result of other
>   messages".  To me "result" is something at runtime.

why should we be only syntactic when talking about messages?
What is important is that people understand what you can do with them.


> "They follow the syntactic template: \ct{receiver messageName}"
>
>  -> "receiver" can be an expression, but "messageName" is a word, so
>     it could be in different font.  (It could be called something
>     else to signify that it is a word.)
>
yes


>
> "a sequence of one or more characters from the set: \ct{+}, \ct{-},
> \ct{*}, \ct{/}, \ct{&}, \ct{=}, \ct{>}, \ct{|}, \ct{<}, \ct{~}, and
> \ct{@}."
>
>  -> Even within the ASCII range, Pharo actually allows ",", "\", "%",
>     and "?" (and possibly some other non-printable ones).  The latter
>     three may not be common but "," should be included.

yes we should add that.

>
>
> "Color r: 1 g: 0 b: 0       --> Color red  "creates a new color""
>
>  -> "Color red" does not craete a new color, but returns an existing
>     one.  (Whether it creates a new one or returns exsiting one is an
>     implementation detail.  So it'd be better to leave it open.)


from a user perspective Color red creates a new color as well as Color r: 1 g: 0 b: 0



the problem is that we avoid evaluation because people think that evaluation is for slow interpreted
languages while execution for real language like C++.


> "Then we bind the argument \ct{aClass} to the concrete value \ct{Boolean}."
>
>  -> Perhaps "... to the actual value" or "actual argument"?

Why not

Indeed we should fix that


Yes but this is true :)
This is just that nobody ever realize it but [ ] creates a scope that terminates message keywords identification


>
>
> "If you have problems with these precedence rules, you may start
> simply by putting parentheses whenever you want to distinguish two
> messages having the same precedence."
>
>  -> I cannot help but feeling that there is so much assumptions
>      behind this hint.  To say the least, people should put
>      parentheses to messages that have different precedence.

this is what you do in math when you do not know and when you understand you start removing them.
Indeed, the smalltalk haskish way.

_______________________________________________
Sbe-discussion mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion

At Mon, 13 Jun 2011 18:12:34 +0200,
stephane ducasse wrote:
  Thank you.  One thing that would help many translators while the
original version is kept updated is to make the original in gettext
(possibly by using po4a)

  Provided that it discusses returning values from send, then that
means the next send is after the return and priority sorts out the
order.

> > "To help you identify the receiver of a message, we will underline it for you."
> >
> >  -> It'd be nice if the "underlines" are (only) in the figures but
> >      not other places such as examples.
>
> why ? this is just to explain after we do not do it anymore.

  Hmm?  You do it on pages 66, 68 (figure 4.4 and 4.5), 69, (but not
some of the ones on 70 and 71).

> > -> It is disturbing to see that the concepts in the syntax and the
> >   behavior at runtime is mixed up.  For example, it reads: "A
> >   receiver can be the first element of a message, such as \ct{100} in
> >   the message send".  To me "first element" is a syntactical concept.
> >   But then it goes "a receiver can also be the result of other
> >   messages".  To me "result" is something at runtime.
>
> why should we be only syntactic when talking about messages?
> What is important is that people understand what you can do with them.

  Sure.  But to understand what is an "element" in "the first
element", the reader would need some mental switch to look at it.

> > "Color r: 1 g: 0 b: 0       --> Color red  "creates a new color""
> >
> >  -> "Color red" does not craete a new color, but returns an existing
> >     one.  (Whether it creates a new one or returns exsiting one is an
> >     implementation detail.  So it'd be better to leave it open.)
>
>
> from a user perspective Color red creates a new color as well as Color r: 1 g: 0 b: 0

  My point is that from a user's perspective, all it matters is that
he gets an instance of Color as the return value but he should not
care if it is "created" or not.

> > "Messages in \ind{parentheses} are sent prior to any kind ofmessages. "
> >
> >  -> Yes...  and the result value is obtained before anything else
> >      happens.  So, sticking with the idea of "evaluation" may be
> >      easier to understand.
>
>
> the problem is that we avoid evaluation because people think that evaluation is for slow interpreted
> languages while execution for real language like C++.

  Hmm, ok.

> > "Then we bind the argument \ct{aClass} to the concrete value \ct{Boolean}."
> >
> >  -> Perhaps "... to the actual value" or "actual argument"?
>
> Why not

  "Concrete" has a connotation with "abstract class vs. concreate
class" (especially because this part is dealing with abstract methods)
concept, and also a more common terminology of parameter passing is
"formal vs. actual".

-- Yoshiki
_______________________________________________
Sbe-discussion mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion

>>>
>>
>> Thanks for the feedback.
>> We should retrofit some part of it in the book.
>
>  Thank you.  One thing that would help many translators while the
> original version is kept updated is to make the original in gettext
> (possibly by using po4a)

our problem is that we cannot rewrite everything and I'm focusing on the second book.

ok we will check that

ah ok of course.

ok

>
> -- Yoshiki
> _______________________________________________
> Sbe-discussion mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
>


_______________________________________________
Sbe-discussion mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion