Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate = in assignments, aliases, and exports in favor of := #413

Merged
merged 3 commits into from
Apr 18, 2019

Conversation

casey
Copy link
Owner

@casey casey commented Apr 18, 2019

This PR adds := as a synonym for = in assignments, aliases and exports, and adds a deprecation warning = in those same contexts.

The deprecation warning looks like this:

warning: `=` in assignments, exports, and aliases is being phased out on favor of `:=`
Please see this issue for more details: https://github.com/casey/just/issues/379

Since this is a disruptive change, I'd like to go over the rationale, just in case anyone is curious.

Currently, = is used in assignments, aliases, exports, and default arguments:

alias b = build
foo = "bar"
export var = "val"

build module="rob":
  ./build --module {{module}} 

The just language doesn't have keywords in the conventional sense, so the parser uses lookahead to disambiguate conflicting constructs.

However, lookahead is limited and messy, and some conflicts cannot be resolved. So for example, these constructs fail to parse:

# the parser thinks that this is an export
export foo = "bar":
  echo {{foo}}

# the parser thinks that this is an alias:
bar = "baz"
alias foo = bar:
  echo {{foo}}

Also, there are additional constructs that I'd like to add that will produce further conflicts, like settings.

In order to fix this, there are a few options:

A. Use more lookahead to disambiguate expressions
B. Use a token other than = to introduce default arguments to recipes
C. Use a token other than = in assignments, exports and aliases

Using more lookahead, as in A, gets messy very quickly, especially as it's extended to longer and more complex constructs, which would limit extension of the grammar in the future, so I think ruling that out is reasonable.

B is reasonable, but I don't think that there is a good alternative to = for default argument values. : is already used to end recipe argument lists.

On the other hand, := is a good alternative for assignments, exports, aliases, and a future set setting := value notation. := is used in make, which just is most similar to, and is also used for assignment in Go and Algol. So, I think C is the best choice.

My current plan is to release this as v0.4.3, and follow up after some time has passed with a version, probably v0.5.0 that removes the old meaning of =. I don't know what the most popular ways of getting just are, but I'd like to give v0.4.3 a chance to appear in package managers so that nobody is in the unfortunate situation of needing to run the same justfile on < 0.4.3 and >= 0.5.0, and not having a construct available that will work on both.

I was thinking of supplying a --fix flag, as I mentioned in #379, but just's current parse-and-dump functionality re-orders constructs and strips comments, so using it to implement fixup functionality would be harder than I thought.

@casey casey merged commit 0ad5574 into master Apr 18, 2019
@casey casey deleted the colon-equals branch April 18, 2019 18:48
@aoeu
Copy link
Contributor

aoeu commented May 7, 2019

@casey I noticed this referencing something else in the README, I like the change. Any idea what version of just it will be in? (I'm on just v0.4.2 via cargo, FWIW.) I'm curious since I'm trying to get some people started on using just and some files I've written, they're likely going to be using homebrew or cargo, and I want to make sure I'm introducing justfiles with the new syntax (but need to make sure they'll be using compatible versions).

@casey
Copy link
Owner Author

casey commented May 8, 2019

Whoops, I meant to cut a release with this sooner. I'll cut v0.4.3 with the change and push it out today, probably later tonight. I'm not sure how long homebrew lags behind crates.io.

@casey
Copy link
Owner Author

casey commented May 8, 2019

I just cut v0.4.3. It's available on Cargo now, and prebuilt binaries will appear on the release page as they're built by CI.

I don't maintain the homebrew package, but it should be pretty easy to update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants