4

"The guard condition evaluates to be false"

vs

"The guard condition evaluates to false"

Which one is grammatical?

  • 1
    Can you give me context, I am having trouble understanding either one. – brentwpeterson Sep 5 '14 at 18:30
  • @brentwpeterson The context is computer programming. Think of a "guard condition" as some set of safety checks that the computer must do before proceeding with an operation. In this case, "evaluates to false" is likely intended as a way of saying "the safety check failed, so an action appropriate for that failure must be taken". – HostileFork says dont trust SE Sep 6 '14 at 5:34
18

Programmers say evaluates to X. They generally do not say *evaluates to be X.

This is a technical phrase used by programmers, and in this phrase to is a preposition and not an infinitive marker, so inserting be would be inappropriate.

| improve this answer | |
  • That being said, it's pretty easy to make sense of the latter. I also feel like there should be a sentence where "evaluates to be" would be appropriate, but can't come up with anything. – Pockets Sep 5 '14 at 22:50
  • 6
    Here's a sentence which uses both evaluates to and evaluates to be- " A constraint that evaluates to true when the value defined by the dynamic operand evaluates to be within the specified range." Here "evaluates to be" is used as an interval indicator. – Manish Giri Sep 6 '14 at 3:46
  • @snailplane I'm not sure what you mean here. It's not that I disagree with your answer, in fact, I'm all for it. What I intend to show is that evaluates to be fits better when used as an interval marker, rather than being used as a condition evaluates to be true/false. – Manish Giri Sep 6 '14 at 3:59
  • 3
    @ManishGiri That sentence is rather snakey all together. I think the point in defending a usage pattern isn't to find a sentence on the Internet where someone has used it, but to find a case where it is used to good effect in an overall communicative way. If you are painted into a linguistic corner and it's the only way to make something feel like it works if you can only change one word, being painted into the corner is the problem, and shouldn't be used to justify the construction. – HostileFork says dont trust SE Sep 6 '14 at 4:00
2

If you want to sound like a natural speaker then neither is correct. Most people would use, 'The guard condition is false'. Except in situations where the evaluation itself is under question; which even in programming is uncommon.

If you are writing a compiler and speaking to someone about a situation where a line should be evaluated a certain way but, for whatever reason, it isn't then you would be careful about the distinction between the evaluation of the line and the result itself. In that case, either of your examples is very common.

Otherwise, it is assumed that the evaluation of the line itself is always correct and the distinction which your versions make between what is written and what is calculated need not be made.

| improve this answer | |
  • 1
    Please see my answer; you really shouldn't say "the guard condition is false" unless you've literally written if (false) or similar. Even if you are going to be lax about it, you still must be precise about the distinction of whether the evaluative result itself is actually false, or if the condition merely is not "satisfied". – HostileFork says dont trust SE Sep 6 '14 at 3:38
  • 1
    You've already made that distinction by including the word 'condition'. Even that is only needed when the condition is missing a !, IMHO. – krowe Sep 6 '14 at 4:28
  • You run out of descriptions if you are too lax; programming doesn't favor ambiguity. With if (foo - bar), I might point at the code and say "what is the condition here?" Does it depend if we are in a debugger with foo and bar at 1 at this point? How much are we losing if we condense it to say "the condition is false?" I'd allow the condition is "foo - bar", but prefer "conditional expression" and saying "conditions" are only satisfied or not. With values I'd say the condition evaluated to 0...and perhaps I'd say it evaluated to a "logically false value"; but not "evaluated to false". – HostileFork says dont trust SE Sep 6 '14 at 4:42
  • I don't deny that their are occasions where you might use this. I just don't think it is very often that I would phrase it like that. – krowe Sep 6 '14 at 4:44
  • Well I want to re-make the point that we agree in wanting to say that "a condition" should be a binary thing linguistically; it is "met" or "satisfied" or "true" or it is not. Unfortunately we can't have our cake and eat it too. If we want to use the shorthand of saying that "condition" can be the convenient name we use for the expression defining the condition -OR- the evaluative result of it (which is common practice), then we can finesse the issue by using the words "satisfied" and "unsatisfied" to keep from colliding with actual evaluations of true/false. Keep it under consideration. :-) – HostileFork says dont trust SE Sep 6 '14 at 4:48
2

"The guard condition evaluates to false."

That's the more correct phrasing in the two choices given; and the grammar explanation has already been provided. But I want to mention that the word choices here enter into fine points of programming semantics.

A guard condition is controlled by an expression to be evaluated. For instance, in C++ you might say:

if (1 - 1) {
    std::cout << "guard condition satisfied\n";
} else {
    std::cout << "guard condition not satisfied\n";
}

1 - 1 will evaluate to zero. Although zero isn't the same thing as false...for purposes of the if statement choosing which branch to take...it will go through to the else branch here.

So you would only be truly correct in saying "the guard condition evaluates to false" if it produced an actual false value. A great deal of the time you are actually more interested in expressing which branch the conditional takes. In those cases you would just say a condition "is" either satisfied or not satisfied.

I've mentioned this mostly as response to the answer that said you could write "the guard condition is false". If the conditional expression itself actually is false ... literally written as if (false) ... it's only then you really technically should say "the guard condition is false".

But even under the general usage that assumes you mean there is an evaluation taking place, you should be careful to distinguish whether you actually meant to emphasize that the condition was "not satisfied". If that is what you meant, it is the safer language to use.

| improve this answer | |
  • 2
    This is not an answer to the question (except for the first line or two). – Drew Sep 6 '14 at 2:19
  • 1
    @Drew The question is about whether saying "the guard condition evaluates to false" is a correct thing to say. And this is an answer saying "It's not actually correct" either way. Not only is this an answer, it is a sophisticated one--coming from a long background in both English and computer software. In those domains the correct thing to say is "The guard condition is satisfied." Conditions are not true or false; conditional expressions are. – HostileFork says dont trust SE Sep 6 '14 at 2:35
  • 1
    Nonsense. I have a longer background in both, I'm sure. There is nothing wrong with saying that a guard condition (or just a guard) evaluates to X. See this (for functional programming) and this (more generally). The evaluation is not necessarily the same kind as that of the guarded expression, but that is beside the point here (which is a point about grammar). – Drew Sep 6 '14 at 2:58
  • @Drew Another answer had covered the grammar point already. I merely agreed--and wanted to add the important bit about how the evaluation type is not necessarily the same kind as of the guarded expression...plus give enough distinctions to help model that "the condition is false" (from another answer) is wrong, unless you've literally written if (false). So introducing "conditional expression" was in service of that goal for precision. As for who's been programming longer, I wouldn't be so sure, but that is also besides the point. – HostileFork says dont trust SE Sep 6 '14 at 3:20
  • 2
    Your opposition against "the guard condition is false" is misplaced: "false" is an adjective, not a noun, so in case the guard condition is "2+2=5", it is perfectly acceptable to say the guard condition is false. Indeed 2+2=5 is false, though it is not identical to "false". (The question was about "evaluates to" rather than "is", which more properly reflects the fact that determining the status of the condition probably involves such things as taking the current values of variables, but that is another discussion.) – Marc van Leeuwen Sep 6 '14 at 14:44
0

Think of saying "23rd June" or "23rd of June". What you should say is "the 23rd day of June", but we use shorthand versions of these phrases where you miss out the bits that are obvious.

The 'be' is similarly dropped in many cases, especially when something is assigned or otherwise becomes something else, and I'd say is a shorthand itself for the word 'becomes'.

In this case though, the condition is being compared to false and so there is no 'becoming', if the guard condition was set then it'd be a different matter, though the 'be' tends to be dropped regardless.

| improve this answer | |
0

The variant with "to be false" seems grammatically incorrect. The variant with "evaluates to false" would be correct in a programming context (although I would be tempted to typeset it as "evaluates to false"), where "true" and "false" are taken to be names of the two values of the Boolean type.

The phrase "The guard condition evaluates to false" does look slightly wrong from a grammatical point of view, since "false" is an adjective whereas it here designates the value resulting from the evaluation. One might say "evaluates to a false value", but I would personally avoid that; another alternative would be "evaluates to falsity".

| improve this answer | |
  • 1
    Usage defines correctness. You're far more likely to see "evaluates to false" than something like "evaluates to falsity," so I would argue that in the programming context "false" and "true" are acceptable putative nouns. Or conversely, that we shouldn't get too hung up on parts of speech! – Tiercelet Sep 6 '14 at 20:32
  • @Tiercelet: That is exactly my opinion (and this was quite clearly a programming context); I changed "acceptable" to "correct" to avoid suggesting any disapproval. – Marc van Leeuwen Sep 7 '14 at 4:50
0

To me the second option (evaluates to be false) has always sounded a little silly. But I do I think that if the speaker is imagining some kind of flow in time/future tense involved in the evaluation then it isn't necessarily wrong. It's a slight difference in perception perhaps.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.