[Ur] Strategy - UrWeb Backend

[Marc Weber]

> My position is that the total time the whole Ur/Web community spends 
> writing libraries to access with the FFI should be negligible compared 
> to the time spent writing the main applications.  Sure, it can be a pain 
> to get C code right, but it's probably worth it, given the long-term 
> performance gains.  Reasonable people may disagree on this.
> 
> I find it very encouraging that an informed developer besides me (i.e., 
> you :]) was able to wrap a Ruby interpreter so easily.  I personally 
> would be more inclined to build an ML or Haskell interface,
I thought about Haskell. But interfacing would have been more
complicated. This way you can use Ur to create Ruby objects and read
them easily - the way you serialized JSON objects.

There is no C function haskell_list_cons(head, tail) you can call AFAIK.

In ruby you can do:

uw_Ruby_return_dummy_arrray(...){
  VALUE i = rb_int_new(20);
  VALUE ar = rb_ary_new();
  rb_ary_add(ar, i);

    // prevent them from being garbage collected by ruby gc:
    protect_value(i);
    protect_value(ar);

   return ar;
}

Because ruby is dynamic you can pretty easily wrap almost everything
without coding more C.

Of course you could have written yet another tool to generate AGDTs for
both: Haskell and UR.. But I want to keep thinks simple.

If ruby failed I maybe would have tried racket - or tried getting my job
done using Haskell. I don't know. It seems that I'm very close so I do
no longer think about it.

Marc Weber