0

I'm currently designing a database query language and I came to wonder what should be the best syntax for the comparison operator.

Most modern languages use ==, but amongst the database languages based on SQL the = is also often used. I acknowledge that the = should have been the comparison operator whereas affectation might have been something like <- if languages had follow a more mathematic syntax, but I guess languages like C have contribued to make = for affectation a standard.

However, I'm not looking for a debate on what should be the best operator for affectation or comparison, but to know if using the same operator for two distinct things like MySQL and some other languages do is a practice to banish.

In terms of language design, using = could be a bit annoying since it is source of grammar ambiguities, since this operator is also used for affectation. MySQL seems to solve this ambiguity by introducing the SET keyword but in my case I don't see the point of introducing a new keyword where I can simply use different operators for affectation and comparison to remove the ambiguity.

So my question is : is there a real benefit to use = as comparison operator considering it is already used for affectation ?

| improve this question | |
  • 3
    In C, you could create a statement if (a = b) { ... } which meant, "assign the value of b to a and if the result is nonzero then do something". It's a perfectly valid statement, arguably does something useful, and is the source of a lot of bugs when the programmer meant if (a == b) but accidentally missed the second =. Please don't bring those days back. – Dan Pichelman Jan 20 at 12:56
  • 1
    Actually I don't think this is bad design. In C, the operator = does the affectation not the comparison. The problem resides more in the fact that the language allows to do affectations anywhere as they're considered as expressions rather than instructions. This can be used to write very beautiful code though. – ibi0tux Jan 20 at 17:08
  • Interestingly MySQL seems to use both = and := in assignments (see SO). Note that <- is much more ambiguous as a<-2 show (is it a<(-2) or a<-(2)). Finally BASIC grammar uses = for both assignment and comparison. Initially there was a LET but it quickly became optional since the grammar rules avoid ambiguity. – Christophe Jan 20 at 19:06
  • 1
    @DanPichelman And any compiler worth using will gladly warn, unless you use extra-brackets if ((a = b)). – Deduplicator Jan 20 at 22:18
2

Apart from concrete syntax details, many languages have common traits or design decisions which can be used to group them into families. One such trait is "every expression is a statement".

C is an example of such a language. Often you'll notice that such languages have a unified function/procedure concept.

Others such as Pascal have a strict separation between statements and expressions and separate keywords for procedure and function definitions.

In a language where expressions can always be used as statements, using the same symbol for assignment and equality operator isn't possible, so such languages basically require different operators. Some use =/==, others :=/= or even (early Smalltalk) ←/=.

Languages such as SQL, BASIC etc. often have assignments further distinguished from expressions by using an explicit LET or SET keyword, which often became optional in later versions.

Which style is better is a matter of taste. I generally prefer the "every expression is a statement" languages because it feels more natural to extend them. This was what drove me from Pascal to C long ago, and to Smalltalk a bit later.

However, languages which are more opinionated about statement syntax may lead to more readable code for some people.

So if you design your own, take a look what exists, think about your design decisions, show them to friends/colleagues. Just don't think there's a single right way.

| improve this answer | |
2

If your language is such that a = b could, in some particular situation, reasonably mean either, you are inviting people to mean one and get the other. Don't do this.

If there is a separation between those uses, such as SQLs distinction of UPDATE ... SET clause vs bool expressions, then there isn't a problem.

And even SQL can be confusing, e.g.

CREATE TABLE FOO (A bool, B bool);

INSERT INTO FOO VALUES (true, false);

UPDATE FOO SET A = B = A, B = B = A;

SELECT * FROM FOO
| improve this answer | |
2

Today, most mainstream languages use = for assignment and == for comparison. The main reason is that these allow an assignment inside any expression (C, C++, Java, C#, ...). Swift uses also = and == but forbids these kind of explosive mixtures to prevent bugs.

Algol, Pascal and its descendants (e.g. Ada) use := for assignment and = for comparison. The reason was symbolic/semantic not ambiguity, as Nicolas Wirth explained: for mathematicians it's uncomfortable to write = between unequal sides so a different symbol was needed. ← is frequently used for this purpose. But it didn't make it into 1965 ASCII standard. := is optically a close unambiguous match.

If your language does not allow assignments within expressions, you can very well use = without ambiguity. This was done from 1965 until now for BASIC: The assignment is a statement made of a variable followed by = followed by an expression. When = is encountered as part of an expression, it's always the comparison.

Ambiguity is not created by the symbols but by the grammar rule. Not convinced? Then, who complains about ambiguity of parentheses because they can denote arguments of a function call or a sub-expression?

| improve this answer | |
  • 2
    Go uses :=, though not always. Lisp, of course, uses = for the comparison and (let) or similar for bindings. Just other examples :) – D. Ben Knoble Jan 20 at 23:42
1

So my question is : is there a real benefit to use = as comparison operator considering it is already used for affectation ?

I can't give you a direct answer to that question.

However, unless you are targeting people who have never use a computer language before, the users of your language will have some preconceived notions about what each language construct looks like and what X = Y could mean in the current context. Those preconceived notions come from the languages they already know.

To make learning/using your language as easy as possible, you should aim for the least amount of surprise. This means, among other things, that syntax that might look familiar should have similar semantics as in the languages your users are expected to know already.
If those languages exclusively use = for affectation, then you using it (also) for comparison can lead to unneeded confusion. If using = for both purposes is already common in those languages, then there is no drawback if you do it as well.

| improve this answer | |
  • So, according to you, there's no drawback (in term of language design) to use a single operator for different purposes, it is just a matter of end developper convenience ? – ibi0tux Jan 20 at 12:26

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.