Re: Short circuit boolean evaluation

["Steve" <nospam_steved94@comcast.net>]

"svaa" <svaa@ciberpiula.net> wrote in message
news:87f5a614.0311061144.360b3325@posting.google.com...
> "Steve" <nospam_steved94@comcast.net> wrote in message
news:<Vwjqb.115053$HS4.999172@attbi_s01>...
> > I consider it unimaginable to make such a fundamental change to a
language
> > in order to save a few keystrokes when more than a few billion lines of
> > source code might be effected.
>
> I wouldn't call it a few  keystrokes, I use it in every condition.
>
> Anyhow, that's not the problem, the problem is that short-circuit has
> clearly proved to be better...

That is a very strong statement.  Especially when you consider cases
where you are forcing in-order execution, essentially restricting the
compiler from generating code that might otherwise execute in parallel.

Of course in either case the compiler may determine that the result is the
same regardless of the order of execution and do the most efficient thing.

> clearly proved to be better, I supose that the idea of Ada0x is to add
> new features and remove flaws. Backward compatibility is a problem,
> but it could be resolved with pragmas etc. Most sofware have eventualy
> made changes that had backward compatibility problems. Probably a big
> problem with backward compatibility means a big improvent for future
> developments.

You appear to be stating that having control whether expressions use
short circuit evaluation or not is a flaw.   I disagree.  In fact I think
the
ability to express how you want things evaluated is a strong point of
the language.  It leads to fewer suprises.

> Sure we can live with full evaluation, but we can live better with
> short circuit. If we accept that short circuit is better than full
> evaluation...

Which I do not.

> the change must be done, sooner or later. This time is as
> good or bad as any another.

> Perhaps Ada0x could let the full evaluation as default, but add a
> pragma that allows short circuit, and in ada1x make it as default. (it
> doesn't means make illegal "and then" operator). Ada has fame of
> bloated and burden syntax, things like this doesn't help. I think it
> is time and make good changes, even if they are deep. It's not time to
> be conservative, but brave.

I would rather keep the so called "bloated syntax".

Incidently.  When moving a bunch of Pascal code to Ada, I was somewhat
suprised at how many bugs came up due to the weaker typing in Pascal.  Not
only bugs, but in some cases serious performance issues.

Coming from Pascal, you probably find it a drag that you have to explicitly
do time conversions in expressions.  I found one routine in the middle of a
fitting
procedure that was converted from Pascal to Ada using an automated tool.
When
I saw the amount of conversions happening between types to perform
operations
I was amazed.  I re-coded the procedure to turn things into a common type up
front
before doing the bulk of the work.  The routine was more than 2X faster.  I
went
back with my new found wisdom and changed the types used in the Pascal code
(just
out of curiousity).  I saw the same speed up there as well.

There is a lot to be said for being able to see exactly what is going on.
As well
as having the control to specify exactly what you want to happen.

Steve
(The Duck)

> Will we carry "and then" in ada5x? Will we accept that flaw (a minor
> flaw, but a flaw) in the first version must remain for ever?.