similar to: [LLVMdev] Parametric polymorphism

> I think the problem is deeper than that, in that LLVM has no official > concept of a subtype, so I don't see how the idea of polymorphism > could be defined in it. Parametric polymorphism is different from subtype polymorphism; you can have one without the other. Parametric polymorphism just means that you can use type variables (like T) in the IR, which are later instantiated to

> I think many people were confused by this at first but an excellent counter > example was provided in a previous thread: C99 ABIs can require that struct > return values are returned via a pointer to a preallocated struct passed as > an auxiliary argument *except* when you're talking about a C99 complex, in > which case the return value is conveyed in a completely different

On Wed, Feb 18, 2009 at 12:32, DeLesley SpamBox <delesley.spambox at googlemail.com> wrote: >> I think the problem is deeper than that, in that LLVM has no official >> concept of a subtype, so I don't see how the idea of polymorphism >> could be defined in it. > > Parametric polymorphism is different from subtype polymorphism; you > can have one without the

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. On Wed, Feb 18, 2009 at 10:43 PM, DeLesley Hutchins <delesley.spambox at googlemail.com> wrote: >> I think many people were confused by this at first but an

> 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

>> How difficult would it be to add such a capability to llvm? I was thinking >> of marking type variables like T as opaque types for the initial codegen, >> and then writing a custom pass that instantiates them to real types. >> However, I don't know if that would confuse or break other parts of the >> compiler infrastructure; parametric polymorphism is not

Thanks for the detailed response! :-) > This is by design. LLVM's type system is very low-level... Yes, and it should remain low-level. :-) > Expecting it to directly support generics seems a third-order-of- > magnitude leap of faith. :) But there is good news for the faithful? Let us distinguish between generics as found in java or .Net, and parametric polymorphism in general.

> It's done by the front-end. There are a variety of attributes and > mechanisms which are used to convolute data and marshall it through > call sites in an ABI-conformant manner. Oh dear. :-( Do the attributes change depending on the type? I would assume that attributes like "ccc" are type-invariant; i.e. every instantiation should use the C-calling convention, whatever

On 2009-02-18, at 14:53, DeLesley Hutchins wrote: > On 2009-02-18, at 08:06, Gordon Henriksen wrote: > >> Still, there are a large number of potential foibles here. For >> instance, passing an argument can require platform-specific >> contortions to conform to the platform ABI... > > Are those contortions done by the native code generator back-end, or > are

> I was thinking of the "T extends Comparable" part, which does involve > subtype polymorphism. Apologies if I'm getting terms mixed up. It was a bad example -- not close enough to actual LLVM. :-) > What do the parametrized types give you that you don't get from using > opaque instead of T? Possibly nothing. I don't really understand the limitations of

On Wednesday 18 February 2009 20:57:02 DeLesley Hutchins wrote: > > It's done by the front-end. There are a variety of attributes and > > mechanisms which are used to convolute data and marshall it through > > call sites in an ABI-conformant manner. > > Oh dear. :-( I think many people were confused by this at first but an excellent counter example was provided in a

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

On Wednesday 18 February 2009 21:27:21 DeLesley Hutchins wrote: > Try implementing a generic complex number class in Java, and watch the > two-order-of-magnitude drop in performance on scientific code. Amen. I haven't proven it with a working HLVM yet but I believe LLVM will make it possible (even easy?) to generate extremely performant code from heavily abstracted high-level source.

> 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

On Thursday 19 February 2009 03:31:04 DeLesley Hutchins wrote: > > 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.

Hi Jon, Jon Harrop wrote: > Other people are creating far more bleeding edge VMs (e.g. VMKit) using LLVM's > GC API so they would be much better positioned to discuss the technical > aspects than I am. I would like to hear any status updates they have! > > VMKit uses conservative GCs (Boehm or Mmap2, a GC developed in our lab), so we don't use the GC API. But we are

On Thursday 19 February 2009 13:39:24 Nicolas Geoffray wrote: > Jon Harrop wrote: > > Other people are creating far more bleeding edge VMs (e.g. VMKit) using > > LLVM's GC API so they would be much better positioned to discuss the > > technical aspects than I am. I would like to hear any status updates they > > have! > > VMKit uses conservative GCs (Boehm or

Why isn't the clang project mentioned anywhere on the main llvm web site? -DeLesley

Hello, is it possible to setup a model/table schema like this: Groupable --> Membership <-- Group ^ ^ | | User UserGroup I tried the following but failed: Groupable (table with ''type'' column) has_many :memberships, :as => :groupable has_many :groups, :through => :memberships

Hi, I'm new to OOP in R so please forgive the naiveness of some of the questions. Here are a couple of them. It would be great if you can contrast to OOP in Java. 1. R's S4 appears to centered around a dispatch mechanism which in my understanding is just a way to implement polymorphism. Now, here's the snag, I thought polymorphism was an aspect of OOP not by itself the definition of