On 17 August 2012 16:04, Levente Uzonyi <leves at elte.hu> wrote:
> On Fri, 17 Aug 2012, Frank Shearar wrote:
>
>> 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...?).
>
>
> Right. :)
>
>
>>
>> But then _ ought to be a valid identifier, given that at the moment
>> unary selectors and identifiers share the same definition. I'd be
>
>
> It is a valid identifier. Just disable underscore as assignment and enable
> underscores in selectors to be able to use it.

Oh! I had no idea!

| _ |
_ := 1.
_. "=> 1"

Haha! Also, _1 and so on are valid identifiers.

frank

> Levente
>
>
>> _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
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>