Best compiled language for extending Ruby

[Mauricio Fernandez]

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.

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.

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.

 

[tho_mica_l]

it's just a matter of adjusting paths

I see. Thanks.

 

[MonkeeSage]

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.

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!

Regards,
Jordan

 

[M. Edward (Ed) Borasky]

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.)

The same could be said for many lower-level language features that are
"standard equipment" -- mark and sweep garbage collectors,
meta-programming, and even the "while" loop.

 

[Chad Perrin]

The same could be said for many lower-level language features that are
"standard equipment" -- mark and sweep garbage collectors,
meta-programming, and even the "while" loop.

A while loop should not make it nearly as difficult to reason about
performance as some of those other language features -- unless your
language's while is just that badly implemented.