frontend: internal representation of method calls skips separate bind step by mikesamuel · Pull Request #447 · temperlang/temper

mikesamuel · 2026-06-26T20:29:42Z

Previously, method calls were represented using separate bind and call steps.
There's something elegant to treating complex calls like the below as
multiple distinct steps.

subject.method<TypeActual>(arg0, arg1)
┣━━━━━┛      ┃           ┃           ┃
┃SUBJECT     ┃           ┃           ┃
┣━━━━━━━━━━━━┛           ┃           ┃
┃  BOUND METHOD          ┃           ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━┛           ┃
┃    BOUND AND PARAMETERIZED METHOD  ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
       COMPLETE METHOD CALL

It was convenient to type each part separately.

The subject has type MyClass<Bar>
Imagine, the method, pre-binding to a subject, has type
<U>(MyClass<T>) -> (U, U) -> Foo<T, U>,
so when bound to MyClass<Bar> the T binds to Bar and the overall type
for the bound method has type <U>(U, U) -> Foo<Bar, U>
Since there are explicit type parameters, the bound and parameterized
method has type (TypeActual, TypeActual) -> Foo<Bar, TypeActual>
Then the method call has type Foo<Bar, TypeActual>.

That only works if you can represent calls to overloaded methods as
one type, an intersection (&) type of function types. Note also
that the type of the bound method is a function type that returns a
function type. There's currying going on. Code reasoning about this
has to repeatedly pack and unpack intersection types and curry and
uncurry type info.

Translating intersection types is hard; most typed languages
(TypeScript being an exception) do not allow user's to explicitly
specify intersection types, though many use them under the hood.

Also, reasoning about whole calls is more common than reasoning about the
parts above (again, outside of the Typer), so many parts of the frontend and
the TmpL translator were complicated by the need to look through calls
so that the could reassemble full argument lists (subject and args)
across two calls.

Ongoing changes to the internal representation of types and to type
solving made it easier to sequester overload handling to a small
portion of the Typer and TypeSolver, obviating the need for
intersection types, and the need for union types (previously used for
nullable type representation and unions of success and failure types
in result types).

This commit reworks DotHelper; instead of BindMemberAccessor
specifying bind semantics, now CallMemberAccessor specifies full
call semantics.

There is a lot of cleanup and reworking of Typer internally to
type the new representation, and cleanup of existing code that
produces method calls to produce the newer, flatter calls.

A lot of this reworking of the typer prefigures work that will
be necessary to use Type2 and Signature throughout instead
of the old StaticType representations.

Signed-off-by: Mike Samuel mikesamuel@gmail.com

… step Previously, method calls were represented using separate bind and call steps. There's something elegant to treating complex calls like the below as multiple distinct steps. subject.method<TypeActual>(arg0, arg1) ┣━━━━━┛ ┃ ┃ ┃ ┃SUBJECT ┃ ┃ ┃ ┣━━━━━━━━━━━━┛ ┃ ┃ ┃ BOUND METHOD ┃ ┃ ┣━━━━━━━━━━━━━━━━━━━━━━━━┛ ┃ ┃ BOUND AND PARAMETERIZED METHOD ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ COMPLETE METHOD CALL It was convenient to type each part separately. - The subject has type `MyClass<Bar>` - Imagine, the method, pre-binding to a subject, has type `<U>(MyClass<T>) -> (U, U) -> Foo<T, U>`, so when bound to `MyClass<Bar>` the *T* binds to *Bar* and the overall type for the bound method has type `<U>(U, U) -> Foo<Bar, U>` - Since there are explicit type parameters, the bound and parameterized method has type `(TypeActual, TypeActual) -> Foo<Bar, TypeActual>` - Then the method call has type `Foo<Bar, TypeActual>`. That only works if you can represent calls to overloaded methods as one type, an intersection (`&`) type of function types. Note also that the type of the bound method is a function type that returns a function type. There's currying going on. Code reasoning about this has to repeatedly pack and unpack intersection types and curry and uncurry type info. Translating intersection types is hard; most typed languages (TypeScript being an exception) do not allow user's to explicitly specify intersection types, though many use them under the hood. Also, reasoning about whole calls is more common than reasoning about the parts above (again, outside of the Typer), so many parts of the frontend and the TmpL translator were complicated by the need to look through calls so that the could reassemble full argument lists (subject and args) across two calls. Ongoing changes to the internal representation of types and to type solving made it easier to sequester overload handling to a small portion of the *Typer* and *TypeSolver*, obviating the need for intersection types, and the need for union types (previously used for nullable type representation and unions of success and failure types in result types). This commit reworks *DotHelper*; instead of *BindMemberAccessor* specifying bind semantics, now *CallMemberAccessor* specifies full call semantics. There is a lot of cleanup and reworking of *Typer* internally to type the new representation, and cleanup of existing code that produces method calls to produce the newer, flatter calls. A lot of this reworking of the typer prefigures work that will be necessary to use *Type2* and *Signature* throughout instead of the old *StaticType* representations. Signed-off-by: Mike Samuel <mikesamuel@gmail.com>

Signed-off-by: Mike Samuel <mikesamuel@gmail.com>

mikesamuel · 2026-06-26T20:39:35Z

            translateDotHelperCall(
                tree,
                callee = effectiveCallee,
-                outerCallTree = null,


There is no outer call tree.

mikesamuel · 2026-06-26T20:40:46Z

-            actualCalleeType = hackTryStaticTypeToSig(callTree.childOrNull(0)?.typeInferences?.type)
-        } else if (dotHelper.memberAccessor is BindMemberAccessor) {
-            val innerCallee = callTree.childOrNull(0)
+        val declaredCalleeType: Signature2? = firstMember?.descriptor


Still want to store the chosen MemberShape with DotHelper post typing. That's a PR for a different time though.

mikesamuel · 2026-06-26T20:41:39Z

Some indenting changed, so recommend viewing in -w mode.

mikesamuel · 2026-06-26T20:41:48Z

+        val actualCalleeType: Signature2? = hackTryStaticTypeToSig(callTree.childOrNull(0)?.typeInferences?.type)

-            actualCalleeType = innerCallee?.typeInferences?.type?.let {
-                hackTryStaticTypeToSig(BindMethodTypeHelper.uncurry(it))


No need to uncurry anything anymore.

mikesamuel · 2026-06-26T20:43:05Z

        // Replace the macro call with regex constructor calls.
        val callPos = macroEnv.pos
        macroEnv.replaceMacroCallWith {
-            Call {


Lots of this kind of change to code that produces method calls: the outer call wrapper goes away in favour of just the inner call which adopts the extra arguments.

Before (Call (Call do_bind_foo subject) arg)
After (Call do_bind_foo subject arg)

mikesamuel · 2026-06-26T21:03:42Z

 enum class TypeOpPrecedence {
    Or, // Binds loosest
    And,
+    Fn,


Ran into a minor bug in debug output where, in a nullable function type, the ? was glomming onto the end of a function-type string representation.

Added tests to StaticTypeTest.

mikesamuel · 2026-06-26T21:04:02Z

    else -> false
 }

+val StaticType.nullity: Nullity get() = when (this) {


Mirrors the nullity member on Type2.

mikesamuel · 2026-06-26T21:05:25Z

Reworked the code that turns DotHelper calls back into subject.method(...) syntax when resugar options are on.

I consolidated some explicit and implicit type arg stuff too.

Added tests to PseudoCodeTest.

mikesamuel · 2026-06-26T21:06:44Z

+        )
+        val strToVoidOrNull = MkType.nullable(strToVoid)
+        assertStringsEqual(
+            "(fn (String): Void)?",


This was coming out as fn (String): Void? which is confusing.

mikesamuel · 2026-06-26T21:07:44Z

        }
    }

-    private fun assertResult(


Moved this down. I prefer to have all the test helpers either at the top or the bottom.

mikesamuel · 2026-06-26T22:08:34Z

Some breakage in C# and Rust backends which I think are related to tweaks to the declared type derivation in translateDotHelper.

I think the C# side exposes a legit issue, see #448.

The Rust side I think is a problem with this PR.

Going to differentially check declared/actual type with printf debugging in some of the Rust functional tests before and after this change. Maybe will try to boil it down to a RustBackendTest case first.

mikesamuel · 2026-06-30T22:57:37Z

The Rust failure is in this code from json.temper.md:

    let decodeHexUnsigned(
      sourceText: String, start: StringIndex, limit: StringIndex
    ): Int {
      var n = 0;
      var i = start;
      while (i.compareTo(limit) < 0) {
        let cp = sourceText[i];
        let digit = if (char'0' <= cp && cp <= char'0') {
          cp - char'0'
        } else if (char'A' <= cp && cp <= char'F') {
          cp - char'A' + 10
        } else if (char'a' <= cp && cp <= char'f') {
          cp - char'a' + 10
        } else {
          return -1;
        }
        n = (n * 16) + digit;
        i = sourceText.next(i);
      }
      n
    }

The problem happens in while (i.compareTo(limit) < 0) {

My guess is that the problem comes from i being types as StringIndex but the declared type has the this parameter as a StringIndexOption.

mikesamuel · 2026-06-30T23:11:06Z

Before these changes:

For .compareTo @ test/impl.temper:6+9-27
  declaredCalleeType=(this : StringIndexOption, StringIndexOption) -> Int32
  actualCalleeType=(StringIndex, StringIndexOption) -> Int32
For .get @ test/impl.temper:7+13-26
  declaredCalleeType=(this : String, StringIndex) -> Int32
  actualCalleeType=(String, StringIndex) -> Int32
For .next @ test/impl.temper:18+8-26
  declaredCalleeType=(this : String, StringIndex) -> StringIndex
  actualCalleeType=(String, StringIndex) -> StringIndex

After:

For .compareTo @ test/impl.temper:6+9-27
  declaredCalleeType=(this : StringIndexOption, StringIndexOption) -> Int32
  actualCalleeType=(StringIndexOption, StringIndexOption) -> Int32
For .get @ test/impl.temper:7+13-26
  declaredCalleeType=(this : String, StringIndex) -> Int32
  actualCalleeType=(String, StringIndex) -> Int32
For .next @ test/impl.temper:18+8-26
  declaredCalleeType=(this : String, StringIndex) -> StringIndex
  actualCalleeType=(String, StringIndex) -> StringIndex

Strangely, it's the this type for the actual callee type that has changed.

Signed-off-by: Mike Samuel <mikesamuel@gmail.com>

mikesamuel · 2026-07-01T21:38:17Z

Merged in main which fixes C# failure.

Signed-off-by: Mike Samuel <mikesamuel@gmail.com>

mikesamuel · 2026-07-01T21:48:35Z

                |{
                |    builder__0 = new C::OrderedDictionary<string, string>();
-                |    Map1 = C::Mapped.ToMap(builder__0);
+                |    Map1 = C::Mapped.ToMap(C::Mapped.AsReadOnly(builder__0));


Not sure whether this extra cast here a problem?

Signed-off-by: Tom <tom@temper.systems>

- Rely on fixed StringIndexOption compare typing - Expect more inlining in a backend test

tjpalmer

Looks like lots of the logic got simpler, which is nice. Overall, I prefer the new way.

tjpalmer · 2026-07-02T15:02:53Z

 for (var i = 0; i < 3; ++i)
  console.log(i.toString()) // Curly brackets missing
-// ❌ Expected function type, but got Invalid!, No type for subject of .toString!, Expected function type, but got Invalid!
+// ❌ Expected function type, but got Function!, No type for subject of .toString!


Expected function type, but got Function!, No type for subject of .toString!

That "but got Function" is a bit unfortunate, but we can refine later. That second message is helpful. And only two messages instead of three is also nice.

tjpalmer · 2026-07-02T15:05:08Z

    membersGrouped.removeMatching { it.value.isEmpty() }
 }
+
+/**


This is redoing some of the analysis you did in auto-inserting super calls.

Maybe we can clean out some of the later logic at some point.

tjpalmer · 2026-07-02T15:06:31Z

+ *
+ * Given these two alternative signatures, `fn (K): String` and `fn (I<String>): String`
+ * the type solver has no way to pick between the two leading to an unresolvable overload
+ * decision.


Or if we choose to error more in the frontend, that would also let us clean back out some from the backends. Since we don't promise semantics when there are frontend errors.

But I guess we probably don't want to error unless we have a manual way to override super selection. Or we could just say "too bad, use composition instead of inheritance here".

tjpalmer · 2026-07-02T15:10:51Z

+ * Then we can compare the signatures for equality (ignoring the `this` arg types),
+ * and since they're equivalent, drop any but the shallowest tier ones.
+ */
+internal fun filterOutDeeperMembers(


I can't tell if inheritance filtering need is increased by this PR or if you just happened to notice it as interesting. And maybe you already explained that elsewhere. I'm ok either way. Just hard to grok everything in review.

tjpalmer · 2026-07-02T15:18:36Z

+            |    interface C { a(): String { "C wins!" } }
+            |    class D extends B & C {}
+            |    new D().a()
+            |/// ┗━━━━━━━━━┛ : String


How can we tell which wins from this test? Or did that involve manual inspection? Either way, I'm not worried. Just wondering if I'm missing something.

It doesn't. I just copied your style of test.

I'd like to get to the point where we're storing member shapes with dot helpers post typing.

Then, maybe I could add a way to point at a dot and use the comment style to point out which member is stored as a way of checking @overload @operator @extension and super-type resolution.

tjpalmer · 2026-07-02T15:36:13Z

+        // We resolved types just fine, but parameterized methods in interfaces are still suss.
+        wantErrors = listOf(
+            "1+20: Illegal type parameter T. Overridable methods don't allow generics!",
+            "3+20: Illegal type parameter T. Overridable methods don't allow generics!",


I wouldn't worry too much about nice handling of type formals that are already illegal.

mikesamuel added 3 commits June 26, 2026 13:30

cleanup some missing tests

b374836

Signed-off-by: Mike Samuel <mikesamuel@gmail.com>

Merge branch 'main' into call-instead-of-bind-semantics-for-dot-helpers

857045a

Signed-off-by: Mike Samuel <mikesamuel@gmail.com>

mikesamuel commented Jun 26, 2026

View reviewed changes

mikesamuel added 2 commits July 1, 2026 14:52

minimal repro for be-rust problem

f041b40

Signed-off-by: Mike Samuel <mikesamuel@gmail.com>

Merge branch 'main' into call-instead-of-bind-semantics-for-dot-helpers

cd973c1

Signed-off-by: Mike Samuel <mikesamuel@gmail.com>

fix test golden

a561e9f

Signed-off-by: Mike Samuel <mikesamuel@gmail.com>

mikesamuel commented Jul 1, 2026

View reviewed changes

tjpalmer and others added 3 commits July 1, 2026 15:37

Remove obsolete workaround for StringIndexOption

9ca4f13

Signed-off-by: Tom <tom@temper.systems>

Expect more inlining

b9171e5

Signed-off-by: Tom <tom@temper.systems>

Fix be-rust for call instead of bind (#455)

18d5373

- Rely on fixed StringIndexOption compare typing - Expect more inlining in a backend test

mikesamuel marked this pull request as ready for review July 2, 2026 04:54

tjpalmer approved these changes Jul 2, 2026

View reviewed changes

mikesamuel merged commit 7771030 into main Jul 2, 2026
2 checks passed

mikesamuel deleted the call-instead-of-bind-semantics-for-dot-helpers branch July 2, 2026 15:57

Uh oh!

Conversation

mikesamuel commented Jun 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikesamuel commented Jun 26, 2026

Uh oh!

mikesamuel commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mikesamuel commented Jun 30, 2026

Uh oh!

mikesamuel commented Jul 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tjpalmer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mikesamuel commented Jun 30, 2026 •

edited

Loading