Best compiled language for extending Ruby

Ruby
21

On Dec 19, 4:58 am, Mauricio F. [email protected] wrote:

about this for eigenclass.org, but I’m dropping more and more posts as of late
(I must be around ~75% rejection rate or so, and worsening).

Heh. Just don’t let it get to 100%. I enjoy reading your blog.

rocaml should be usable on Win32 after some work in the Makefile generation
forward to the result of the attempt to bring type classes to OCaml.
How do you feel about the strict vs. non-strict semantics? One thing I love
about OCaml is that I can know what is happening under the hood and there are
no bad surprises (bad performance or unexpectedly high memory consumption).

I was just being silly, since Haskell is “pure” (and “pure” ==
“greatest” :wink: because it separates functions and “actions”. In
actuality, I like the fact that OCaml lets me use reference types and
imperative programming when I feel it best suites the problem.

I’ve only been using Haskell for about six months, and I’ve not delved
too deeply into theory (Curry-Howard isomorphism, existential types,
and so forth). So I can’t really say on any technical level what I’d
be missing (if anything) by using OCaml rather than Haskell.

List comprehensions are nice, but not essential (there is a camlp4
module for list comps in OCaml [1], but I’ve not tried it). Syntax
isn’t a big deal, and the “revised syntax” is pretty close to Haskell
(there is also Mike Lin’s preprocessor [2] for using the off-side rule
rather than parens / begin…end for statement grouping). One big
difference is obviously type classes, but so far I’ve found generic
functions provide enough polymorphism for what I’ve been doing, and
haven’t needed overloading. However, I do miss it for the overloaded
functions defined in the Prelude, which save from explicit type
conversions and and type-specific operators – it’s nice to be able to
say “10 / 2.0” and get “5.0” instead of “this has type float but is
used with type int”. :wink:

I agree about laziness having fangs (and I almost always use the
strict Data.ByteString.Char8 for example), but over-all I like it for
the reasons given by SPJ [3] (my favorite of which is: “Laziness is
jolly convenient”, heh). But (aside from implementation details) since
I can generate a thunk in OCaml with the lazy keyword and can build
the same kind of lazy data structures [4], strict vs. non-strict
semantics seems like a moot point. In Haskell you have to explicitly
tell a function to be strict, in OCaml you have to explicitly tell it
to be lazy. Six of one, half-dozen of the other. :slight_smile:

[1]
http://www.univ-orleans.fr/lifo/Members/David.Teller/software/comprehension/
[2] "The Whitespace Thing" for OCaml
[3]
http://research.microsoft.com/~simonpj/papers/haskell-retrospective/
[4]
http://enfranchisedmind.com/blog/2007/01/01/ocaml-lazy-lists-an-introduction/

[1] The inability of ocamlopt (up to 3.09.2 or so, 3.10.0 can on some
platforms) to generate PIC code is not a problem on win32, see [274896].
The next release of OCaml will feature dynamic loading of native code.

–
Mauricio F. - http://eigenclass.org

Regards,
Jordan

22

it’s just a matter of adjusting paths

I see. Thanks.

23

On Dec 19, 5:42 pm, Mauricio F. [email protected] wrote:

fairly easy work that requires access to the platform, however.
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 :wink: 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! :wink:

–
Mauricio F. - http://eigenclass.org

Regards,
Jordan

24

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.

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.

25

MonkeeSage wrote:

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. :slight_smile:

26

On Thu, Dec 20, 2007 at 11:21:45PM +0900, M. Edward (Ed) Borasky wrote:

MonkeeSage wrote:

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. :slight_smile:

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.