Updated Programmer's Reference Manual online

[Brian Rice]

I've committed these changes now, but may not get a chance to update  
the online copies of the manual very quickly.

The diff is here:
http://slate.tunes.org/cgi-bin/viewcvs.cgi/slate/doc/progman.lyx.diff? 
r1=1.22&r2=1.23&sortby=date

Let me know if there are any further questions, comments, or concerns,  
and thanks for the useful feedback! :)

On Jan 27, 2005, at 9:06 AM, Brian Rice wrote:

> 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/