~technomancy/fennel

1

Re: [PATCH] Reintroduce ~= as an alias for not=.

Details
Message ID
<87k1askmnn.fsf@hagelb.org>
DKIM signature
missing
Download raw message
Looks like git send-email screwed up the threading on this AGAIN, so
I'll just continue the conversation here with patches in attachments instead.

Benaiah Mischenko <benaiah@mischenko.com> writes:

> Phil Hagelberg <phil@hagelb.org> writes:
>
>> I just realized that the list in issymbolchar is a *disallowed* list,
>> not a list of allowed chars. So ~ is already intended to be blocked, but
>> it's not blocked consistently, since ~= is allowed to be used.
>
> o.O this definitely does not seem like intended behavior.

The first patch contains a small fix for this; disallowed symbols are
now disallowed consistently instead of being allowed as the first char
of a symbol.

> Finally, I failed to mention another option in my previous email: we
> could continue to disallow ~ in user-defined symbols, but allow it in
> compiler builtins, and leave ~= as a builtin alias for not=. This would
> maintain the previously-planned use of ~ while avoiding the nasty
> backwards incompatibility caused by removing ~=. When ~ was used as
> unquote it wasn't possible to do this, because ~= would then be
> ambiguous (unquote equal vs. quoted not-equal) when inside a quoted
> form. Since we've decided to use , for unquote instead, there's not
> actually any need to remove ~= in order to use ~ for something else.

This seems like the best of both worlds and pretty easy to implement;
the second attached patch implements this with a special-case for the ~=
symbol.

Thoughts on either?

-Phil

Re: [PATCH] Reintroduce ~= as an alias for not=.

Details
Message ID
<87ef0zh9ol.fsf@mischenko.com>
In-Reply-To
<87k1askmnn.fsf@hagelb.org> (view parent)
DKIM signature
pass
Download raw message
Phil Hagelberg <phil@hagelb.org> writes:

> Benaiah Mischenko <benaiah@mischenko.com> writes:
>
>> Phil Hagelberg <phil@hagelb.org> writes:
>>
>>> I just realized that the list in issymbolchar is a *disallowed* list,
>>> not a list of allowed chars. So ~ is already intended to be blocked, but
>>> it's not blocked consistently, since ~= is allowed to be used.
>>
>> o.O this definitely does not seem like intended behavior.
>
> The first patch contains a small fix for this; disallowed symbols are
> now disallowed consistently instead of being allowed as the first char
> of a symbol.

The patch looks great! Perhaps this deserves mention in the changelog
(similarly to the removal of commas-as-whitespace). It seems unlikely
that this would break any existing code, but it is possible.

>> Finally, I failed to mention another option in my previous email: we
>> could continue to disallow ~ in user-defined symbols, but allow it in
>> compiler builtins, and leave ~= as a builtin alias for not=. This would
>> maintain the previously-planned use of ~ while avoiding the nasty
>> backwards incompatibility caused by removing ~=. When ~ was used as
>> unquote it wasn't possible to do this, because ~= would then be
>> ambiguous (unquote equal vs. quoted not-equal) when inside a quoted
>> form. Since we've decided to use , for unquote instead, there's not
>> actually any need to remove ~= in order to use ~ for something else.
>
> This seems like the best of both worlds and pretty easy to implement;
> the second attached patch implements this with a special-case for the ~=
> symbol.

This also looks good to me. Thanks for the quick implementation!

- benaiah