[Rd] [External] Re: stopifnot -- eval(*) inside for()

[Martin Maechler]

>>>>> Tierney, Luke 
>>>>>     on Mon, 1 Apr 2019 12:41:08 +0000 writes:

    > On Mon, 1 Apr 2019, Martin Maechler wrote:
    >>>>>>> Suharto Anggono Suharto Anggono via R-devel
    >>>>>>> on Sun, 31 Mar 2019 15:26:13 +0000 writes:
    >> 
    >> > Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval'
    >> > inside 'for' makes compiled version behave like
    >> > non-compiled version.
    >> 
    >> Ah.. ... thank you for detecting that  " eval() inside for()" behaves
    >> specially  in how error message get a call or not.

    > Don't count on that remaining true indefinitely. The standard behavior
    > is better and we'll eventually get the case where 'eval' and a few
    > others are called to behave the same.

    > Best,
    > luke

Yes, Suharto did indeed mention that it may not be a good idea
to rely on that behavior, and I did agree ... though my
agreement was a bit buried in other stuff.

Note that I have been asking if this "accidental" but internally
consistent behavior for the current situation, could not be made
a feature that the user can ask for ... without having to use a
handler (which had been a real slowdown when used inside
stopifnot() in R 3.5.3) :


  [................]
  [................]

    >> So it seems I am asking for a new feature in R,
    >> namely to temporarily say: Set the call to errors to NULL "in
    >> the following".

    >> In R 3.5.x, I had used withCallingHandlers(...) to achieve that
    >> and do even similar for warnings... but needed to that for every
    >> expression and hence inside the for loop  and the consequence
    >> was a relatively large slowdown of stopifnot()..  which
    >> triggered all the changes since.
    >> 
    >> Whereas what we see here ["eval() inside for()"] is a cheap
    >> automatic suppression of 'call' for the "internal errors", i.e.,
    >> those we don't trigger ourselves via stop(simpleError(...)).

So, for me as programmeR, it would be nice to be able to ask for
"this" behavior explicitly in a special case as here, where
"no-call" error messages are preferable .. because the call can
be really large and is known to be  "almost surely" distracting
rather than helpful.

Martin