From: Robert Feldt <feldt@...>
Date: 2001-11-26T16:57:09+09:00
Subject: [ruby-talk:26488] Re: generating and serving SVG

On Mon, 26 Nov 2001, MikkelFJ wrote:

> > Out of curiosity could you mention the other languages you considered in
> > the same deal? You seem to have done a pretty extensive survey.
> 
> Ruby didn't enter the competition because it wasn't fast enough, uses too
> much memory and is difficult to create standalone solutions in (script
> only). But it is expressive - just needs an easier way to handle higher
> level functions. Given a fast Ruby compiler I still think I'd choose OCaml
> over Ruby for some problems, but Ruby would then be a serious competitor as
> a preferred language for most problems.
> 
I'd also really like to see a Ruby-to-native compiler and I'm doing some
experiments to find a feasible path there. Do you know the state of the
art of general, useable and powerful back-ends. I've looked into C-- but
don't think its mature enough yet, gcc back-end seems complicated and
undocumented, BEG and BURG are a bit old and unsupported (I haven't
studied them in depth), GNU lightning not much used and only tested on
x86. An option is to compile to C but more control, simpler and possibly
more long-term performance by skipping the additional step. Any thoughts?

> In the end I was convinced that OCaml is almost as powerful in any of the
> aspects that the other languages shines in. OCaml does not have a nice macro
> system as Lisp, but it does have a very powerfull preprocessor, that is just
> as powerful if not more, just more complicated to use. I is not dynamically
> typed as Lisp is. This should complicate writing easy maintainable code
> (note that this is where Ruby is also very strong). However the combination
>
Yes, isn't expressiveness and easy maintainability two of Ruby's most
prominent features? I tend to think so. 

> Independently of the distribution, OCaml generates assembler text files and
> calls upon the system specific assembler to create an object file and
> subsequently links to other modules using the system linker. As an
> alternative OCaml generates bytecode but uses the same system libraries. I
> reckon that Ruby could learn something from how OCaml deals with the cross
> platform issues as it is both compiled and bytecode based.
> 
Very interesting; I'll look into the sources. Sounds like a great design.

> Lazy streams. In the end I'm not so fond of embedded languages. I'd rather
> write a parser that parses the domain language into an implementing
> language, so whether you target OCaml, Haskell, or Clean, the underlying
> syntax doesn't matter much.
> 
I think a good solution is to supply both. With an embedded language you
get simplicity and flexibility. For example in parsing, you can easily
create a parser and directly use it without going through a generation
phase. And you can parse difficult things (context-sensitivity etc) since
you have the full power of a programming language if needed. With the
parser combinators you can then implement a parser for a clean grammar
description language and then generate code (either using the embedded
parser comb language or by skipping that step). IMHO, you get the best of
both worlds. BTW, this is the approach I'm taking with Rockit.

> Caml language (I left out the 'O' on purpose). The preprocessor p4 allows
> you to make all kinds of new concepts that are rewritten into Caml before
> being compiled.
> They wrote the precossor to help making language research easier.
> 
This sounds interesting. Can you give an example of what can be done with
p4?

Maybe we should build a rubyp4/rubypp with one of the RubyInRuby
parsers? It would be nice to play with selector namespaces, multi-methods,
aspect weaving etc. Sure much can be done in Ruby itself because of its
dynamic nature but not everything (since the meta-model is limited) and
we'd gain performance (important for example in apsect-implemented
profiling).

> > Especially I'd be interested in documentation on the OCaml code
> > generator. Could be something to ponder for RubyVM.
> 
> I think OCaml is very interesting as a base for a Ruby compiler or VM.
> Mostly compiler because of the machine language generation. The VM is
> probably rather different.
> 
Yes, I agree. I'll look some more at the back-end stuff.

> I have earlier mentioned C-- as a possiblity for the core of a Ruby
> compiler - looking at the OCaml source it appears that C-- lives somewhere
> in the internals of the OCaml compiler - not sure how much though - but the
> idea is the same: multiple targets from internal representation.
>
Yes, its strange. I found lines like:

(* From C-- to assembly code *)

in the OCaml back-end. Are they really refering to the C-- at
cminusminus.org? I've mailed Xavier Leroy and asked; I hope he answers.

> But then I think you could actually compile most of Ruby to OCaml. However,
> I'd rather wait until support of generics is more complete.
> 
Sounds like an interesting undertaking. We should continue discussing
this. I'll be back after checking out OCaml in more depth.

> > Since I found Clean I'm
> > considering using it over Haskell. Seems to be few drawbacks and quite a
> > few advantages.
> If you can live with the platform restrictions and do not need any features
> not currently available, Clean is definitely a good choice. Better
> development platform and many good examples of how to create real
> applications.
>
Yes, and exe's are smaller and faster. I've talked to the Clean team about
the lock-in problem of having to use their IDE; they sent me programs from
the 2.0 system so that I can now use the Clean compiler, generator and
linker from the command line => use my ordinary IDE/env. Its awkward but
works. If they'll live up to their goal of releasing 2.0 as an open-source
system before years-end Clean is still "in my ball-park".

> > > OCaml and Ruby have very compact code as a common denominator. Apart
> from
> > >
> > Yeah, but IMHO Clean would probably beat them both?!
> 
> I'm not sure. If you count the signature files (.mli) of Ocaml, Clean may
> have an edge - but then Cleans module system is inferior to ML's (which is
> also the basis for OCamls module system).
> In Clean you have to write more type info for each function which takes up
> space but makes the code more readable. Clean may be more to much compact by
> utilizing laziness - when you really can exploit that.
> I think it is splitting hairs. In any case both Clean, Ruby and OCaml are
> very compact.
>
Ok, you're probably right. My impression was that Clean has a type
inference system much like ML but maybe I'm wrong.

> I hate that OCaml forces you to write the types twice when using
> signatures - that is exactly one of the things a wanted to leave behind in
> C++, and which is one of Ruby's forces. But you can't have it all, and the
> ML module system is really powerful so you get something in return - not
> mentioning the forthcoming generics of OCaml.
>
Couldn't you handle that with the preprocessor?

Regards,

Robert