[09:15:14] Good Morning everyone. I just joined the channel as part of my onboarding! :) [09:15:39] 👋 welcome, Zelig880 [09:19:21] welcome! [09:35:10] Hey, welcome! [15:39:51] Hello everyone! I also joined as part of onboarding [15:41:19] Hi lindsayk 😊 [16:58:11] * stwalkerster waves [17:24:23] hi Zelig880 lindsayk ! [17:24:45] Hello :) [17:25:21] hello [17:30:39] Howdy all :) [17:32:14] So I was thinking about static validation of JavaScript functions as pure functional; I think it may be possible as long as you require all function calls to be statically verifiable, which means callbacks passed over Wikifunction boundaries must be typed as pure or having side effects [17:33:44] Additionally you'd want to remove mutator functions from the globals and freeze them in the JS runtime as a safety measure; then each pure-functional JS Wikifunction could run in the same context and call each other directly. [17:35:41] So in the case of passing a callback from a mutable state Wikifunction to a pure one, you'd play monad games I guess, treating it like an iterator maybe? [17:39:51] Freezing the globals keeps each module from interfering with the others if a validation failure lets through mutation of local state. [18:28:42] So the validator would check for two things: immutability and non-determinism. A function that changes nothing in its own state, but does call through to a non-deterministic Wikifunction (which might modify internal state across calls, or might pull from the outside world where data sets may change) would could as non-deterministic, but still immutable so it could be packed in the immutable-only-functions language [18:28:42] runtime [18:28:55] *would count [18:49:10] sorry, a completely different question (I am wary of any static analysis, as this would need to be repeated for every language we support, and hope we can avoid it): what if instead we compiled it to wasm and ran that instead, and relied on the wasm's container security model not to mess it up? or wouldn't that help because, well, a global being changed in the JS should be faithfully represented in the wasm compilation [18:50:19] denny_wmf: that is another possibility indeed, and you do get some strict isolation guarantees! lemme think about that [18:51:19] one thing to note is that you'd still have to serialize and deserializedarguments [18:51:30] rather than passing arrays and dictionaries directly [18:51:51] however it does give you strict isolation guarantee *and* in-process execution, which i like [18:52:07] i'm not sure there's a good JS to Wasm compiler out there yet; i'll take a look at the space :D [18:52:37] thanks! it's just an idea, but it was interesting given your work on the step-by-step debugger [18:52:46] in general a static Wasm target for JS functions isn't ideal because JS is hard to optimize at compile time, but there's some ways around this [18:53:13] one is to make the compiled wasm able to replace itself with a recompiled version of the func on demand [18:53:38] which is tricky but there are ways [18:53:41] :O [18:54:16] or even, going with consistent performance that's just not super-optimized but guaranteed safe may be acceptable [18:54:58] I'd start with that [18:55:03] yeah :D [18:55:08] no need to start with the clever version haha [18:55:08] once things work, optimizing can always come in later [18:55:12] exactly [18:55:38] as knuth said [18:55:42] yeah the one place where i think we need to think on first is determinism & caching, if we design the model right we can make it start easy to make and then make it fast [18:55:47] if we make the model wrong, then it's hard to fix :D [18:56:12] oops windows downloaded its updates be back in a few [18:56:28] I would focus entirely on deterministic and functionally transparent code at first [18:56:34] kk [18:57:56] *nod* [18:59:02] Yeah there's a couple models we can go with concentrating on the pure func code. I'll write up more notes later :) [19:01:20] there's plenty of stuff that is very useful even with that restriction [19:01:55] and enough for us to learn while getting it up and running :) [21:06:04] denny_wmf: few initial notes on https://www.mediawiki.org/wiki/Extension:WikiLambda/Jupyter_kernel_proposal#Case_study:_JavaScript_isolation with some areas i'll expand later :D [21:07:29] the compile-to-wasm case actually interesting and has some big benefits for call time [21:07:55] writing a js compiler and runtime is a lot of work though ;) [21:08:47] reusing v8 has its own huge advantages, and can be similarly managed *if* we can enforce immutability without the guarantees we make [21:09:09] within a JS context though it's hard to lock down mutation of state if you manage to write new code that escaped the validation check [21:09:22] like you can freeze the global objects to prevent state transfer between modules (good) [21:09:36] BUT you can't stop a function from modifying its own arguments, probably [21:09:58] or objects it itself creates that haven't gone over a function bridge boundary [21:10:27] so that's where rolling our own has a potential advantage, in that we could forbid all assignment operators and auto-freeze all objects etc [21:10:53] and at least it's implementing a language standard that already exists ;) [21:11:04] so that's a big advantage, even if it's a big standard, over making up a custom language [21:12:43] and i think i could actually do optimization sensibly, it would be a fun project if we end up doing it ;) [22:08:24] ooh [22:08:26] iterators [22:08:43] i want an iterable data type as well as callbacks :D [22:09:49] could allow processing large data sets in a nice functional way without loading huge data sets in memory or manually constructing callback sequences