>>>>> 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
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
