True is always any value other than 0
Lo and behold, boolean(b) is TRUE. What your original code proves is that there are cases in FPC where two expressions that evaluate to TRUE are NOT _logically_ equal (even though they are both TRUE). IOW, there are cases in FPC where TRUE <> TRUE (and according to some, somehow that's not a bug... it's just "undefined behavior"...
But since this is about Pascal, and probably specifically fpc style, applying other conventions seems a bit out of scope?It's about what is logically and mathematically correct.
Speaking about a numerical value for "true", are you sure that in maths (i.e. boolean algebra) there is a numerical value to the logical states?But since this is about Pascal, and probably specifically fpc style, applying other conventions seems a bit out of scope?It's about what is logically and mathematically correct.
FPC's documentation states that when it comes to the boolean type only the value 1 is considered TRUE but, that is not true. FPC considers values other than 1 to be TRUE
Speaking about a numerical value for "true", are you sure that in maths (i.e. boolean algebra) there is a numerical value to the logical states?boolean is two states. Those can be ON and OFF or in a gate, low voltage and high voltage, if you assign a numeric value to those states then you get 0 and 1. It's been convention, for centuries I believe, to assign zero to false and 1 to true (unless I'm mistaken George Boole is responsible for that one.)
I could have sworn that is a by product of information technology.... (And this topic started about numerical values...).Again, unless I am mistaken Boole started that thing.
Does it, or does it consider them undefined?The documentation is crystal clear. for all boolean types (not BOOL types) 1 is TRUE and 0 is FALSE. It's right there in black and white. That's what the documentation states, that's very far from what FPC enforces and considers as TRUE which for FPC is any value other than zero.
Speaking about a numerical value for "true", are you sure that in maths (i.e. boolean algebra) there is a numerical value to the logical states?boolean is two states. Those can be ON and OFF or in a gate, low voltage and high voltage, if you assign a numeric value to those states then you get 0 and 1. It's been convention, for centuries I believe, to assign zero to false and 1 to true (unless I'm mistaken George Boole is responsible for that one.)
You keep doing a mix of ignoring and misrepresenting it. Your choice. Valid choice as well, but not a choice on which I will waste my time.I don't think I"m ignoring or misrepresenting anything.
You keep doing a mix of ignoring and misrepresenting it. Your choice. Valid choice as well, but not a choice on which I will waste my time.I don't think I"m ignoring or misrepresenting anything.
By definition Boolean is 2 states.
By definition Boolean is 2 states.And so does it have in FPC.
And so does it have in FPC.NO, that's the fallacy. The fact that FPC uses instructions such as test al, al and test ax, ax to determine the truth value _proves_ that what FPC is implementing is NOT a true, 2 state only, 0 and 1, boolean type. It is implementing C's BOOL thing which is 0 = FALSE any other value = TRUE (that's 255 additional states) which is in direct contradiction to the documentation.
And so does it have in FPC.NO, that's the fallacy.
Yes, it doesMartin, you cannot argue this.
And I explained how/why.
Yes, it doesMartin, you cannot argue this.
And I explained how/why.
Thank you for answers.
My desire was to determine if I can write code like this:
Agreed. I can only state the facts. I did.Here is a FACT: in FPC two expressions that are TRUE are considered to be unequal, IOW, TRUE <> TRUE. THAT is a FACT in FPC. There is NO undefined territory in the whole universe that can justify that.
Thank you for answers.It should work but, I still would be careful with writing something like that because the value of B is NOT guaranteed to be in the set [0, 1]. It can be any value ranging from zero to 255. That said, if your code can guarantee that the value of B will be 0 or 1 then there is no problem, just don't expect the compiler to guarantee B to be zero or 1, it does not.
My desire was to determine if I can write code like this:
Agreed. I can only state the facts. I did.Here is a FACT: in FPC two expressions that are TRUE are considered to be unequal,
Without the user violating the contract, an initialised boolean var can only have ordinal 0 or 1.Some people say that Pascal is a strongly typed language. I believe it is rather reasonable to expect a strongly typed language to enforce what values can be assigned to a variable, particularly when the value _obviously_ violates the data type.
Some people say that Pascal is a strongly typed language.
I believe it is rather reasonable to expect a strongly typed language to enforce what values can be assigned to a variable, particularly when the value _obviously_ violates the data type.And there we go.
Without the user violating the contract, an initialised boolean var can only have ordinal 0 or 1.Some people say that Pascal is a strongly typed language.
The problem is that FPC (and likely Delphi) fail to enforce the fact that a boolean is a single bit type.
No cycles are needed.The problem is that FPC (and likely Delphi) fail to enforce the fact that a boolean is a single bit type.
That would be only needless cycles to check that, since only legal constructs can violate that. (with the exception of an union record).
The problem is that FPC (and likely Delphi) fail to enforce the fact that a boolean is a single bit type.
The compiler should simply refuse casts such as boolean(5) which is done at compile time.Hands off type casting. This is a convenient tool. If the programmer doesn't know what it is and doesn't know how to apply it, don't let him touch it. If he knows, but uses it with an error, it's his fault, not the compiler's. Personally, I'm already annoyed when the compiler issues a warning when casting between Pointer and PtrUInt.
No cycles are needed.The problem is that FPC (and likely Delphi) fail to enforce the fact that a boolean is a single bit type.
That would be only needless cycles to check that, since only legal constructs can violate that. (with the exception of an union record).
The compiler should simply refuse casts such as boolean(5) which is done at compile time.
This is really amazing.How you keep trying to make up a fault that does not exist. At least not in the faintest fashion of how you portrait it?
Read it again, slowly please: typecasting any value other than 0 and 1 to boolean is INVALID. It's not rocket scientce, it's that simple.It is invalid, if and only if you want the value to be valid boolean data.
In addition to that, look at the code the compiler generates for a boolean: it is WRONG. The compiler is testing for nibbles, bytes, words, etc instead of testing a single bit as it should.Read my section on "representation" very very very slowly. I had discussions with you before, I know you are way above average, and ** if you want ** you can easily comprehend it.
That's right, it's invalid. If it's invalid then why does the compiler allow it ?? there are plenty of examples of invalid typecasts the compiler does NOT allow, why does it allow that invalid typecast ? It couldn't possibly be because it's a bug ... could it ?QuoteRead it again, slowly please: typecasting any value other than 0 and 1 to boolean is INVALID. It's not rocket scientce, it's that simple.It is invalid, if and only if you want the value to be valid boolean data.
If it's invalid then why does the compiler allow it ??
Now you are just trying to twist it around to a different narrative. That isn't what the docs states that you pointed to.If it's invalid then why does the compiler allow it ??
A long thread, and boolean(100) is in reference (https://www.freepascal.org/docs-html/ref/refse84.html).
boolean( ordinal_expression), the so-called value typecast,
is safe (producing valid value) only when the lowest byte of the expression result is $00 or $01.
The topic is broader: byte() and all other ordinal types.
"if you want the value ..."That's right, it's invalid. If it's invalid then why does the compiler allow it ??QuoteRead it again, slowly please: typecasting any value other than 0 and 1 to boolean is INVALID. It's not rocket scientce, it's that simple.It is invalid, if and only if you want the value to be valid boolean data.
there are plenty of examples of invalid typecasts the compiler does NOT allow, why does it allow that invalid typecast ? It couldn't possibly be because it's a bug ... could it ?Because it can be valid, depending on the situation, and expectation.
no value greater than 1 fits in a boolean and the compiler should know and enforce this _obvious fact_. but... no, it's the programmer's fault the compiler allows typecasting the space shuttle into a ham and cheese sandwich. Bad, bad programmer!
Because it can be valid, depending on the situation, and expectation.really ? how about you provide at least one example where typecasting the value 18 to boolean would be valid and, what would the result mean ? (if anything at all)
If you want a language that does not allow such stuff => well that is fine. But Pascal already allows it.I had no idea that Pascal allows putting a value, such as 18, in a single bit but, I did know that FPC tries (unsuccessfully, of course!) I had heard of "fat bits" but I don't think their purpose was to accommodate values greater than 1.
A long thread, and boolean(100) is in reference (https://www.freepascal.org/docs-html/ref/refse84.html).
boolean( ordinal_expression), the so-called value typecast,
Because it can be valid, depending on the situation, and expectation.really ? how about you provide at least one example where typecasting the value 18 to boolean would be valid and, what would the result mean ? (if anything at all)
Just to make sure, typecast to a boolean NOT a BOOL. Thank you! :)Neither.
If you want a language that does not allow such stuff => well that is fine. But Pascal already allows it.I had no idea that Pascal allows putting a value, such as 18, in a single bit but, I did know that FPC tries (unsuccessfully, of course!) I had heard of "fat bits" but I don't think their purpose was to accommodate values greater than 1.
I said typecasting "data". Storing it in a variable that happened to be of type boolean. I did not say 18 would become boolean.The point is that it is totally nonsensical and wrong to allow typecasting a value greater than 1 to a boolean. It is simply wrong for the compiler to allow that. There are plenty of invalid typecasts that FPC disallows, it should also disallow that one because it is invalid.
The variable holds arbitrary data after the typecaset. Just like TStringlist(1).
Would you agree, that TStringlist(1) does not make 1 a TStringList? If yes, then why do you expect Boolean(18) to make 18 boolean?
As I stated before, this isn't rocket science. Actually, rather trivial stuff.
In case of asm generated for boolean tests. The are correct. Show me a case (where you do not break the contract) where they do return the wrong result.There is no "contract" that a programmer has to tip-toe around to accommodate incorrect code. "test al, al", "test ax, ax", etc are appropriate for BOOL and completely wrong for boolean. No programmer has to carry the burden of accommodating wrong code. There is no contract that says, the compiler generates incorrect code and you have to program to avoid it. Also, a boolean is 1 bit (2 states) that's mathematical and no "contract" can change that, the same way that no "contract" can stuff a value greater than 1 into 1 bit.
There is no "contract" that a programmer has to tip-toe around to accommodate incorrect code.
It's not hard to implement the real boolean type, a simple "and reg, 1" does it.
because it actually is that simple.It's not hard to implement the real boolean type, a simple "and reg, 1" does it.
Why do you claim that?
I wonder where in the fpc documentation you found grounds for the expectation that the value of bit 0 should represent the boolean value.The documentation does not state which bit should be used (and it shouldn't) but, the most sensible choice is bit 0. That said, if FPC wanted to pick bit 3 or any other bit for that matter, it can be my guest. The only thing that matters is that ONLY A SINGLE BIT be used to represent a boolean, not 2, not 3, not 8, not 16, not 32, not 64 because a boolean is a single bit.
And I cannot understand on what grounds you claim a particular variant of implementing boolean to be "real boolean", and any other not.The container which can be a byte, a word, a dword or a qword, is totally irrelevant. The only thing that matters is a single bit, one the compiler chose to represent the boolean value.
So, in this post, when I say Boolean, I shall mean one-byte Boolean type as documented in fpc of course, not something you call "real boolean".
As often happens, I am part of the minority that agrees with 440bx. In a nutshell, the reason for my position lies in some inconsistent behaviors of fpc with boolean type, such as the following:
Why doesn't the compiler emit an invalid cast message error?
Edit: The error is clearly intentional.
I don't see need for it.+1.
Why doesn't the compiler emit an invalid cast message error?
Edit: The error is clearly intentional.
writeln(B1); // Output: TRUE CORRECT
writeln(B2); // Output: TRUE IMPLEMENTATION DEFINED
writeln(B1 and B2); // Output: TRUE IMPLEMENTATION DEFINED
// Compare by normalizing to 0/1
writeln( (integer(B1) <> 0) = (integer(B2) <> 0) ); // Output: TRUE CORRECT, but because the typecasts force BOOL, not BOOLEAN semantics
The purpose of my example, intentionally incorrect and extreme, was to show a concrete paradox that arises from what was clearly explained in previous posts about boolean type implementation of fpc.
In a language with static and strong typing like Object Pascal, silent errors like True=True is False should not happen, in my humble opinion.
The fact is, that Pascal has a part that is strongly typed.
And Pascal has a part that is not, and that allows to break out of that type-system. Warts and all.
The container which can be a byte, a word, a dword or a qword, is totally irrelevant. The only thing that matters is a single bit, one the compiler chose to represent the boolean value.
FPC does NOT implement booleans, it implements C's BOOL. When it comes to the boolean type, it only works as long as it is considered a BOOL and NOT a boolean.No. In fpc Boolean is what fpc documentation says, nothing else. And what you mean by "booleans" there remains unclear.
That's the reason why when using booleans, FPC can end up in situations where TRUE <> TRUE
True <> True, it is oneVariableWithUndefinedValue someRelationOperator anotherVariableWithUndefinedValueYou can't expect a predictable value from this expression. You get something once, another time something else. Or even worse, you will get the same outcome always, and your user something else.but, when the compiler does that atrocity, it's "undefined territory" (but, of course, it is!) just like when a drunk drives into a tree, it's the tree that got in the way (obviously!.)
The problem, sometimes, is to figure out where the underlying type system is strong or weak.
However GnuPascal, an old and abandoned, but respectable implementation of Pascal, with my example, generates a compilation error ("constant out of range") when attempting to cast 2 to a boolean.
So my expectation of an error message from the compiler is not so unreasonable.
I have never tried GNU Pascal, so I don't know its rules, but I believe that, unlike FPC, it doesn't follow Borland's extensions, but the iso standard object pascal.Indeed the latter, although ISO pascal also does not explicitly seem to state how it is actually stored in memory. The behaviour though is described for both: true and false are the only two options.
Indeed the latter, although ISO pascal also does not explicitly seem to state how it is actually stored in memory.
It does, actually (another link in the page you gave): https://www.gnu-pascal.org/gpc/Boolean-_0028Intrinsic_0029.html#Boolean-_0028Intrinsic_0029 (https://www.gnu-pascal.org/gpc/Boolean-_0028Intrinsic_0029.html#Boolean-_0028Intrinsic_0029)Well, sort of. It tells us how the compiler handles it/treats them (which differs from tp/fpc). It (at least ISO pascal, I'm not too familiar with gnu) does not explicitly says anything about how these enumerated values are actually stored in memory. For all we know such boolean actually occupies 64 bits in memory or perhaps even 128 bits. And as long as the compiler treats them in a certain way, it does not matter. It should behave as a black box. This in contrast to the other in gnu pascal defined boolean types.
That example is truly bad. It might be (part of) why 440bx is so strongly against the ability to use typecasts on boolean. (Albeit, his arguments are still wrong, as they simple aren't true).The drunk tree got in the way... bad, bad tree! does that tree have a licence to drive ?...
When explicit casting is involved, the compiler must not do any checking, that's the point of explicit casting. Explicit casting must not adjust bits in a variable, that's the one and only thing we can rely on.
In my opinion, the mere presence of undefined behavior isn't the problem here, but the fact that it can be triggered so easily without warning - it's a footgun with a silencer attached.
There is no consistency regarding casts in FPC - Integer(Some_Double) is forbidden,:o
Would it really kill the compiler to turn this:
...into this:
...when casting to Boolean? In the compiler's philosphy, casts involving more than just bit pattern reinterpretation seem to be perfectly fine (as demonstrated above).
With type casting you are skipping the strong type system. That's it.
But this "cast" from Integer to Double
There are 2 operations by the syntax: SomeType(SomeValue)
- typecasts
- conversion.
E.g. Int64(MyIntVar)
is a conversion. It will sign extend the value from 32 to 64 bit.
It is a bit of a pity that the same syntax does 2 different things.
Double(Int64Variable), which is same size, and the bits were reinterpreted! So, it is not about extending size, it actually changed the bits.But this "cast" from Integer to Double
The double( int) bug (https://gitlab.com/freepascal.org/fpc/source/-/issues/35886) fix is in newer versions.
who could possibly expect a compiler for a strongly typed language to catch such an error ???) Some strong type checking there!
When a programmer uses explicit type casting, he says to the compiler - do not attempt to check anything, I know what I'm doing and why I want to do so.You got that completely wrong. Typecasting isn't "limitless" and that's quite obvious because there are plenty of typecasts the compiler rejects. You really have to rethink that.
When a programmer uses explicit type casting, he says to the compiler - do not attempt to check anything, I know what I'm doing and why I want to do so.You got that completely wrong. Typecasting isn't "limitless" and that's quite obvious because there are plenty of typecasts the compiler rejects. You really have to rethink that.
Has there ever been a time where "cast" exclusively referred to bit pattern reinterpretation? (Genuine question)Yes, since K&R I know it, but probably much earlier in CS.
In C, the standard way to convert between int and double is to use casts.The C++ approach is quite like the helpers.
The C++ standard considers cast to be synonymous with explicit conversion. Furthermore, std::bit_cast isn't part of the core language; it's a standard library function.
(And by the way, "to cast" originally meant pouring molten metal into a mould, which also changes the metal's shape.)No, it means shaping the same amount of material into a different shape. It comes from old Norse and means "to throw" but there are much earlier Greek references that describe the same concept. ( Looked that up: Metaphysics (Book VII, section 1033b) , Aristotle of course, should have known that :'( )
OTH, FPC's typecasting rules are completely inconsistent (that's putting it _very_ kindly.) If they were consistent then it would accept "SomeDword := DWORD('ab');" and "SomeDword := DWORD('abc');" because it accepts "SomeDword := DWORD('a');". If the compiler was consistent it would do the same padding it does for "DWORD('a') for the other cases but, it is NOT consistent. Not only that, typecasts that are accepted for variables are not accepted for constants. IOW, consistently inconsistent.
The auto conversion is indeed a problem and hell when you want to use C style casts.
The work-around is using pointer types to what you want to cast.
The best way to show that is trying to translate any and all examples in the famous "bit twiddling hacks" from stanford.
https://graphics.stanford.edu/~seander/bithacks.html
Some of which need adjusting in FPC because of implicit conversions.
This is known to the core compiler team.But Delphi compatibility would be the priority... This mess came from Embarcadero, right?
Try DWORD('a'+'') and you will see that it fails for a string (long or short $H+/-). Because a string has no ordinal value. And the wrong size in this case.DWORD('a+') does NOT work but...
Maybe there is one thing we could all agree on
which is: the type boolean is NOT the same as the type BOOL (at least it isn't supposed to be but, it is in FPC)
Type Boolean if FPC is True only when it equals one. It is False only when it equals zero.But, that's not true.
Try DWORD('a'+'') and you will see that it fails for a string (long or short $H+/-). Because a string has no ordinal value. And the wrong size in this case.DWORD('a+') does NOT work but...
In FPC a boolean that has any value other than 1 is TRUE
Type Boolean if FPC is True only when it equals one. It is False only when it equals zero.But, that's not true.
In FPC a boolean that has any value other than 1 is TRUE which is very different than what it's supposed to be and very different than what is documented.
Wrong.You believe that ? ... I got a really good deal for you on a bridge in NY...
It is true only if it equals 1, false only when it equals zero, all other values are undefined.
It has already been shown that FPC will consider any value other than 0 to be TRUE for a boolean. That's not undefined territory, that's a FACT. That's been proved, your wishful thinking doesn't change reality.
Is this conversion behaviour documented anywhere? Not a word about it in https://www.freepascal.org/docs-html/ref/refse85.html#x147-17100012.5 (http://Variable typecast) page.operator overloading ?
How can we tell when it is not a cast but a conversion? Why wasn't assignment compatibility of Integer to Double good enough?Basically you can't unless you know which ones are 'active'.
But Delphi compatibility would be the priority... This mess came from Embarcadero, right?No matter who or what is responsible the compatibility does it and which renders these kind of discussions completely useless imho. But that compatibility is a joke on itself (sometimes intentional, sometimes by accident).
Really? I have not seen that proof.
Wrong.You believe that ? ... I got a really good deal for you on a bridge in NY...
It is true only if it equals 1, false only when it equals zero, all other values are undefined.
It has already been shown that FPC will consider any value other than 0 to be TRUE for a boolean. That's not undefined territory, that's a FACT. That's been proved, your wishful thinking doesn't change reality.
You and/or anyone else for that matter, can claim Santa Claus exists but, it doesn't make it that way.
Hm... I have no reason not to believe that Boolean is implemented according to what is documented.Of course not. Nothing other than the program posted above.
Is this conversion behaviour documented anywhere? Not a word about it in https://www.freepascal.org/docs-html/ref/refse85.html#x147-17100012.5 (http://Variable typecast) page.operator overloading ?
DoubleVar := Int64Var;But if you explicitly use type casting:DoubleVar := Double(Int64Var);then you obviously don't expect to get the same as with simple direct assignment.
Hm... I have no reason not to believe that Boolean is implemented according to what is documented.Of course not. Nothing other than the program posted above.
You need to read the documentation again.
Free Pascal supports the Boolean type, with its two predefined possible values True and False. These are the only two values that can be assigned to a Boolean type. Of course, any expression that resolves to a boolean value, can also be assigned to a boolean type.there seems to be nothing new...
It has already been shown that FPC will consider any value other than 0 to be TRUE for a boolean.Not always.
| Bad style | Good style |
| Boolean(IntVal) | IntVal <> 0 |
| Integer(BoolVal) | Ord(BoolVal) |
| Float(IntVal) | IntVal + 0.0 |
FPC's boolean is a boolean like the Pope is a Russian astronaut.
But if you explicitly use type casting:Explicit overloading, see also here (https://www.freepascal.org/docs-html/ref/refse104.html#x224-24800015.3).Code: [Select]DoubleVar := Double(Int64Var);then you obviously don't expect to get the same as with simple direct assignment.
for something that does not exist everything is true. the Pope is a Russian astronaut. and the Pope is not a Russian astronaut.a qubit :)
Explicit overloading, see also here (https://www.freepascal.org/docs-html/ref/refse104.html#x224-24800015.3).
When doing an explicit typecast, the compiler will attempt an implicit conversion if an assignment operator is present.
However, an Explicit operator can be defined, and then it will be used instead when the compiler encounters a typecast.I have missed these things.
Really? I have not seen that proof.
No problem...
I have missed these things.Glad I could be of help (however slightly)
Not that I like this... but now I know! ;)It is another reason that renders this topic moot. It allows for the user to design its own type behaving exactly the way as user intended. Wish to create a boolean that is stored as text and can be assign as text , f.e. "PLEASEMAKETHISBOOLEANTRUE" the only accepted string to set it to true as possible implementation ? However weird, it is possible to do so.
The original code proves that FPC isn't treating the boolean parameter as a boolean but as a byte value. This is obvious because a boolean can only have the values 0 and 1, therefore it could never index the "error" string.
I have missed these things.Glad I could be of help (however slightly)
QuoteNot that I like this... but now I know! ;)It is another reason that renders this topic moot. It allows for the user to design its own type behaving exactly the way as user intended. Wish to create a boolean that is stored as text and can be assign as text , f.e. "PLEASEMAKETHISBOOLEANTRUE" the only accepted string to set it to true as possible implementation ? However weird, it is possible to do so.
Is it documented anywhere? When can we expect conversion instead of cast?It is documented on the fp-devel list at least.
Boolean vs Byte (or any other storage) is not a conflict.it shouldn't be a conflict but, FPC equates boolean to bytebool, that's a problem and a conflict because a boolean isn't a byte. A boolean can only host 2 values, a byte can host 256 values, quite a difference.
Anyway... it's rather obvious that we'll never agree just as it is obvious that FPC does not implement the boolean type.fwiw I do not see eye to eye with everything you wrote but do agree that a boolean is just that: a boolean able to contain two different states.
You are repeating yourself. Still wrong. Please "slowly" reread my earlier posts. Thanks.I was hoping that repetition would lead to understanding, unfortunately, it doesn't always work, but, it's worth a try just in case.
Found it, implicit and partially.
https://www.freepascal.org/docs-html/ref/refse85.html.
I wonder how electronic engineers think about all of this :)That is actually a good comparison to show the zero vs any other value is expected.
You are repeating yourself. Still wrong. Please "slowly" reread my earlier posts. Thanks.I was hoping that repetition would lead to understanding, unfortunately, it doesn't always work, but, it's worth a try just in case.
They are completely wrong regardless of the speed at which they are read.
You're very welcome!
Well, I admit when I was wrong. My assumption about using "very slow" was wrong. Apologies for that.You're making progress, you managed to see one of the times you were wrong. In time you might see the many other ones too.
But well it happens, and one single mistake of mine in the entire thread, well I can live with that.
Too bad there is no hope FPC will implement the boolean type correctly... oh well. can't have it all I guess.
Correct: "will implement" reference to the future. They can't do it in future, as it already has been done. No mistake (not in fpc, nor of mine in writing this).You're probably right that they can't do it in the future because if they were able to, they would have done in the past.
Correct: "will implement" reference to the future. They can't do it in future, as it already has been done. No mistake (not in fpc, nor of mine in writing this).You're probably right that they can't do it in the future because if they were able to, they would have done in the past.
Wrong mood. Not "would" but "did". Your welcome.You're just as correct as "Your welcome" which should be "You're welcome" but maybe it's just FPC English, like the FPC "boolean" thing. There is a resemblance but, it's still wrong.