
Porting a Haskell graphics framework to Rust - chiachun
http://phaazon.blogspot.com/2016/04/porting-haskell-graphics-framework-to.html
======
nickpsecurity
Fascinating that a Haskell tool mapped so well to Rust. Might make it easier
to do seL4-style developments with Rust given they simultaneously do a Haskell
model and C code w/ equivalence proof. A Haskell subset that uses whatever
verification & testing tools they have might be extracted to an equivalent
Rust program automatically or with manual guidance. The assertions or tests
would be extracted for equivalence testing. That might have significant safety
and maintenance benefit even without HOL parts.

What do the Rust people think of that idea? And how hard would you guess an
AutoCorres-style tool be for it vs C in event we wanted HOL parts?

~~~
vvanders
The one thing that's tripping me up on Rust from doing everthing in a purely
functional way is the way closures are dealt with. I really hate the idea that
I'm going to need to Box::new() every closure I pass around if I want to
return it from a function or store it. Even simple move closures can't be
cloned and makes some things that are simple in Haskell/Elm/etc much more
painful.

Don't get me wrong, great language but I'm a but dubious of the 1:1 porting
story here.

~~~
dbaupp
Closures in other languages like Haskell, JavaScript and Python (and almost
certainly Elm too, I've never used it and hence don't know for sure) are
similar to the `Rc<Fn(...) -> ...>` type in Rust. In fact, if absolutely
necessary, one could probably use that everywhere.

Stuff like this is one of the trade-offs in Rust: control over exactly how
closures behave (if allocations are necessary, if virtual calls are necessary
when calling it) is balanced with/detracts from how much typing one needs to
do to get them to work.

~~~
vvanders
Duh, dunno why I'd forgotten Rc.

I'm still not a huge fan of the extra allocation(and chance for cycles) but I
stand corrected that it does work, kudos.

