Lambda the Ultimate

Hello everyone,

I have been working on a language design which will requires builtin security checks of some sort ala what Java has or something like E. I have been looking recently at ML mixin modules which seem to be very closely related to classes. The question I have is are there known methods for handling security for systems like this where you cannot trust all the packages or load files in the system? To have a security system which is similar to an object based one I assume one would have to have any such security predicated not only on the modules(classes) but also the data. Is this sort of thing possible and is there any research in this area?

Thanks in advance,

Carter.

They are essentially translating haskell to CUDA code. The added semantics on the Haskell side is what is most interesting. Does anyone know of similar projects to add higher-level constructs to a language that gets compiled to CUDA. It's not clear to me from this presentation what the Lava semantics have to do with it.

Obsidian

In Common Lisp, Dylan, and Python, all languages that provide multiple inheritance, there is a notion of inheritance order, specified by the order in which the direct superclasses of a class are given. All three languages determine the order in which methods are examined for relevance at method-call time by flattening the direct superclass orders into an order of all the superclasses. If no such flat order is possible, the class is rejected at compile time. (The flattening is done by different rules in each language, but that's not my present concern.)

In particular, suppose a class A and a class B which wlg inherit only from the topmost class. Then we may have a class AB which inherits first from A and then from B if A does not have a suitable method, and a class BA which inherits first from B and then from A. However, a class C that inherits from both AB and BA is not allowed, as its order would be locally inconsistent: we do not know whether to flatten it as C, AB, BA, A, B or as C, AB, BA, B, A.

My question is this: does having such classes as AB and BA ever actually make sense? Are there Real World examples where it is necessary in the same program to have two distinct classes that inherit from the same set of superclasses but in a different order?

I ask this question because I am implementing a language with MI, and it seems to me that there is a considerable advantage to my implementation if I can rule out such combinations of classes tout court, and simply require a globally unique order: if AB exists, then BA cannot, and vice versa. I have asked people from the Python and CL communities, and they tell me that such contrasts are normally considered poor style: that the only thing a method should count on is that methods from its subclasses are tried before it, and methods from its superclasses are tried after it. However, I would not want a win for me to become a loss for my users, so if anyone can point to realistic counterexamples, I suppose I will have to bite the bullet.