On Fri, 17 Aug 2012, H. Hirzel wrote:

> Yes, not uncommon in other languages
>
> see for example http://underscorejs.org/
>
> Any fixes  which allows to have preferences to switch on underscore in
> identifiers and have a compatibility mode for underscore as assignment
> operator is fine. It seems that these preferences exclude each other.

No, they don't, but there are some limitations when both preferences are 
enabled: you can't name your variables and methods as a single underscore 
and you have to add whitespaces around all underscore assignments.


Levente

>
> --Hannes
>
> On 8/17/12, Frank Shearar <frank.shearar at gmail.com> wrote:
>> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>