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.

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