Improve constructor handling in Orc classes

[arthurp]

Currently constructors for classes cannot be referenced in a subclass. Instead the subclass is required to implement fields with the same names as the constructor arguments of the superclass. This is really confusing. In addition, constructors currently always bind the arguments to fields. This means that constructor arguments are always tied to the life cycle of the object even if they are not needed after field initialization completes.

Ideally we would have Scala like primary constructors where subclasses need to provide the arguments as arguments to the class name when they declare the superclass.

It's not clear how to solve these problems. We need to consider several issues:

• Lenient and strict constructors.
• How to encode the result into the underlying theory.
• Exactly how much has to be directly supported by the interpreter and what can be encoded into OIL without special support (notably Arthur expects that constructors that do not store the arguments will need special support beyond what the theory has).

[arthurp]

Due to the redesign of Orc objects, I have decided to initially remove automatically created constructors entirely. Class users will need to explicitly write new C { val parameter1 = 5 # val parameter2 = f(x) }. This will not be a tenable long term solution, but it will allow us to experiment with various constructor use patterns and decide what kinds of automaticly generated constructor are most useful.

[arthurp]

Introducing class constructor sites which can be called from within that class (recursively) implies that the partial constructors would need to recursively call the constructor site. However currently we do not allow defs and sites to be recursive (and partial constructors should really be defs since there is no reason for them to implicitly jump to another termination domain). We could remove the restriction and define semantics for mutually recursive groups containing both sites and defs.

I don't think those semantics would be overly complex. All calls would still function as they usually do with each site call executing at it's declaration (even recursive calls) and each def call executing at the call location.

[dkitchin]

Alternatively, we could define mutual recursion between any set of declarations by using a wrapping object.

On Tue, Jan 31, 2017 at 4:57 PM Arthur Peters notifications@github.com wrote:

Introducing class constructor sites which can be called from within that class (recursively) implies that the partial constructors would need to recursively call the constructor site. However currently we do not allow defs and sites to be recursive (and partial constructors should really be defs since there is no reason for them to implicitly jump to another termination domain). We could remove the restriction and define semantics for mutually recursive groups containing both sites and defs.

I don't think those semantics would be overly complex. All calls would still function as they usually do with each site call executing at it's declaration (even recursive calls) and each def call executing at the call location.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/orc-lang/orc/issues/169#issuecomment-276542638, or mute the thread https://github.com/notifications/unsubscribe-auth/AHM5MCbV6FQ0oApDvKgZC_sD2T_ptTCJks5rX9hsgaJpZM4Le9vt .

[arthurp]

That is a good point. I did think about how maybe we should actually convert all recursive defs and sites to objects. That would make objects the only recursive element of the language and that has a certain elegance.

[dkitchin]

We don't necessarily need to convert single recursive def or site definitions to objects, since the semantic rules for those are straightforward, but any mutual recursion in a group makes much more sense as an object (since it is precisely a recursive record anyway).

On Wed, Feb 1, 2017 at 10:29 PM Arthur Peters notifications@github.com wrote:

That is a good point. I did think about how maybe we should actually convert all recursive defs and sites to objects. That would make objects the only recursive element of the language and that has a certain elegance.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/orc-lang/orc/issues/169#issuecomment-276879390, or mute the thread https://github.com/notifications/unsubscribe-auth/AHM5MBN0fcJoCWnUAxQP49oGy2w2nq_uks5rYXfdgaJpZM4Le9vt .

[arthurp]

Why not go all the way? What's the advantage of keeping the recursion support for the simple cases?

[dkitchin]

So there's actually four distinct points on this continuum:

1) Mutually recursive declarations have special support, separate from objects. This seems unnecessary. 2) Mutually recursive declarations use objects. Singly recursive definitions are covered by their original semantic rules (site, function, etc) 3) All recursion uses objects, but only to access a name; that name is still bound to a function or site (which mentions 'self' in its body in order to perform recursion). Functions and sites still use their original semantic rules, but don't close the loop, and no longer even have names. 4) All callable declarations live within objects. Sites are remote methods. Functions are local methods.

1 doesn't make much sense.

2 makes a lot of sense, and doesn't take much work (the compiler and

interpreter already bundle recursive defs and have to do separate work to support them at runtime)

3 keeps recursion in one place conceptually, and in effect makes all

callables anonymous, but takes more work (all recursive machinery now goes through the global store rather than locally pushing in context, optimizations for special cases of this end up recreating #2).

4 is consistent and even more parsimonious, but has Lots of Consequences

for the typechecker and the runtime, and will cause optimization problems similar to #2 (with optimizations that either recreate #3 or #2). Orc is mostly no longer a subset of OrcO.

There's a fair chance we end up at #4 but I don't want to go there in the next month. Between #2 and #3, #2 requires less fiddling right now. Note that all of #1-#4 are invisible in the surface language anyway, so this is really up to our own convenience right now.

On Wed, Feb 1, 2017 at 10:41 PM Arthur Peters notifications@github.com wrote:

Why not go all the way? What's the advantage of keeping the recursion support for the simple cases?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/orc-lang/orc/issues/169#issuecomment-276880889, or mute the thread https://github.com/notifications/unsubscribe-auth/AHM5MGUycFvRCffVKpm4VhaaqF3dGzqUks5rYXqRgaJpZM4Le9vt .

[arthurp]

I have not fully read this. But I wanted to add something: Currently I am not adding automatically generated constructors at all. So none of this is actually needed. I will not be implementing it in the next month.

[arthurp]

This will probably not be implemented any time soon. To get an idea of why see this discussion of adding trait parameters to Scala: http://docs.scala-lang.org/sips/pending/trait-parameters.html . Basically, it's extremely hard to handle classes passing constructor arguments to superclasses if all classes are effectively traits like in Orc.