Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign uppromql: separate expression language and rule parsing #1595
Comments
fabxc
added
the
enhancement
label
Apr 25, 2016
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
|
Not in favor of semicolons – but we should just vote on that. Please react to this comment:
|
This comment has been minimized.
This comment has been minimized.
|
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... |
This comment has been minimized.
This comment has been minimized.
|
I do have an alternative proposal. I'll prepare an overview. |
This comment has been minimized.
This comment has been minimized.
|
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
added
kind/enhancement
and removed
enhancement
labels
Apr 28, 2016
fabxc
referenced this issue
Jul 1, 2016
Closed
promtool: Add naive implementation of promtool fmt #1779
fabxc
referenced this issue
Sep 8, 2016
Merged
Fix parsing of label names which are also keywords #1958
This comment has been minimized.
This comment has been minimized.
|
@grobie so, about that alternate proposal... :) I'm curious |
This comment has been minimized.
This comment has been minimized.
|
@fabxc Oops, long time. I'll need to check my notes, but I think it's better to ignore that comment for now. |
This comment has been minimized.
This comment has been minimized.
|
When this happens we also need to look at #1695 Especially fabxc's points:
|
This comment has been minimized.
This comment has been minimized.
|
Is this done now with 2.0? |
This comment has been minimized.
This comment has been minimized.
|
Yes, I think so. |
brian-brazil
closed this
Jul 7, 2017
This comment has been minimized.
This comment has been minimized.
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. |
fabxc commentedApr 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.