Re: The IDS, the EDS and the DBMS

On Sun, 12 Sep 2004 16:33:18 -0400, "Laconic2" <laconic2_at_comcast.net> wrote:

>
>"Marshall Spight" <mspight_at_dnai.com> wrote in message
>news:%I_0d.30754$MQ5.23684_at_attbi_s52...
>> Realistically, you'd probably stick with == for equality-check,
>> to disambiguate it from assignment.
>
>Or use ":=" for assignment, freeing up "=" for equality-check.

I know this is wandering even further from the froup's topic of database theory, but ...

Maybe I'm some kind of dullard, but I've never had a problem with languages which use "=" for both assignment and equality checking. The meaning of "=" is understood by the context:

        If a = b then ...

Tests whether a is equal to b;

        a = b

Assigns the value of b to a.

The problem with context seems to arise with languages which can use an assignment as a condition, e.g.:

        if (a = b) then ...

Assiging the value of b to a and then tests a.

        if (a == b) then ...

Tests whether a is equal to b.

IMHO such assignment/testing encourages lazy programming. Yes, it's possible in the language use shorthand to say something like:

        if (fileopen("myfile",filehandle)) then ...

but something like:

	filestatus = fileopen("myfile",filehandle);
	if filestatus = 0 then ...

seems to me much clearer, and when working in a language which allows such constructs, I will nevertheless do the latter out of principle. An optimising compiler should see the two as equivalent anyway.

But it gets worse. Such languages don't just encourage lazy programming, they also offer major pitfalls for the unwary. They are much more prone to trivial clerical errors, where the programmer intended to type "if (a == b) ..." but mistakenly typed "if (a = b) ...". The compiler will accept it, and the fault may not be discovered until quite a long way into the development cycle.

Lemming

-- 
Curiosity *may* have killed Schrodinger's cat.