From: MikkelFJ Date: 2001-11-27T07:27:20+09:00 Subject: [ruby-talk:26564] Re: generating and serving SVG "Robert Feldt" wrote in message news:Pine.GSO.4.21.0111260813480.8609-100000@godzilla.ce.chalmers.se... > 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 I did some research - I don't know much about the gnu backend, but like you, my conclusion was that it would be difficult to use. There were another compiler backend project (maybe thats the BEG/BURG you mention). I didn't keep a link because it was discontinued - I think some of the work were continued in C--. Apart from the ones mentioned there are the Microsoft Intermediate Language (MSIL) for their new .NET platform, and there is the SML codegeneration platform named MLRisc or something - it's actively developed and makes performance progress as I've understood. Milton is a SML dialect that compiles to C which shows decent performance and good portability. A problem with C is you need to control the compiler which essentially limits you to either supporting GCC only, or hope for the best. Personally I'd rather avoid compiling to C, but I do see the advantages, especially when targetting special platforms. > > 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 If you are doing research, embedded languages are great, but for production quality I'd be hesitating doing it. Actually the camlp4 preprocessor is halfway a frontend compiler doing a mix between embedded langauge and frontend compilation - you decide how much to hide of the original language, and how much to add. You are still bound by some overall semantic constructs no matter the amount of syntactic sugar. > This sounds interesting. Can you give an example of what can be done with > p4? http://caml.inria.fr/camlp4/tutorial/tutorial004.html Here they create a new syntax for OCaml that is somewhat cleaner. > Maybe we should build a rubyp4/rubypp with one of the RubyInRuby > parsers? I've thought about it - as I said I'd need better generic support first. Otherwise you'll certain problems with dynamic typing. Even with generics you'd probably have some problems but most Ruby programs would compile and many others could be rewritten so that they would. The generics also support dynamic typing which is crucial for supporting Ruby. I'd say that the work the OCaml people is doing here could take many years to accomplish in Ruby - so Ruby could be used as a cleaner OCaml syntax. A first go would probably be a reduced Ruby grammar. > 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. Let me now what you learn. > Ok, you're probably right. My impression was that Clean has a type > inference system much like ML but maybe I'm wrong. Well I'm no expert in any of the languages - it's just my immediate impression. > > > I hate that OCaml forces you to write the types twice when using > Couldn't you handle that with the preprocessor? Not really because it spreads on two files - it's not a C-style include preprocessor. On the other hand the very same feature allows you to heavily reuse code with paramaterized types over an entire module (functors), so in that sense it does save you some work in the long run. You also don't have to write the ..mli signature files if the types are only used within the same file. I have been instructed "to learn to love the module system". I'm trying, and I think that I will succeed eventually :-) I'm still very new to the language. BTW: a very good on OCaml in french published on O'Reilly is being translated and will eventually emerge in english online and possibly as a book: http://www.pps.jussieu.fr/Livres/ora/DA-OCAML/index.html