Open jiribenes opened 3 months ago
Rebased on current master
.
Blocked on #629, I'll fix it there and then rebase. :)
Rebased on current master
(b0342130d7bbd926e072e753f048b92a7395efd8)
There's something that looks like a miscompilation on the JS backend in the examples/stream/map.effekt
test 👀 (cc @b-studios @marvinborner when you get the time: I think it's related to some optimizer changes)
It's reproducible locally. EDIT: And it goes away if I turn off the optimisations!
Here it is on the CI: https://github.com/effekt-lang/effekt/actions/runs/12014381198/job/33490034109#step:11:249
The cause is that l_6
is not defined here (look for the shl: <<
)
But the corresponding l9890516147
is also missing in Core (look for bitwiseShl
)
Hey, I am currently away from my computer. Where is the l
coming from? What is the core before optimizations?
btw. I typically use println(util.show(...))
in random positions to understand the trees during transformation.
I don't have the time to minimise further, so here's all of the data:
... by the way it would be nice to have a --ir-show=unopt-core
or something for these purposes ...
def go2822(level2819: Int398, m2820: Map2616[K2660, V2661], pairs2821: List910[Tuple2249[K2660, V2661]]) =
def b_k_38535593() =
m2820;
def b_k_38565594(k2823: K2660, v2824: V2661) =
putMax2721[K2660, V2661](m2820, k2823, v2824);
def b_k_38825595(k2825: K2660, v2826: V2661, rest2827: List910[Tuple2249[K2660, V2661]]) =
let v_r_38575596 = run {notOrdered2790(k2825, rest2827)}
if (v_r_38575596) {
insertMany2794(m2820, pairs2821)
} else {
let l2828 = run {m2820}; // `l2828` bound here
let cr2829 = run {create2801(level2819, rest2827)};
def b_k_38655597(r2830: Map2616[K2660, V2661], xs2831: List910[Tuple2249[K2660, V2661]]) =
let v_r_38625598 = run {link2709[K2660, V2661](k2825, v2826, l2828, r2830)} // `l2828` passed here
go2822(bitwiseShl225(level2819, 1), v_r_38625598, xs2831);
def b_k_38695599(r2832: Map2616[K2660, V2661], ys2833: List910[Tuple2249[K2660, V2661]]) =
let v_r_38665600 = run {link2709[K2660, V2661](k2825, v2826, l2828, r2832)} // and `l2828` passed here too
insertMany2794(v_r_38665600, ys2833);
...
let cr999169214 = run {create40328823(level86788726, v_y_38841141068748)}
cr999169214 match {
case Tuple3335 { (v_y_3872110102179215: Map2616[Int398, Char390], v_y_3873111103189216: List910[Tuple2249[Int398, Char390]], v_y_3874112104199217: List910[Tuple2249[Int398, Char390]]) =>
v_y_3874112104199217 match {
case Nil1114 { () =>
let v_r_3862103951039389 = run {link2709[Int398, Char390](v_y_38871151078749, v_y_38881161088750, l989059208, v_y_3872110102179215)} // HERE
go85778830(bitwiseShl225(level86788726, 1), v_r_3862103951039389, v_y_3873111103189216)
}
} else {
v_y_3873111103189216 match {
case Nil1114 { () =>
let v_r_3866107991439392 = run {link2709[Int398, Char390](v_y_38871151078749, v_y_38881161088750, l989059208, v_y_3872110102179215)} // and HERE
...
Wouldn't --ir-show core --no-optimize
work?
Wouldn't
--ir-show core --no-optimize
work?
It does, but it's slightly more work and doesn't work directly in VSCode :/
Also, it doesn't work with --ir-write-all
to dump both the optimised and unoptimised core...
I've been sitting on this code for almost 9 months now (started on Xmas 2023), it's about time we finalise it. This PR adds immutable ordered maps and sets based on BB[α]-trees into the standard library.
Important caveat: These structures work only on the JS backend because it's the only one with a generic comparison primitive (#394).
Note that it might take a while before I'm happy with this code, I just want to put it out here in case someone wants to help out / to prevent somebody else from spending too much time on reimplementing this.
TODO:
///
for doc stringsintersection
!via
combinators inSet
actually inline