[fpc-pascal] New feature: IfThen() intrinsic
Henry Vermaak
henry.vermaak at gmail.com
Tue Feb 2 13:45:52 CET 2016
On Tue, Feb 02, 2016 at 01:12:25PM +0100, Michael Van Canneyt wrote:
> On Tue, 2 Feb 2016, Henry Vermaak wrote:
> >So you are saying that relying on all function arguments being
> >evaluated is bad?
>
> I am saying that the difference between this behaviour and the
> behaviour where they may not all be evaluated is so subtle that many
> (I am tempted to say most) programmers will never even know the
> difference.
I'm sure most programmers will know that in foo(doa(), dob()) both doa()
and dob() will be executed. I agree with what you said about the order
of evaluation (it's undefined behaviour), but you said that your points
still stand for whether arguments are evaluated at all. This doesn't
make any sense, how would the compiler decide what to evaluate and what
not?
> It is simply over their heads.
>
> Even Graeme - who has a lot of mileage in programming - was confused
> as to "why all the fuss" till I explained with a simple example.
I think there may be a misunderstanding. I'm very confident Graeme
knows that all the arguments to a function gets evaluated and that a
branch of an if statement won't be evaluated. Maybe he was confused by
wrapping up the behaviour of an if statement into something that looks
like a function?
> I'm just trying to to put any foaming-at-the-mouth argumentation using
> this particular argument in perspective.
I've tried to express my concerns about this in a civil way, but I
apologise if anything I've said came across otherwise.
> For a correct understanding: The compiler must behave predictable at
> all times, no arguing there. But I don't think that iif() having
> different semantics than all other functions, is a problem. It just
> needs to be documented properly. It is a non-issue for me.
>
> To give more perspective: The same is true for Writeln() and Assert(),
> which also have are different semantics, but this difference is simply
> documented (if at all). I didn't hear anyone protesting that. The
> fact that it is so in the pascal standard doesn't make a iota of
> difference; the standard was most likely simply made after the facts.
Exceptions to standard behaviour is bad, just because there are
exceptions doesn't mean that we need to create more of them.
Documenting something doesn't make the behaviour intuitive.
Henry
More information about the fpc-pascal
mailing list