Array.raw should take a reference

[hellerve]

Currently, the type signature of Array.raw is (Fn [(Array a)] (Ptr a)). I believe it should be (Fn [(Ref (Array a))] (Ptr a)) instead. The reason I believe that would be better is that it’s currently impossible to interface with side-effecting functions that make use of the raw memory and then getting it back in Carp. While this is supremely unsafe, it is also how a bunch of low-level C libraries operate—writing into preallocated buffers rather than allocating and returning their own. I think we should provide the means to interoperate with those libraries.

What do y’all think?

Cheers

[eriksvedang]

It makes it likely the array will be deleted pretty soon after calling raw, no..?

[hellerve]

Not really! Take crypto libraries, for instance: they generate a key for you, but you’ll have to generate the buffer. In C:

uint8_t* buf = malloc(BUF_SIZE);
my_fake_lib_generate_key(buf);
// and from here on we can use the data in buf

In carp, this is basically impossible.

My case in point is my wrapper for libhydrogen. All of the functions follow this scheme, and currently I’m using a custom C data type in Carp to support what we’re trying to do (you can look at the code here).

In short, moving the array to C does not say anything about the lifetime of the value, IMO.

[jacereda]

Maybe both variants make sense and we could have raw! in addition to raw?

[hellerve]

Actually, that’s true. I was thinking that this should be possible because it’s strictly more powerful, but the added safety benefit of the current behavior is probably worth keeping it!

[eriksvedang]

Well, it's a dangerous function either way since the current behaviour requires you to manage memory manually. Having both seems potentially useful, yes. But I think the new name should explain what makes it different a bit more.

[jacereda]

I proposed raw! because the ! seems to be used in several places to imply mutation, but I'm not particularly attached to it.

On Tue, Oct 15, 2019 at 9:04 AM Erik Svedäng notifications@github.com wrote:

Well, it's a dangerous function either way since the current behaviour requires you to manage memory manually. Having both seems potentially useful, yes. But I think the new name should explain what makes it different a bit more.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/carp-lang/Carp/issues/591?email_source=notifications&email_token=ABAAMT3DLZHTTPMS22GIJLTQOVTQVA5CNFSM4JAOV7M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBHVMIQ#issuecomment-542070306, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAAMTZBLOCC2UYCWZBE4JTQOVTQVANCNFSM4JAOV7MQ .

[hellerve]

How about unsafe-raw, then?

[eriksvedang]

Sounds like a decent name.

[GrayJack]

So what was the final decision?

• raw stays de same
• Create unsafe-raw that have this type signature (Fn [(Ref (Array a))] (Ptr a))

That's correct?

[hellerve]

Not quite; raw will stay, and unsafe-raw will be there as an additional function! :)

[GrayJack]

I updated, is it right now?

[hellerve]

That sounds right to me!