New EEP draft: Pinning operator ^ in patterns

[Eugene]

On 1/15/21 12:19 PM, Raimo Niskanen wrote:
> On Fri, Jan 15, 2021 at 11:48:14AM +0100, Eugene wrote:
>> On 1/15/21 11:42 AM, Raimo Niskanen wrote:
>>> On Thu, Jan 14, 2021 at 06:09:53PM +0100, Eugene wrote:
>>>> On 1/14/21 3:58 PM, Raimo Niskanen wrote:
>>>>> On Mon, Jan 11, 2021 at 02:50:46PM +0100, Eugene wrote:
>>>>>> annotating UNbound variable will take less symbols.
>>>>>> far far far less.
>>>>>>
>>>>>
>>>>> Every time you introduce a new variable, it is unbound.
>>>>>
>>>>> Do you claim that matching an already bound variable is more common?
>>>>
>>>> not matching,
>>>> mentioning.
>>>>
>>>> i hope you are not trying to introduce another
>>>> context-dependant mental mess.
>>>
>>> Nope.  I was trying to understand you.
>>
>> if you compare occurrences of UNbound vs bound,
>> bound is way more often,
>> and should be given the shortest notation.
>>
>> if you limit your scope to the "match" context
>> (whenever a part of an expression is equivalent to
>> a left-side of a match)
>> you thus create a context-dependency that
>> MUST BE KEPT IN MIND OF A READER.
> 
> Now I think I understand.
> 
> This EEP suggests to add the pinning operator to variables in patterns,
> not in expressions.  Therefore it is better to have the operator on unbound
> variables that are less common in patterns.
> 
> Patterns are, as you say, left of = (the matching operator), in function
> clauses, in case clauses, and in list comprehensions left of <-.
> 
> The code reader must already today be very aware about what is a pattern
> and what is not.  This EEP does not introduce a new requirement on context
> awareness for the code reader.
> 
> 
>>
>> you win a statistical comparison and can give
>> the shorter notation to UNbound mentions of a variable,
>> but a reader of your program has to pay some price.
> 

explicit OPTIONAL notation of the requirement for a variable
to be UNbound appears more coherent in the big picture.