Thank-you for the information. It was very useful. Couple of reactions FWIW:
On 8/21/07, Stefan O'Rear <[EMAIL PROTECTED]> wrote: > > Sooo.... if I was feeling "evil", could I take this c-code and pipe it > > into something that turns it into C#??? > > Yes. You could do the same with the original haskell. It's called a > compiler. Yes, that is true. However, this is also true, for an appropriate compiler, for programs such as: "Give me the first 10 numbers of the Fibonnacci (spelling?) series". The compiler can search on the internet for what is the Fibonnacci series, and/or ask its friends. In a subsequent version, a compiler could in fact compile programs such as: "Go!" ... where the compiler uses context to deduce what I want it to do ;-) Nevertheless certain compilers are easier to write than others, and writing code to automatically port ghc-generated C code is likely to be significantly easier than to compile Haskell to C#, or to .Net bytecode, from scratch. > > Name: Native code generator > Performance: 0.97 > Flags: -fasm > > GHC's own mini C compiler converts the internal C-- data into assembly > code, which is then piped to gas. Ah, hence SPJ's C-- project? > > Name: Unregisterized C > Performance: 0.40 > Flags: -unreg > > Generates near-ANSI C, using memory variables for the VM's registers and > the returning function pointer hack seen in oh so many Scheme compilers. > Good for early stages of porting, and not much else. Could be good enough. C# compiler and VM provides some optimizations which could handle this. What is the function pointer hack? Specifically, is that why you say "near-ANSI" C, rather than "ANSI C"? > > > If it contains lots of macros (or any macros at all perhaps...), this > > becomes non-trivial, > > I fail to see how macros have anything to do with this. Especially > since cpp removes them all. > > > but otherwise I think most things in C can be mapped fairly trivially > > to C#? > > Unsafe C#, sure. Haskell's type system is strictly more expressive than > C#, and you need to sacrifice either machine efficiency or checked > safety. > > > (It's a one-way mapping of course, eg "delete" in C is simply dropped > > when mapped to c#). > > There is no delete in C, and even if there was, GHC wouldn't use it. > Allocation is *the* major bottleneck of functional programs, and having > a custom allocator inlined into every call site is vital to have usable > performance. > > > (Not that I have any good reason to do this, simply... fun). > > Stefan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGyur/FBz7OZ2P+dIRAleTAJ9WiK8tCp0QZE4syG4BZk5EFm1FuQCgzYGK > NUv22zY5IgeqkEJ5kL3yriQ= > =0Xkq > -----END PGP SIGNATURE----- > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe