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

Allow with syntax. #22

Closed
evinism opened this issue Oct 16, 2021 · 3 comments
Closed

Allow with syntax. #22

evinism opened this issue Oct 16, 2021 · 3 comments

Comments

@evinism
Copy link
Owner

evinism commented Oct 16, 2021

We might want let syntax, via with [expression] as [identifier] in [expression]. This'll be a bit of a journey to get though, so not immediately available.

@evinism evinism changed the title Allow let syntax. Allow with syntax. Oct 16, 2021
@evinism
Copy link
Owner Author

evinism commented Oct 25, 2021

One of the first real projects I had with MistQL made it so that "with" syntax was extremely necessary. I'm probably gonna formalize this and add it because not having it seems to be a major issue.

2 possible styles:

  1. with {var1: var2, var3: var4} in expression
  2. with var1 as var2, var3 as var4 in exp

Additionally i need to determine how it binds with other things, and whether there's a better way to tackle ambiguity like this.

@evinism
Copy link
Owner Author

evinism commented Jan 8, 2022

With pipes propagating values, you can do this with something like:

{ alias1: 2 * "something" } | apply (whatever you were planning on doing)

Still awkward but certainly better than nothing, and certainly good enough the time being.

@evinism
Copy link
Owner Author

evinism commented Mar 26, 2022

Probably gonna keep this out of the language for the time being. Unless the idiom {alias: value} | apply ( ... ) becomes too cumbersome, we should opt to reduce complexity of the language, and keep this dedicated syntax out.

Even better, if #110 gets adopted, then the idiom becomes {alias: value} |> (...) which is wonderfully concise and satisfies the issue completely. With that in mind, I'm going to close this issue as our path forward is really through the |> operator

@evinism evinism closed this as completed Mar 26, 2022
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

No branches or pull requests

1 participant