Support typed config objects by tjpalmer · Pull Request #479 · temperlang/temper

tjpalmer · 2026-09-04T16:43:16Z

Specifically support typed config for be-java
Inject bindings during import stage from all registered backends
Also inject std config.temper.md source from backends so it's not present when a backend isn't active and the config bindings are also missing
Also evaluate new calls during partial interp for imu types
Eval function defs in export stage so we get export values
Still support old top-level be-java fields so unchanged libraries still work (and also still has <groupId>dev.temperlang</groupId> and package temper.regex_parser; in generated files):

temper-regex-parser> temper test -b java
Tests passed: 22 of 22

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

* Work toward better std config injection * Move java config def to frontend Signed-off-by: Tom <tom@temper.systems>

tjpalmer · 2026-09-07T16:48:27Z

-        val javaPackageConfigKey = Symbol("javaPackage")
-
-        /** Config key to specify Maven dependencies */
-        val javaDependenciesKey = Symbol("javaDependencies")


Moved to config description in frontend to be with the new config type for use in std.

Moved to config description in frontend to be with the new config type for use in std.

Now in a different file in be-java.

tjpalmer · 2026-09-07T16:49:37Z

        val pomPath = filePath("pom.xml")
        val pomMime = MimeType("text", "xml")

+        override val configBindingsInjector: BindingsInjector = JavaConfigInjector


We still want these configured on each backend so that plugged backends also can register them, even if we don't yet have a way for them to do custom config for std.

tjpalmer · 2026-09-07T16:50:36Z

+        (value.stateVector as InstancePropertyRecord).properties.map { instance ->
+            (instance.key as SourceName).baseName.nameText to instance.value
+        }.toMap()
+    }


Even if the definitions are in the frontend, we use them from the java backend.

And while sloppy checks here for config type are better than nothing, somehow sneaking this properly into frontend type checking might be nice.

What does get checked in frontend now, though, is the the field types themselves for the JavaConfig instance, and that's likely to be helpful.

tjpalmer · 2026-09-07T16:51:25Z

-    private val libraryArtifact: String get() = cfg(JavaBackend.javaLibraryArtifactConfigKey) ?: libraryName
+
+    private val libraryArtifact: String
+        get() = cfg(JavaConfigKeys.ARTIFACT, JavaConfigKeys.libraryArtifactGlobal) ?: libraryName


To support fallback for existing temper libs, check both the typed config and if missing then the global config var.

tjpalmer · 2026-09-07T16:53:06Z

+                |          class: JavaConfig,
+                |          package: "com.example",
+                |        };
                |    ```,


If we get target-typed prop bags, we could say this instead:

export let java: JavaConfig = { package: "com.example", };

I'd rather not rely on unique keys, even though package is unique right now, because I suspect different backend configs could conflict easily in the general sense.

tjpalmer · 2026-09-07T17:11:19Z

+    JavaConfigInjector,
+)
+
 private val sharedStdModules = lazy {


With sharedStdModules themselves already global here, I didn't feel too bad about making the injectors also global. Note that both are private to this file.

tjpalmer · 2026-09-07T17:11:42Z

+     */
+    fun addBindingsInjector(injector: BindingsInjector) {
+        mutableBindingsInjectors.add(injector)
+    }


Here's comments about me musing on import resolvers.

tjpalmer · 2026-09-07T17:12:13Z

+      dependencies: [
+        "org.junit.jupiter:junit-jupiter:5.9.2",
+      ],
+    };


Converted std to new style here, which is what needed the schema code being in frontend.

tjpalmer · 2026-09-07T17:13:54Z

            // Produce exports
+            stage == Stage.Export -> true
            stage == Stage.GenerateCode -> true
            else -> false


And we discussed this some on discord, but I can't get values into exports unless either:

Export stage actually provides function values or

We wait until generate code stage to make exports.

Note that the already existing comment above suggests someone was thinking about exports coming from generate code stage, even though that's not what happens elsewhere.

tjpalmer · 2026-09-07T17:16:19Z

+
+private fun TypeShape.isImu(): Boolean {
+    return (stayLeaf?.incoming?.source as? DeclTree)?.parts?.let { imuSymbol in it.metadataSymbolMap } == true
+}


Not much code needed to produce new values in partial interp for @imu. I don't know what all other functions run, but at least basic values and lists work as shown in this pr. And supporting proper @partialImu usage would be correct here, too, but I didn't look into that in this pr.

I didn't look to see if partial interp support for lists values check @partialImu rules correctly. Lists of strings were already working before any of my recent changes.

mikesamuel · 2026-09-09T15:07:50Z

+                    module.addBindingsInjector(injector)
+                }
+            }
+        }


Do they need to have the authority to affect all modules, or can we just have their effect limited to config modules.

mikesamuel · 2026-09-09T15:09:54Z

+    properties: Map<String, Planting.() -> Any?>,
+) {
+    Call {
+        Rn(ParsedName(imuDecorator.name))


Should this be a builtinname? And ExportDecorator.name below?

Should this be a builtinname? And ExportDecorator.name below?

In at least some cases, I think BuiltinName was failing on me, but I can do a fresh pass to try things out.

Should this be a builtinname? And ExportDecorator.name below?

In latest checks, BuiltinName worked for imu but not export, so I made the change for imu.

Thanks for giving that a try.

mikesamuel · 2026-09-09T15:11:40Z

It seems less than ideal to have backend-specific stuff outside of that directory.

Is there any way to avoid that?

It seems less than ideal to have backend-specific stuff outside of that directory.

Is there any way to avoid that?

As I've mentioned, I can't put java config info in be-java and also use it in std, because we don't always have be-java on the classpath.

As I've mentioned, I can't put java config info in be-java and also use it in std, because we don't always have be-java on the classpath.

And I already linked in the pr description my failed attempt at controlling config injectors from backends.

@ShawSumma recommends possibly injecting std config content and not just type definitions. Well, full recommendations could be much more elaborate, but that's the simple scope version that maybe I can fit in this pr. So I'll look into that.

* Fail at backend-defined std injectors * Support also injecting std config source * Move java config back to be-java Signed-off-by: Tom <tom@temper.systems>

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

tjpalmer · 2026-09-10T01:34:51Z

-        val javaPackageConfigKey = Symbol("javaPackage")
-
-        /** Config key to specify Maven dependencies */
-        val javaDependenciesKey = Symbol("javaDependencies")


Moved to config description in frontend to be with the new config type for use in std.

Now in a different file in be-java.

tjpalmer · 2026-09-14T11:27:21Z

+    /** Config key to specify Maven dependencies */
+    const val DEPENDENCIES = "dependencies"
+    val dependenciesGlobal = Symbol("javaDependencies")
+}


Separated these keys out.

tjpalmer · 2026-09-14T11:28:05Z

+            )
+        }
+    }
+}


And here's the type definition for java config. Maybe could make this temper source like the bonus config section, but I already had this part working before that was done. That source injection is only for std config. This here is for config typing for any library, including std.

tjpalmer · 2026-09-14T11:29:38Z

+      dependencies: [
+        "org.junit.jupiter:junit-jupiter:5.9.2",
+      ],
+    };


Backends now can add their own separate config chunk for std, so this also works for plugged in configs. Alternatively, they could use custom backend logic, but seeing config for std that matches config for other libraries can be nice.

tjpalmer · 2026-09-14T11:46:23Z

+            }
+        }
+    }
+}


And the actual helper method that gets called from anywhere that organizes backends (currently 3 places). Most importantly, this provides config for supported backends from the temper cli.

It's also called for funtests and backend tests but without any extra backends listed.

tjpalmer · 2026-09-14T11:55:19Z

+                    // This typically is for tests where not all registered backends are on the classpath.
+                    // In those cases, this message isn't much interesting, but someone's actual environment could be
+                    // broken, and even in that case, the message should be enough info without a stack dump.
+                    console.error("Error loading Temper plugin $jvmClassName: ${r.failure}")


Shrink error messages for when backends aren't available. This still usually is clear about the issue.

tjpalmer · 2026-09-14T11:56:19Z

 }

-val defaultBackend: Lazy<Backend.Factory<*>> =
-    supportedBackendsGlobal.factories.getValue(BackendId("js")).backend


We were only using this in RunTest and not even in the cli, and it was breaking anyone trying to use anything else in this module if be-js wasn't on the classpath, so I removed it.

tjpalmer · 2026-09-14T13:18:30Z

+    properties: Map<String, Planting.() -> Any?>,
+) {
+    Call {
+        Rn(ParsedName(imuDecorator.name))


Should this be a builtinname? And ExportDecorator.name below?

In latest checks, BuiltinName worked for imu but not export, so I made the change for imu.

tjpalmer · 2026-09-14T13:19:17Z

        onError = { error(it) },
    )
+    // We only get here from backend-specific test classes, so no need for other backends.
+    backendOrganization.addSharedStdConfigInjectors(listOf())


For cli, we pass in supportedBackends, but here and for funtests we don't need that, and it causes error messages.

tjpalmer · 2026-09-14T13:32:18Z

            }
        },
    )
+    backendOrganization.addSharedStdConfigInjectors(supportedBackends)


For main build, inject all extra std config for all supported backends. Otherwise, a unit test case for one backend misses config for others in the same test class. This logic should also be fine for cli needs.

tjpalmer added 12 commits August 28, 2026 16:49

Prep for injecting java config

242baf3

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

Explore broken type injection

4bb6c91

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

Define class dynamically and use it

ece186e

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

Work toward new results in partial

57f7507

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

Allow function defs in export stage

7ca215d

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

Parameterize a data class

2aafdb2

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

Merge branch 'main' into typed-config

dc6e847

Use object propertiesl coalesce config

1cda462

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

Inject into std also

73410a9

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

Use prepareBuild in DoTestTest to config backends

e2a5e7c

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

Fix lint

e92a548

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

Fix std and more for typed config (#480)

5177b51

* Work toward better std config injection * Move java config def to frontend Signed-off-by: Tom <tom@temper.systems>

tjpalmer commented Sep 7, 2026

View reviewed changes

tjpalmer marked this pull request as ready for review September 7, 2026 17:16

mikesamuel reviewed Sep 9, 2026

View reviewed changes

tjpalmer marked this pull request as draft September 9, 2026 18:06

tjpalmer added 6 commits September 9, 2026 18:32

Inject java std config in addition to types (#482)

7f812df

* Fail at backend-defined std injectors * Support also injecting std config source * Move java config back to be-java Signed-off-by: Tom <tom@temper.systems>

Include std config for all supported backends

a541f3c

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

Remove default backend; reduce logging for missing ones

bb456f8

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

Avoid needless backends; use builtin name

352f5fb

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

Also no extra backends for funtests

7004796

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

Fix lint

8a917fc

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

tjpalmer commented Sep 14, 2026

View reviewed changes

tjpalmer marked this pull request as ready for review September 14, 2026 18:40

mikesamuel approved these changes Sep 24, 2026

View reviewed changes

tjpalmer merged commit ad0bc12 into main Sep 24, 2026
2 of 6 checks passed

tjpalmer deleted the typed-config branch September 24, 2026 18:30

Conversation

tjpalmer commented Sep 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

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!

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!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tjpalmer commented Sep 4, 2026 •

edited

Loading