My failed experiment trying to avoid template syntax

[Bill Cox]

In Rune template classes are declared like:

class ClassList(self, <initialArray>) {
    self.list = initialArray

    func addClass(self, object) {
      self.list.append(object)
    }
}

class Foo(self, <value>) {
    self.value = value
}

l = ClassList(arrayof(Foo))  // This is a non-concrete datatpe, since we don't know Foo's template parameter types.
l.addClass(Foo(123))

This fails to compile because passing Foo passes a non-concrete datatype, which is never resolved.  The append method of arrays do not currently refine types.  If it did, this could compile.  However, the complexity of allowing non-concrete type assignments was a mistake.  I now believe it never should have been allowed.  Fixing this requires new syntax.

class ClassList(self, <initialArray>) {
    self.list = initialArray

    func addClass(self, object) {
      self.list.append(object)
    }
}

class Foo(self, <value>) {
    self.value = value
}

l = ClassList(arrayof(Foo<u64>))  // This describes a concrete type.
l.addClass(Foo(123))

The old syntax supports passing a call to the class constructor there, which I thought would be enough to avoid type expressions like "Foo<u64>".  I was wrong.  For example, builtin/doublylinked.rn, we initialize first and last references to the child class in the parent class with something like "self.firstChildNode = null(Node)".  In this example, if Node is a template class, then the variable self.firstNode is assigned a DE_TYPE_NULL datatype, which is not concrete, and must be resolved to a concrete type before the datatype can be used in binding expressions that refer to this data member.  This led to having to insert type hints in the code for the Rune compiler to succeed.

The new rule will be that all null values must be concrete.  If Node is a template class (having template parameters), then the relation will be instantiated like:

relation DoublyLinked Node<string>:"Parent" Node<string>:"Child" cascade

In the generated code, the line that used to result in "self.firstChildNode = null(Node)" will be expanded instead to "self.firstNode = null(Node<string>), which is concrete.

I think this is the last major revision before we can start hammering away at the bootstrap.

Bill)

[Aiden Hall]

Oh so this is related to the syntax thingy we discussed with regard to relations on Monday right?

--
You received this message because you are subscribed to the Google Groups "Rune language discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rune-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rune-discuss/CAH9QtQH9K-yPmEwPa3Apq3dkuQ2_f83Y6C_yaABOLzUMAVbyDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Bill Cox]

Correct.  I'll have an unfortunately very large CL to send your way shortly.  I don't know how to make this change in < 1000 lines.