Collecting app-polymorphic lambda sets for glue · compiler development

Stream: compiler development

Topic: Collecting app-polymorphic lambda sets for glue

Ayaz Hafiz (Jul 18 2023 at 22:32):

cc @Folkert de Vries @Richard Feldman
As discussed earlier today in the meeting, for collecting lambda sets that an app "fills in" for a host-exposed type,

let's make host-exposed defs require a type annotation whose surface types are fully monomorphic (except of course in lambda set + app-type-variable positions)
Collect those annotations at some point (probably can is the easiest). These annotations are the type as the host sees them. Store them in a bucket HostExposedPolymorphic : Name => Annotation
Solve as usual. Now we have those host exposed names specialized to the app, and hence can use them as a bucket HostExposedAppSpecialized : Name => Annotation
To determine the host-exposed lambda set wrappers to generate
- for each Name, PolymorphicAnnotation in HostExposedPolymorphic
  - Run the lambda-set numbering scheme over PolymorphicAnnotation, create a mapping HELS: LSNum => Variable where each variable (should be) the empty lambda set
  - Set AppSpecializedAnnotation = HostExposedAppSpecialized[Name]
  - Unify AppSpecializedAnnotation ~ PolymorphicAnnotation
  - For each LSNum, LSVar in HELS, look up the new content of LSVar. This is the app-specialized lambda set for which a lambda set caller function should be generated for at the LSNum lambda set number.

Folkert de Vries (Jul 21 2023 at 20:55):

for (symbol, variable, annotation) in it {

progress is being made

Folkert de Vries (Jul 24 2023 at 18:42):

@Ayaz Hafiz running into a problem still

so, we're very close, but now the type of main misses the lambda set. This is the main branch:

[crates/compiler/mono/src/ir.rs:8529] proc_name = `#UserApp.main`
[crates/compiler/mono/src/ir.rs:8531] SubsFmtContent(&content, env.subs) = Alias(`pf..IdentId(1)`, [67], <1556>Alias(`pf.Task.Task`, [1, 3, 67, 3], <1557>Opaque(`pf.Effect.Effect`, [1567, 1564], <1568>Func([<1578>EmptyRecord,], <1564=1576>LambdaSet([`pf.Effect.IdentId(15)` <1571>Func([<1578>EmptyRecord,], <1574=1579>LambdaSet([`pf.Effect.IdentId(33)` <80>Apply(`Str.Str`, []) , ], ^<1571>), <1578>EmptyRecord) <1572>Func([<1578>EmptyRecord,], <1573=1584>LambdaSet([`pf.Task.IdentId(62)` , ], ^<1572>), <1582>['Err' <1563>EmptyTagUnion , 'Ok' <1562>EmptyRecord , ]<Any(1570)>) , ], ^<1568>), <1586>Alias(`Result.Result`, [1562, 1563, 1565], <1567>['Err' <1563>EmptyTagUnion , 'Ok' <1562>EmptyRecord , ]<Any(1570)>)))))
[crates/compiler/mono/src/ir.rs:8532] layout_cache.interner.dbg(ret_layout) = "{}"
[crates/compiler/mono/src/ir.rs:8533] layout_cache.interner.dbg(lambda_set.full_layout) = "{Str, {}}"

and this is on our changed branch

[crates/compiler/mono/src/ir.rs:8595] proc_name = `#UserApp.main`
[crates/compiler/mono/src/ir.rs:8597] SubsFmtContent(&content, env.subs) = Alias(`pf..IdentId(1)`, [72], <1578>Alias(`pf.Task.Task`, [1, 3, 72, 3], <1579>Opaque(`pf.Effect.Effect`, [1580, 72], <1581>Func([<1587>EmptyRecord,], <72=1584>LambdaSet([], ^<1581>), <1586>Alias(`Result.Result`, [1, 3, 3], <1582>['Err' <3>EmptyTagUnion , 'Ok' <1>EmptyRecord , ]<Any(3)>)))))
[crates/compiler/mono/src/ir.rs:8598] layout_cache.interner.dbg(ret_layout) = "{}"
[crates/compiler/mono/src/ir.rs:8599] layout_cache.interner.dbg(lambda_set.full_layout) = "[]"

A theory is that we don't introduce (in constraint gen) the "freshened" lambda set variables. But I'm not sure what to do there, or how to debug this further

this is in trying to run an example that actually uses Task, the CFold example from the benchmarks specifically

Folkert de Vries (Jul 24 2023 at 18:51):

what is really weird about this is that our changes influence the type that is inferred for main, even though we don't actually do anything with it

Folkert de Vries (Jul 24 2023 at 18:53):

ok nvm, needed to switch some constraints around

Folkert de Vries (Jul 24 2023 at 18:56):

2 hours down the drain ...

Folkert de Vries (Jul 24 2023 at 20:04):

https://github.com/roc-lang/roc/pull/5687

Ayaz Hafiz (Jul 24 2023 at 20:19):

Did you manage to resolve it?

Folkert de Vries (Jul 24 2023 at 20:23):

yes by switching the constraint solving order

Folkert de Vries (Jul 24 2023 at 20:23):

the "real" annotation should go first and introduce all the variables

Last updated: Jul 06 2025 at 12:14 UTC