[Rd] RFC: rawConnection (was "loop connections")

[Duncan Murdoch]

dhinds at sonic.net wrote:
> Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> 
>>>Having a rawConnection() entry point is simple enough.  Seeking also
>>>seems straightforward.  I'm not so sure about using as.raw().  I
>>>wondered about that, but also thought that rather than coercing to
>>>raw, it might make more sense to cast atomic vector types to raw,
>>>byte-for-byte.
> 
> 
>>I'd prefer as.raw, so that we don't end up with two incompatible ways to 
>>convert other objects to raw objects.
> 
> 
> An advantage of no as.raw() would be that you could create a raw
> connection on an object without making an extra copy, which was
> another of your requests.  But there would be a lack of symmetry,
> because you could "r" from an arbitrary R object, but only "w" to raw,
> unless there was also a way of specifying a type for the result
> vector.

I think the cost of duplicating as.raw is worse than the cost of using 
extra memory.  If the lack of symmetry bothers you, a solution is to 
require a raw object as input.

> Having the backing store be an R object with no copy does seem tricky,
> however.  

In that case I wouldn't bother.  It's important to get it right; being 
maximally efficient is a second priority.

 > Currently, textConnection() makes a copy for "r" connections
> but writes directly to an R object for "w" connections.  The "w" case
> is buggy; you can crash R by removing the target object while the
> connection is being used.  I'm not familiar enough with R internals to
> know how to fix that.  Maybe the object has to be searched for every
> time the connection is used, to avoid potentially stale pointers?

I've been having an argument with some other people about something 
related to this.  I think they would say that the language doesn't 
support writing to a variable.

I don't know the right way to fix this.
> 
> 
>>>Can you given an example of where a text-mode raw connection would be
>>>a useful thing?
> 
> 
>>No, but someone else might.  Why unnecessarily let the source of the 
>>bytes determine the mode of the connection?  In the case of 
>>textConnection, there are natural line breaks, so a text mode connection 
>>makes sense.  A raw object can contain anything, so why wouldn't someone 
>>want to put text in it some day?
> 
> 
> It seems that that a text-mode raw connection would be equivalent to a
> textConnection on the result of rawToChar(), no?

If so, then a binary mode rawConnection (with mention of the way to 
convert in the Rd file) would be good enough for me.


> 
> While some of these possibilities seem like they might be useful, I'm
> not sure that all need to be implemented immediately.  If we can agree
> on the basic interface and semantics, then we could implement a basic
> version now, and relax restrictions on the arguments later as needed?

I'd rather get it right now, but that doesn't have to mean including 
every bell and whistle someone (even me!) has suggested.

Duncan Murdoch