[m-rev.] for review: delete references to Erlang in the compiler
Zoltan Somogyi
zoltan.somogyi at runbox.com
Wed Oct 28 13:00:16 AEDT 2020
2020-10-28 10:57 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
> My own patch series was nearly ready as well, oh well. I didn't make the
> change to item_type_repn_info so let's go with yours.
Sorry for stopping on your toes. I only started on the change after midnight,
when it seemed to me that you stopped working on this diff series.
> The major difference with my patch series is that I kept lang_erlang
> around. The compiler would continue to accept pragma foreign_code,
> foreign_type, etc. for a language "Erlang" but silently discard them.
> The compiler would also continue to accept --libgrades-exclude erlang.
> My plan was that we would leave these transition measures in place for
> one or two major releases (six or 12 months).
Sorry, but I don't see any point in that. Anyone who wants to keep using
the Erlang grade would have to keep using pre-erlang-deletion
compilers anyway, as fitting punishment for not speaking up on m-users.
Anyone who has never used Erlang would not have any Erlang code
to delete. The only people affected by the decision here are people
who used Erlang in the past, but do not use it now. They would have to
delete any Erlang code at some point in time; I don't see any benefit
to letting them keep it for a while. To my mind, the simplest thing to do
would be to stop supporting Erlang in *all* aspects at the same time.
There is one thing we can do for users to help them, which is that
when the compiler encounters "erlang" or "Erlang" as a foreign language
on a foreign type, enum, code, decl or proc, the error message it emits
should say not just "unknown language", but a message that specifically
says that support for Erlang has been discontinued. I am happy to add
that extra message. I don't see any benefit to adding lang_erlang back
to the compiler in general. What benefit do you see?
Zoltan.
More information about the reviews
mailing list