I immediately thought "'and then' surely?" And realised that I was showing my Ada '83 heritage...
Nearest I get to cutting code nowadays is html, but obviously still default to the short-circuit operators as per the LRM. I'm sure this says *something* about me, but what exactly eludes me..
I'm confused about the Ada '83 reference. I know nothing about Ada in particular, but isn't the concept of a short-circuit boolean operator with an explicit sequencing constraint common to many languages? Certainly including (for instance) C, Perl and sh. Is it different in some way in Ada? (Or have I misunderstood your entire point?)
One thing that Ada (83 certainly, I couldn't say about 95) does - that Other languages don't - is that by default redundant checks in ANDs and ORs aren't bypassed as soon as one fails/passes unlike every other language under the sun (hell, even Prolog) - Ada values consistency (especially of any other effects that the functions may have) so if you *want* to allow short-circuit, and the run-time savings that this allows, then you have to specify AND THEN or OR ELSE in place of AND and OR.
(As I confused you I'm over-explaining here for the benefit of anyone else.)
What tickled me was that mental consideration of the use of AND THEN and OR ELSE where AND and OR is found in code is a habit, certainly of this coder - and is obviously one that I still have in me after (thinks) over ten years since I last touched Ada.
(But now you've said it, so I know what to look for, it appears that Ada 95 hasn't changed this. Unsurprising, really, if the whole point was consistency :-)
no subject
no subject
git, but it's a fairly general rant that I've had brewing for a while...no subject
Nearest I get to cutting code nowadays is html, but obviously still default to the short-circuit operators as per the LRM. I'm sure this says *something* about me, but what exactly eludes me..
no subject
no subject
One thing that Ada (83 certainly, I couldn't say about 95) does - that Other languages don't - is that by default redundant checks in ANDs and ORs aren't bypassed as soon as one fails/passes unlike every other language under the sun (hell, even Prolog) - Ada values consistency (especially of any other effects that the functions may have) so if you *want* to allow short-circuit, and the run-time savings that this allows, then you have to specify AND THEN or OR ELSE in place of AND and OR.
(As I confused you I'm over-explaining here for the benefit of anyone else.)
What tickled me was that mental consideration of the use of AND THEN and OR ELSE where AND and OR is found in code is a habit, certainly of this coder - and is obviously one that I still have in me after (thinks) over ten years since I last touched Ada.
Ada: Love it or hate it, but it leaves its mark.
no subject
(But now you've said it, so I know what to look for, it appears that Ada 95 hasn't changed this. Unsurprising, really, if the whole point was consistency :-)