~technomancy/fennel

Discussion of the Fennel programming language for contributors and users

https://fennel-lang.org

1

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

Details
Message ID
<87o906kzc0.fsf@hagelb.org>
DKIM signature
missing
Download raw message
Benaiah Mischenko <benaiah@mischenko.com> writes:

> I believe part of the rationale was to be able to have a character
> reserved by the compiler which would allow us to add special forms by
> any name we wanted without ever breaking extant fennel code in doing so.

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. Also this
fails to compile:

    (let [a~ 1] a~)

But this succeeds:

    (let [~a 1] ~a)

So whatever we do, we should probably enforce the list of disallowed
characters more consistently. =)

We also already have @ in the list, so that might be enough.

> - Abandon the idea of a reserved compiler character or sigil, and just
>   add globally-bound symbols when we create new special forms or
>   built-in macros. We already do this without much trouble, and we could
>   potentially version this map of names-to-builtins so that users can
>   use newer compilers with unmodified code by telling the compiler to
>   use the builtin names from an older version.

Right now when you try to define something that shadows an existing
built-in, it's a compiler error. We could provide a compiler option to
put it into warning mode so you can slowly upgrade to new versions of
Fennel instead of fixing it all at once. I think that would solve this
same problem in a more flexible way.

-Phil

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

Details
Message ID
<87h85ygq4l.fsf@hector.i-did-not-set--mail-host-address--so-tickle-me>
In-Reply-To
<87o906kzc0.fsf@hagelb.org> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
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. Also this
> fails to compile:
>
>     (let [a~ 1] a~)
>
> But this succeeds:
>
>     (let [~a 1] ~a)

o.O this definitely does not seem like intended behavior.

> We also already have @ in the list, so that might be enough.

I want to correct my earlier email from this thread. ,(unpack ...) is
not actually equivalent to unquote-splicing. This is because unpack will
only insert multiple values if it is the last form in the surrounding
function call or table literal, whereas unquote-splicing as implemented
in other lisps doesn't have this limitation. Given that, perhaps @ is
better used for its traditional purpose in the ,@ prefix.

> Right now when you try to define something that shadows an existing
> built-in, it's a compiler error. We could provide a compiler option to
> put it into warning mode so you can slowly upgrade to new versions of
> Fennel instead of fixing it all at once. I think that would solve this
> same problem in a more flexible way.

This could work, but the compiler would have to be modified to allow
special forms (these include macros) to be shadowed by lexical
bindings. I'm fairly certain the error is there to prevent users from
running into weird errors caused by special forms and macros being
unshadowable.

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.


- benaiah