Updated Programmer's Reference Manual online

[Brian Rice]

On Jan 27, 2005, at 1:09 AM, Márton Sasvári (IJ/ETH) wrote:

> 1.
> Paragraph on case sensitivity of expressions feels to be a sidestep in
> the description of expressions in section 2.2. Section starts with
> emphesizing message sends, then case sensitivity, then back to
> message send classification.

That's a good point. I'll try to introduce the lexical basics first and 
then dive into message-send syntax.

> 2.
> Dispatch in 2.3.4
> It is explained that the sequence of arguments determines
> method specificity but the distance of roles does this as well. I'm 
> missing some explanation on how these to measures interwork or what is 
> the default linearisation (if that term stands without a generic 
> function concept).
>
> Anyway you may consider this a question.

The explanation there is still lacking in clarity in a few ways, so I 
am not surprised. Your question is interesting on its own, though.

Simply put: the distance of roles only relates within inheritance 
traversal for that argument only. Each argument is traversed in turn 
from left to right, and the traversal stops when the nearest applicable 
method(s) are found and all but one of the methods are ruled out. There 
may be a way to explain the precedence in terms of distance, but I 
believe that Lee has logically arranged it so that the 
distance-per-argument explanation is more accurate.

The method in question is in dispatch.slate, as dispatchTo:arity:above: 
and has zero comments, but the control-flow structure is there. I'll 
try to add some very basic comments in the hope that it will inspire 
some higher-level comments from Lee. And of course I'll adjust the 
section in the manual.

> 3.
> In the resending section 2.3.6 I could not find out what the 
> 'dispatchArray' argument is/should be in #sendTo:through: calls.

Oh. Those would be the new objects used to start the dispatch from (the 
"different signature" described in the explanation). I'll try to make 
that clearer.

> 4.
> Type Annotations 3.12.3, the example has one input slot in the block 
> and one local slot. It is explained that type annotations of method 
> input
> parameters can be added to the header as well. I looked into
> dispatch.slate the other day and have found that the type annotation 
> of input slots in the header do not need the colon before them despite 
> being input slots. I suggest to mention this in this section.
> I would be interested in the reasons for that actually. Is it to 
> distinguish them from slot definition? But than they resemple local 
> slots very much.

This is actually a mis-perception, because the parser "removes the 
colons" so to speak once it finds them, and does use them to indicate 
input slot names. parser.slate's method parseBlock: /does/ look for the 
colons - see line 285. dispatch.slate just looks at the slot name, so 
of course it won't see colons - or for that matter, it won't see 
ampersands in front of optional-keyword local slots. Instead this is 
all distinguished by having separate variables' collections in the 
method.

Without having input slots distinguished from local slots, passing 
arguments in to a block or method would result in ambiguous filling of 
slot values.

> 5.
> The LinkedList description in section 3.6.6 does not mention that this 
> list assumes that added objects respond to the protocol defined by the 
> Link prototype. Other collections do not do that. At least that's how 
> I've understood it when looking at the code.

Yeah, that collection type suffers from a lack of comments as well. 
I'll fix both.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/