Re: Best compiled language for extending Ruby

On Dec 19, 5:42 pm, Mauricio Fernandez <[e-mail]> wrote:
> On Wed, Dec 19, 2007 at 08:45:04PM +0900, tho_mica_l wrote:
> > > AFAIK, rocaml could in principle[1] work on
> > > Win32, at least with the MinGW and cygwin builds of Ruby and OCaml
>
> > May I ask if somebody has succeeded in building rocaml on cygwin?
>
> Well, you don't actually build rocaml itself, but rather use it to build Ruby
> extensions written in OCaml. rocaml does essentially two things: generate the
> C wrappers and create a Makefile. The logic behind the latter is what needs to
> be adapted to the platform.
>
> I'm not aware of anybody having used rocaml on cygwin. Some changes to
> rocaml_extconf.rb (think of it as an extension to the common extconf.rb and
> mkmf.rb) would be required in things like:
>
> ocaml_native_lib_path = %w[
>   /usr/lib/ocaml/**/libasmrun.a
>   /usr/local/lib/ocaml/**/libasmrun.a
> ].map{|glob| Dir[glob]}.flatten.sort.map{|x| File.dirname(x)}.last
>
> As you see, it's just a matter of adjusting paths, compiler flags and so on:
> fairly easy work that requires access to the platform, however.
>
> > > What do you miss when you're doing OCaml instead of Haskell
>
> > Eager vs lazy evaluation makes some difference, I'd suppose.
>
> Yes; what I wanted to know is in which direction :). I understand that lazy
> evaluation is not something you necessarily miss, as it's got some associated
> costs (as MonkeeSage said, if Haskell has strictness annotations, OCaml has
> got lazy expressions, so we're concerned with the default evaluation
> strategy). I've found contradicting opinions about the difficulty of analyzing
> the behavior of programs under lazy evaluation: some people say only newbies
> are bitten by that, others reply that even Haskell experts bump into puzzling
> cases where seemingly minor changes can affect performance greatly, in both
> directions.

I think it's safe to say that it can (and does) bite everyone, since
the designer of the language says: "Laziness makes it much, much
harder to reason about performance, especially space." (SPJ, op. cit.)

> Likewise, I was wondering if somebody versed in Haskell will find impure
> languages painful, or if some side effects here and there will be considered
> acceptable.

From what I've gathered from reading LtU and other sources, the main
point of containing side-effects in monads is that it makes it easier
to prove the program (the whole "program as proof" bit). So I guess it
depends on whether you're trying to write a correctness / theorem
prover (all 10 people doing that, heh ;) or trying to write an actual
systems application (the rest of us), as to whether you find a
doctrinaire separation of side-effects helpful. I mean, despite
contrary exclamations, monads are simple (they only have to satisfy
three basic equations, or two if you want to be lazy -- pun intended),
but when you get into stuff like the state transformation monads, it
gets somewhat more complex. At least I'm too dumb to understand it
easily (but that's not saying much). But a reference type and a loop
construct? Gimme a break...even C programmers can grasp that! ;)

> --
> Mauricio Fernandez  -  http://eigenclass.org

Regards,
Jordan