On 17 August 2012 15:02, Levente Uzonyi <leves at elte.hu> wrote:
> On Fri, 17 Aug 2012, Frank Shearar wrote:
>
>> On 17 August 2012 13:07, Levente Uzonyi <leves at elte.hu> wrote:
>>>
>>> On Fri, 17 Aug 2012, Frank Shearar wrote:
>>>
>>>> On 14 August 2012 15:38, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>>
>>>>>
>>>>> On 14 August 2012 15:36, Colin Putney <colin at wiresong.com> wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar
>>>>>> <frank.shearar at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> Why both testPrefFalse and testTokenishFalse (and both testPrefTrue
>>>>>>> and testTokenishTrue) if they both do the same thing?
>>>>>>> (testPref(True|False) are in the image now, so unless there's good
>>>>>>> reason, I don't see why we can't just remove testTokenish(True|False)
>>>>>>> from the above.
>>>>>>>
>>>>>>> Nit: I'd like testPref(True|False) categorised.
>>>>>>>
>>>>>>> Otherwise, +1 from me.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I renamed them.
>>>>>
>>>>>
>>>>>
>>>>> *cough*. Frank, the '-' lines are lines that are removed, and the '+'
>>>>> lines are lines that are added. Right. Moving swiftly along...
>>>>>
>>>>>> The new tests are related to selector precedence, so I
>>>>>> wanted the tokenish tests to have that word in their selectors. The
>>>>>> new versions are categorized too!
>>>>>
>>>>>
>>>>>
>>>>> Now that my eyes have seen the light, consider this an unqualified +1
>>>>> then.
>>>>
>>>>
>>>>
>>>> Does this need updating? testP2LeadingUnderscore and
>>>> testP2SingleUnderscore fail because #_+ and #'_' have precedence 1
>>>> instead of the expected 2. (This relates to your conversation with
>>>> Juan, IIRC, on whether or not $_ can form part of a binary selector.)
>>>
>>>
>>>
>>> #'_+' is not a valid selector, since + can only be part of a binary
>>> selector, while _ can't be part of such selector. So it doesn't matter
>>> what
>>> #precedence returns and #testP2LeadingUnderscore should be removed.
>>
>>
>> Well, I've now twice seen "$'_+' is not a valid selector" but I've not
>> seen any _reason_ why not. _ used to be a poor man's left arrow, so _
>> couldn't be in _any_ selector, so arbitrarily limiting _s to only
>> non-binary selectors seems artificial. Unless it's _purely_ a
>> compatibility with those Smalltalks who have always had _s in their
>> selectors? (So "that's what ANSI says" would be a valid reason.)
>
>
> Nothing artifical here. Characters which are allowed in binary and
> non-binary selectors are in two disjunct sets already. I'm pretty sure the
> reason for this is to keep the grammar free of ambiguities. For example:
> If + would be allowed in non-binary selectors too, then you could write a
> method with the name yourself+b. So "a yourself+b" would have two different
> meanings.
> With _+ the same can be done. What is "a_+b"?
> Is it "a _ + b" (where #'_' is a unary selector) or "a _+ b" (where #'_+' is
> a binary selector)?

We're bordering on being meaninglessly academic, so feel free to shut
the conversation down :) We're not talking about $+ though, which is
definitely in the binary selector set of characters. Oh, I think I see
what you mean: you're saying $_ should only be in the binary selector
set of chars or the other set, but NOT both (because of potential
ambiguities...?).

But then _ ought to be a valid identifier, given that at the moment
unary selectors and identifiers share the same definition. I'd be
_very happy_ with this, but it's probably not a compatible change. Uh,
no, that leads back to the 3--4 problem. a_+b could be a _+ b or a_ +
b. Ah well.

frank

> Levente
>
>
>>
>> frank
>>
>>> Levente
>>>
>>>>
>>>> frank
>>>>
>>>>> frank
>>>>>
>>>>>> Colin
>>>>>>
>>>>
>>>>
>>>
>>
>>
>