> > 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
···
On Dec 19, 5:42 pm, Mauricio Fernandez <m...@acm.org> wrote:
On Wed, Dec 19, 2007 at 08:45:04PM +0900, tho_mica_l wrote:
