Does carp has notion of closures ?

[carp-lang]

Does carp has notion of closures ?

[eriksvedang]

I've started implementing closures in the lambdas branch. It will take a while to get right, but at least it's on it's way now.

[Gozala]

@ds2643 given that rust supports closures I don't think memory model is a limitation here, although it does certainly complicates a lot of things. There had being some discussion on what's necessary on gitter (if you want to look it up). I believe @hellerve was suggesting that lambda lifting and call site rewrites would be a path to get there, which I personally doubt as sometimes you might enclose over the heap allocated binding and that has implication on the lifetimes (linked doc on rust closures covers some of this). This is another informative article about representation of lambda in Guile scheme is it sort of goes about many different cases and bunch of rewrite optimizations and also cases where there is no way but to heap allocate it.

[eriksvedang]

That's correct, they are not implemented yet.

[ds2643]

I'm fairly new to carp, but I'm curious if the memory model presents issues with respect to support for closures. What work is necessary to support them?

[hellerve]

Just a quick FYI: after pondering this for a bit more I basically decided that the approach that I concocted wouldn’t work. I’m not entirely sure what the correct way to go forward would be, but maybe something like Larceny’s approach—I think I shared this before—could be interesting, combining closure conversion and an approach that @Gozala preferred (though it is possible that I misremember his position).

[chrisosaurus]

A closure closing over a linear term also presents a problem, as those functions would either have to also be linear, or have some smarts around their destruction.

I think mixing linear values with closures would likely mean a need for some kind of borrow checking system (how rust deals with this), even if that was a more naive escape prevention.

[eriksvedang]

I think one way to implement closures is to handle them as anonymous structs. Then all the ownership rules should still work. Rust does something like this and have a trait for callable things. Perhaps interfaces in Carp could be used to a similar effect. This would make it impossible to send closures to external C code though. Another way could be to use "blocks" in Clang (supported on Mac and perhaps on Linux..?). On Windows we could compile to C++ instead (it's better supported anyways) and use their lambdas. Still haven't thought this through completely, any better ideas are most welcome! (Btw, I think closures is the most pressing need for the language at this moment, after writing a sizeable program in it recently.)

[chrisosaurus]

Rust also has a borrow/lifetime system: If the closure can only closes over references, and cannot escape the original ownership (lifetime) of those referenes, it is safe.

If the closure can escape, then it must be created with copies/move instead, but then you have to figure out when it is safe to destroy the closed over items (and in this case, I think your struct idea works, as then we have some destruction information).

I think you could still pass those structs to C, and expose some function like CARP_call(closure_struct, arg_list) which then handled the calling so that the C program doesn't have to mess around.

What else is problematic about passing these closure structs to C?
(note that anything inside C can always screw with memory, so we cannot easily protect against that).

[hellerve]

We have closures now, and they’re ready to be played around with!

[hellerve]

Can this be closed now?

[eriksvedang]

Yes, I'll do so now! There's (at least) one big design question left but I'll open a new issue for that one.