> Why do you say that people who compile, e.g., functional languages > would benefit from type variables in LLVM? > I like the level the LLVM is at, and would prefer to deal with > instantiating parametric polymorphism at a higher level.I'm surprised you're happy with a non-polymorphic llvm. Does Cayenne target llvm? Dependent types take polymorphism to new heights -- but perhaps you feel that since llvm cannot hope to match Cayenne, you might as well do everything yourself. :-) My reasons are: First, if type variables are handled at the higher-level, then every functional language will have its own implementation. It will not be possible to define and reuse optimization passes between languages, which is one of the goals of llvm. Second, polymorphism can be made more efficient if it has low-level codegen support -- see my earlier offset code. Third, any language which has polymorphism is faced with the task of ``erasing'' it before it can hand the code to llvm. Such erasure can be done in different ways -- compare Java type erasure (use pointers, instantiate nothing), with C++ (instantiate everything), with .Net (instantiate some things). (I don't know how Ocaml does it) It is very difficult to share code between languages if the erasure semantics differ so widely. -DeLesley
On Wednesday 18 February 2009 23:36:27 DeLesley Hutchins wrote:> > Why do you say that people who compile, e.g., functional languages > > would benefit from type variables in LLVM? > > I like the level the LLVM is at, and would prefer to deal with > > instantiating parametric polymorphism at a higher level. > > I'm surprised you're happy with a non-polymorphic llvm. Does > Cayenne target llvm? Dependent types take polymorphism to new > heights -- but perhaps you feel that since llvm cannot hope to > match Cayenne, you might as well do everything yourself. :-) > > My reasons are: > > First, if type variables are handled at the higher-level, then every > functional language will have its own implementation.No, they just need to share a HLVM.> Second, polymorphism can be made more efficient if it has low-level > codegen support -- see my earlier offset code.In theory, perhaps.> Third, any language which has polymorphism is faced with the task > of ``erasing'' it before it can hand the code to llvm. Such erasure can be > done in different ways -- compare Java type erasure (use pointers, > instantiate nothing), with C++ (instantiate everything), with .Net > (instantiate some things). (I don't know how Ocaml does it) It is very > difficult to share code between languages if the erasure semantics differ > so widely.The same can be said of closures, garbage collection and a dozen other features that also cannot feasibly be added to LLVM. The only logical solution is to build a HLVM on top of LLVM and share that between these high-level language implementations. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e
> The same can be said of closures, garbage collection and a dozen other > features that also cannot feasibly be added to LLVM. > > The only logical solution is to build a HLVM on top of LLVM and share that > between these high-level language implementations.This is an excellent point. You have convinced me. :-) BTW, what garbage collector are you using for your HLVM? You complain about mono's use of the Boehm-Weiser collector on your blog; but you also said that you assumed an uncooperative environment. I'm not a GC expert, so why are the current GC intrinsics insufficient? -DeLesley