Lambda the Ultimate

I get that nesting is often just sugar, but its aesthetics can't be ignored, especially when you considering tooling; e.g., when I type "a." what appears in the list of completions?

That's defined by the environment (imports, lexical scope) and what's known about 'a' at that point. If 'a' is 'Num a', then you see all of Num's functions. I'm not sure if that answers your question; it seems so straightforward that I suspect you have some trickier issue you'r thinking of.

Possibly related. I'm not knowledgeable in how advanced and effective tooling for Haskell is; i.e., is it able to list functions whose first argument is a value of some type?

Another angle on this problem is that we might want to constrain outer objects of arbitrary levels up the object tree. So we might want to say that A requires one of its outer objects to extend B, without specifying if this is the closest outer object.

Functors provide for parameterized class scope (you can use them to build mixins), not for extensible nesting.

Extension methods allow you to define methods on instances of a class from the outside. I guess what I'm asking about are extension classes, or classes whose instances are qualified by instances of another class, from the outside. I'm designing a new language, so what existing OO languages can and cannot do is not important.

Let's say I define an actor class that is designed only to work inside some game; i.e., it's initialization code depends on it's outer context being an instance of that game. Now, does it make sense to put that restriction in the type system or to have it their more informally via a constructor argument? The primary advantage might just be in tooling; e.g., intellisense adds the new actor class to the set of objects that can be qualified by a game of that type.

But what does "containment" mean if not lexical scoping? All your feature seems to provide to a class is a reference to some other class that client code can then instantiate. You won't have special access to it. AFAICS, all you'd gain is the ability to write o.C instead of C(o) to name the class. So what?

I suspect this is a hint, from the OP: "e.g., a nested class in Scala is qualified by the type of its [containing] object." I'm guessing that Sean wants:

o : O ⊦ new o.C() : o.C,

or at least

o : O ⊦ new o.C() : O.C.

In either case obviously the semantic nesting is significant, although only the first case actually seems useful. For a constructor argument, of course, we only have

o : O ⊦ new C(o) : C.

I didn't mean C(o) as a constructor invocation but as generic instantiation (or functor application, or what you prefer). So C[o] in more Scala'ish syntax. Or with your example:

o:O ⊦ new C[o]() : C[o]

My point is that I fail to see the substantial semantic difference between this and the first version above. I think this could only ever be relevant if you had object types that contain classes, and you'd need this kind of extension classes to adapt a given object. But that seems pretty esoteric.

I would say that the usual notion of functor would give the type C[O], rather than C[o]. This is pretty much the difference between my original first and second versions. Some form of dependent typing is required to get the latter, and path-dependence via nesting has proven to be workable. So I'm still not 100% sure we're talking about the same thing, but I may well be misunderstanding.

Ah, no. A functor can give you this kind of dependency. That was my point.

Could you explain how a functor can give this kind of dependency? Little o is a value, not a type. In most settings that I'm familiar with, you cannot even apply a type constructor to a value, so the application C[o] would be nonsensical.

(In fact, something like this is legal in Scala, but only because they have subtyping and singleton types. So I actually can write something like C[o.type].)

Suddenly it occurs to me that maybe you specifically mean something like ML functors and not just type constructors or generics. As I recall, it is possible to parameterize ML functors by values. Is this what you have in mind?

To be clear, I'm not playing dumb, I really don't get what you mean, and am hoping for enlightenment here...

Well, yes, I talked about functors. I wasn't very specific about what exactly I had in mind there, and there are several possibilities. Most directly, you can just take the module level itself: with functors it is possible to parameterize a signature (i.e. a module type) by a structure (i.e. a module value). And structures are closely resembling objects.

More concretely, e.g. in Ocaml you can say

module F(X : O) =
struct
  module type S = ...
end

and then F(M).S would be a signature, instantiated by a module M.

Now, the syntax is a bit awkward, and unlike modules, objects are first-class by default. But those aren't crucial differences in this context, I think.

Yes, that makes sense. I thought you meant functor in a much more general "type constructors are functors in some category" sense. Now I see what you mean.

Say you could express a type O..C that would match any instance of class C in an instance of type O with any number of objects in between in the object graph.

Also, for your last case, we could go with dependent classes, then

o : O ⊦ new C(o) : C(o)

But even then, we still have the problem that containment, namely indirect containment, cannot be captured directly in a type system that doesn't model it first class.

Sorry, I still don't get it. If I have a variable x : O..C, what could I do with x that I cannot do with x : C? If I write a class C that is "contained" in O (or o? I'm still not sure what you're actually asking for), what can I do inside it that I cannot do with a parameter O (or o : O)?

Great reference! They seem to call this concept inclusion. So you can specify that "Button in Panel." I would prefer "Button is Widget" and then "Widget in Panel".

Concepts seem like just another kind of object system. The weird name really turns me off and makes the work difficult to get through.

So you can specify that "Button in Panel." I would prefer "Button is Widget" and then "Widget in Panel".

In concept-orientation (both the programming and the data models), to be a member of a set means to be more specific than this set and to inherit from this set.

IS-A is a particular case of IS-IN relationship where a parent has one child only. For example, "Button is Widget" means that there is always one Button object included in a Widget object - yet, it is still inclusion. In this case, the Button object does not have its own identity - its identity is inherited from and shared with the parent Widget object.

Naasking: There is no requirement that Inner be a subclass of Outer at all, and it frequently isn't. What it means is that instance/class methods of Inner also have access to the instance/class fields/members/variables of Outer.

Yes, I know what it means given I work with C# every day. The scoping rules for nested types in such languages are very ad-hoc though, and the type class constraint I mentioned was intended to rigourously define the static context/environment/scope available to Inner. This requires a more explicit specification of the bindings that Outer exposes, but I'm not sure that's a bad thing.

Whether introducing the inheritance relationship is a problem is debatable. It doesn't seem ideal at first blush, but any rigourous specification of the opened context will be publicly visible at Inner's constructor in some way, so why not a type class inheritance relationship?

I'm well aware of the work. If you want to reduce nesting to a simple parameter, it will work. However, if you want to abstract over the object tree, then you would need something stronger with containment built in.

Both scoping and semantics are meaningful here, since if you can abstract over the object tree, scoping is no longer simply syntactic sugar.

Your original post says "why not just specify that class Inner could only be instantiated in the context of an instance of class Outer." isn't this precisely what parameterizing class Inner on an instance of class Outer achieves?

In that case the members of the Outer instance would not implicitly be in scope for the body of Inner, but that could hypothetically be handled by a separate "using" sort of mechanism.

I'm not sure what you mean by "abstract over the object tree," beyond what a system like the above provides. I'm interested to know, though, so if you have the time to explain I'd appreciate it.

A couple of points:

• Aesthetics are a concern here. Does it make sense to have syntax for saying that a Button can only be created inside a Panel? Or is it better to (a) syntactically nest the Button class inside the Panel class so button objects are always qualified by a panel object or (b) include Panel as an argument to Button (the common approach)?
• Abstracting over the object tree means being able to talk about properties of a node or nodes along a path in the tree vs. a very specific node, like the one immediately above the object. For example, if a Button can only be created in a Panel, does it make sense for that the Panel object to always be the immediate parent of the Button object, or could Panel just be some parent of the Button?

Part of my reason for posting is to understand and clarify the problem, or to figure out if there is really any problem at all :)

Does it make sense to have syntax for saying that a Button can only be created inside a Panel? Or is it better to (a) syntactically nest the Button class inside the Panel class so button objects are always qualified by a panel object or (b) include Panel as an argument to Button (the common approach)?

All the syntactic nesting approaches make it hard to adapt the framework when next weeks UI paradigm allows buttons somewhere else as well, you can't syntactically nest in two places. So changes are likely to break existing client code.

Passing parent as a parameter (b) is more flexible but may not find illegal parents until runtime (depends on your implementation).

Making the parent a type parameter (by any available mechanism) should allow it to be checked at compile time.

I think the problem is you are trying to express the nesting of instances (eg buttons in panels) with nesting of the types themselves.

I see this as similar to the old OO design argument of design by nouns in the problem space but they may be implemented by a different set of nouns in the code space vs problem space nouns ARE the nouns in the code space.

I'm not really interested in the difference between type nesting and object nesting, to me they are pretty much the same and its only an accident that type nesting was ever considered separately. OO types really should just be seen as quantifiers over objects, and nested types would fall naturally out of object nesting.

You can generalize Button's container from being a panel to being a more general type. This is a hard change that requires editing the source code, but would you expect anything else? You should also be able to modularly create a new kind of button that expects a more specific kind of parent (this is possible in Scala).