[Rd] [R] incoherent conversions from/to raw

[Martin Maechler]

>>>>> "WK" == Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no>
>>>>>     on Thu, 19 Mar 2009 10:17:20 +0100 writes:

    WK> Wacek Kusnierczyk wrote:
    >> interestingly,
    >> 
    >> c(1, as.raw(1))
    >> # error: type 'raw' is unimplemented in 'RealAnswer'
    >> 
    >> 

    WK> three more comments.


    WK> (1)
    WK> the above is interesting in the light of what ?c says:

    WK> "
    WK> The output type is determined from the highest type of the
    WK> components in the hierarchy NULL < raw < logical < integer < real
    WK> < complex < character < list < expression.
    WK> "

    WK> which seems to suggest that raw components should be coerced to whatever
    WK> the highest type among all arguments to c, which clearly doesn't happen:

    WK> test = function(type)
    WK> c(as.raw(1), get(sprintf('as.%s',type))(1))

    WK> for (type in c('null', 'logical', 'integer', 'real', 'complex',
    WK> 'character', 'list', 'expression'))
    WK> tryCatch(test(type), error = function(e) cat(sprintf("raw won't
    WK> coerce to %s type\n", type)))

    WK> which shows that raw won't coerce to the four first types in the
    WK> 'hierarchy' (excluding NULL), but it will to character, list, and
    WK> expression.

    WK> suggestion:   improve the documentation, or adapt the implementation to
    WK> a more coherent design.

Thank you, Wacek.

I've decided to adapt the implementation
such that all the above  c(<raw> , <type>)  calls' implicit
coercions will work.


    WK> (2)
    WK> incidentally, there's a bug somewhere there related to the condition
    WK> system and printing:

    WK> tryCatch(stop(), error=function(e) print(e))
    WK> # works just fine

    WK> tryCatch(stop(), error=function(e) sprintf('%s', e))
    WK> # *** caught segfault ***
    WK> # address (nil), cause 'memory not mapped'

    WK> # Traceback:
    WK> # 1: sprintf("%s", e)
    WK> # 2: value[[3]](cond)
    WK> # 3: tryCatchOne(expr, names, parentenv, handlers[[1]])
    WK> # 4: tryCatchList(expr, classes, parentenv, handlers)
    WK> # 5: tryCatch(stop(), error = function(e) sprintf("%s", e))

    WK> # Possible actions:
    WK> # 1: abort (with core dump, if enabled)
    WK> # 2: normal R exit
    WK> # 3: exit R without saving workspace
    WK> # 4: exit R saving workspace
    WK> # Selection:
 
    WK> interestingly, it is possible to stay in the session by typing ^C.  the
    WK> session seems to work, but if the tryCatch above is tried once again, a
    WK> segfault causes r to crash immediately:

    WK> # ^C
    WK> tryCatch(stop(), error=function(e) sprintf('%s', e))
    WK> # [whoever at wherever] $

    WK> however, this doesn't happen if some other code is evaluated first:

    WK> # ^C
    WK> x = 1:10^8
    WK> tryCatch(stop(), error=function(e) sprintf('%s', e))
    WK> # Error in sprintf("%s", e) : 'getEncChar' must be called on a CHARSXP
  
    WK> this can't be a feature.  (tried in both 2.8.0 and r-devel;  version
    WK> info at the bottom.)

    WK> suggestion:  trace down and fix the bug.

[not me, at least not now.]


    WK> (3)
    WK> the error argument to tryCatch is used in two examples in ?tryCatch, but
    WK> it is not explained anywhere in the help page.  one can guess that the
    WK> argument name corresponds to the class of conditions the handler will
    WK> handle, but it would be helpful to have this stated explicitly.  the
    WK> help page simply says:

    WK> "
    WK> If a condition is signaled while evaluating 'expr' then
    WK> established handlers are checked, starting with the most recently
    WK> established ones, for one matching the class of the condition.
    WK> When several handlers are supplied in a single 'tryCatch' then the
    WK> first one is considered more recent than the second. 
    WK> "

    WK> which is uninformative in this respect -- what does 'one matching the
    WK> class' mean?

    WK> suggestion:  improve the documentation.

Patches to  tryCatch.Rd  are gladly accepted
and quite possibly applied to the sources without much changes.
Thanks in advance!

Martin Maechler, ETH Zurich