Rename the ENV variable JULIA_USE_NEW_PARSER to something more verbose and less time-sensitive

[navidcy]

I find the JULIA_USE_NEW_PARSER environment variable name ambiguous.

julia/base/Base.jl

Line 607 in d60f9b3

if get_bool_env("JULIA_USE_NEW_PARSER", true) === true

What is new now it won't be new in a few months... So the variable name is doomed to become obsolete.

Why not something like JULIA_USE_PRE_v1p10_PARSER or something along those lines: more verbose, and less time-sensitive.

[PallHaraldsson]

I think this is overkill. I believe the new parser is off by default I believe we are testing to have it on by default until first release candidate, and we will see about changing it then to non-default, depending on if any issues come up.

[maleadt]

Maybe JULIA_USE_JULIASYNTAX (cfr. USE_BINARYBUILDER)?

I believe the new parser is off by default

It is used by default, as the code above shows.

[navidcy]

That's better. Anything that is not time-sensitive is better. That's my 2 cents. :)

[KristofferC]

Or maybe delete it completely?

[PallHaraldsson]

Maybe JULIA_USE_JULIASYNTAX

That's actually worse, since the syntax is supposedly the same, just a new parser, and not all familiar with JuliaSyntax.jl, which is just an implementation detail. Since it is actually on by default (I thought it was meant to be off), then JULIA_USE_OLD_PARSER could also work.

[navidcy]

But that has the same problem as above. E.g., in 3 years what will "old" mean?

[oscardssmith]

what about JULIA_USE_FLISP_PARSER

[PallHaraldsson]

E.g., in 3 years what will "old" mean?

It doesn't really matter. People will almost never need to opt into the old parser, it will only be relevant to test for compatibility with the current parser, or if there's a known bug to opt into the older one. Since the new one is pure Julia, I don't see that we will have such a transition again, but even if, we will only have the latest, and an older legacy one, and we will only want the capability to opt into that one (and never have three or more to choose from in any specific Julia version), so it doesn't really matter what the old refers to.

Pretty much nobody is going to be using the ENV, and that goes for JULIA_USE_NEW_PARSER, since it's actually defaulted to, so my argument applies to it too (unless before release we will no longer be confident in it and change to off by default).

what about JULIA_USE_FLISP_PARSER

It's more explicit, I would be ok with is since I don't think we sill have another transition, but if ever then we would need yet another ENV, and then JULIA_USE_OLD_PARSER might actually be better to just reuse it. I think we don't need o worry about this much, and can actually postpone to until closer to release. We are not committed to anything in non-release alpha.

[LilithHafner]

+1 for deleting it entirely. If we never touch the flisp parser again then as the language syntax evolves it will soon be obsolete. During 1.10 we can (and IMO should) keep the flag (possibly with a rename), but by 1.11, I doubt it will be viable to opt out of JuliaSyntax.

[DilumAluthge]

Won't we always need to keep the flisp parser around for bootstrapping JuliaSyntax?

[LilithHafner]

@c42f suggested on slack that we might be able to remove it using separate compilation

[c42f]

We will definitely remove the old parser at some point (maybe 1-3 1.x releases? Depends on who decides to do that work, and the readiness of runtime facilities like separate compilation which would make this a lot easier.)

At that point the JULIA_USE_NEW_PARSER environment variable will become obsolete and will be deleted. So I really don't think it's worth worrying about how this environment variable is named. So much so, that I'm ok with pretty much anything vaguely sensible. JULIA_USE_FLISP_PARSER seems fine.

However I do think we should keep some mechanism to opt into the old parser for at least one release. This is to accommodate compatibility. JuliaSyntax.jl is highly compatible, but it's only been tested against General which is far from all the Julia code which exists. If you've ever run a production system, you'll know how valuable it is to be able to flip the switch back to the old behavior, and it costs us very little to allow this for the short term.