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

promql: separate expression language and rule parsing #1595

Closed
fabxc opened this Issue Apr 25, 2016 · 11 comments

Comments

Projects
None yet
5 participants
@fabxc
Copy link
Member

fabxc commented Apr 25, 2016

The current parser handles both as one which makes #1095 nearly impossible to implement.
They should be considered separate language. This will require newlines becoming part of the rules syntax to be handled in a sane way.

Even though everyone should be doing that, this will be breaking.

Should we consider adding newline semantics before 1.0 to not have to cut 2.0 for that?
My hunch is we won't get to it too soon and will cut 2.0 for other reaosons.

@fabxc fabxc added the enhancement label Apr 25, 2016

@brian-brazil

This comment has been minimized.

Copy link
Member

brian-brazil commented Apr 25, 2016

I hear semicolons are not completely out of fashion.

If we're going to break rules files, we should probably force all rules to be in a group while we're at it.

@fabxc

This comment has been minimized.

Copy link
Member Author

fabxc commented Apr 27, 2016

Not in favor of semicolons – but we should just vote on that.

Please react to this comment:

👍 – newline (Python/Go style)
👎 – semicolon (C style)

@juliusv

This comment has been minimized.

Copy link
Member

juliusv commented Apr 27, 2016

I'd have to understand this better before trying to comment either way.

So with newlines, obviously it should still be allowed to have newlines in general in expressions (including rule RHS expressions), just not in certain positions, right? What would be exactly the rule for when a newline means the end of an expression? To get an idea of how much it would break and how confusing it would be...

@grobie

This comment has been minimized.

Copy link
Member

grobie commented Apr 27, 2016

I do have an alternative proposal. I'll prepare an overview.

@brian-brazil

This comment has been minimized.

Copy link
Member

brian-brazil commented Apr 27, 2016

Yeah, I'd like to see what a newline proposal looks like. We don't want to end up with the oddness JS has for newlines for example.

@fabxc

This comment has been minimized.

Copy link
Member Author

fabxc commented Sep 8, 2016

@grobie so, about that alternate proposal... :) I'm curious

@grobie

This comment has been minimized.

Copy link
Member

grobie commented Sep 8, 2016

@fabxc Oops, long time. I'll need to check my notes, but I think it's better to ignore that comment for now.

@gouthamve

This comment has been minimized.

Copy link
Member

gouthamve commented Mar 28, 2017

When this happens we also need to look at #1695 Especially fabxc's points:

  • easy to define PromQL tests
  • easy to define PromQL benchmarks
  • alerting rule unit testing for users
@brian-brazil

This comment has been minimized.

Copy link
Member

brian-brazil commented Jul 7, 2017

Is this done now with 2.0?

@gouthamve

This comment has been minimized.

Copy link
Member

gouthamve commented Jul 7, 2017

Yes, I think so.

@lock

This comment has been minimized.

Copy link

lock bot commented Mar 23, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.