[00:00:15] But one way to go in that direction is to replace all the global objects with wrappers or proxies that forbid altering their properties or extending them [00:00:30] I'm wondering if there's a different solution [00:00:42] Some non well formed code that relies on altering globals would fail, but most code should work reasonably well [00:01:05] Because if we need to do that for every programming language we support we'll move very slowly [00:01:44] Yeah. I worry the same thing about neutering non deterministic APIs though -- there's always going to be something we missed [00:03:36] (we should invent new licenses. ND is for non-deterministic, SA for "synchronous-asynchronous" etc.) [00:03:46] Lol [00:04:48] If we can't harden global state I think we're going to have real practical performance problems from firing up new contexts all the time [00:13:14] I think Adam Baso brought up an interesting js runtime called deno [00:13:30] yay Deno (re @vrandecic: I think Adam Baso brought up an interesting js runtime called deno) [00:13:55] You used it? [00:14:09] No just learning [00:14:22] It looked very early tech last time I checked [00:14:39] (It feels a lot better than node, from what I've used of both) [00:19:33] External libraries wouldn't need to pass our requirements for purity [00:19:56] Hmm, but what do you do if their functions are called and then alter state? [00:20:09] Well, that's what shouldn't work [00:20:34] We could try to run the code in slow isolated mode, with a lot of context calls [00:21:01] To test, in lieu of a static analysis [00:21:20] I'm being too hacky... [00:44:18] I feel like either we can enforce determinism from inputs or we can't. If we can't, and any function that imports data from the database cannot be so validated, then we need an explicit model for caching that the functions themselves can manage [00:45:49] I think it's more important for the behavior to be well defined and consistent than to be pure functional :) [00:56:45] Agreed. [00:58:49] When we get to functions that grab data from external sources we need to rethink parts of our approach, in particular wrt purity [01:09:25] I think that's a stage we need to plan for at the beginning, otherwise we may bake in choices that make sense for statically verifiable pure functions that don't match a world where languages being used have mutable state and are processing data from a mutable database and that's the entire reason for the project. :) [01:15:15] I worry that the main benefit of pure functions is that it sounds clever to cache them based on input, and if you guarantee that happens it seems nice. But with mutable world state that turns into an approximation; functions may return different results at different times with the same input. Inputs may not make good cache keys as they may be multi-megabyte arrays of data dictionaries, or closure references that [01:15:15] themselves may return different data when called multiple times [01:16:28] If none of the assumptions if pure functions hold, then we have to ask what we want out of approximating them. Just the caching behavior? Make it explicit and put it under function authors control. [01:23:18] Basically, have metadata on each function that specifies caching behavior? (You discuss this in your essay regarding a Wikidada property) [01:24:23] Yeah, either as metadata on the function or as metadata on the cache entry as specified by running code [01:24:41] Advantage of doing it from code is you can specify what inputs matter and how [01:25:00] I wanna flesh that idea out more and see if I can make it more ergonomic :) [01:25:29] Also I am *all in* on Wikidada ;) ;) ;) [01:27:09] The main ways to hook invalidation are checks at the next read time or event hooks like triggering on a change to a certain Wikidata item or a specific property [01:27:45] Which brings the worry of registering too many hooks and slowing down operations ;) [01:27:53] Anyway it's the weekend ;) [01:28:04] I'll save it for Monday! [05:15:56] it's all a bit too technical for me but the talk of functions which might not always return the same thing got me wondering what might do that, which made me wonder how something like returning the current month or calculating the age of something would work [05:17:01] both of which depend on the current time and you have to get that somehow [05:22:25] Right. We would need a solution for that, and those are great examples of why functions should be able to define their own caching strategies - a "get the current year" functions can cache longer than the "get the current date" function. [05:23:10] For now we didn't plan yet how to solve that. I'd like to push that for later. [05:25:11] One solution is to basically give the current date as an argument, and not as a function. So your function wouldn't be "age(Biden)" but "age At(Biden, 2021-02-27)" [05:25:38] It's not a perfect solution, but it works until something better is there [05:26:16] And Brion's solution certainly is better [13:50:35] did the same test with Python instead of JS, and it takes ~1m30s of wall-clock time (and some 6m of CPU time) just for 1000 iterations 😬 (re @lucaswerkmeister: I did a test with a JS function calling an eneyj function calling another JS function, and the outer JS function has a loop with one million iterations – runs in ~3m20s with proper isolation, or 1s without it) [13:50:47] maybe that’s why https://github.com/oracle/graalpython is still experimental and all that… [14:11:56] (for GraalJS, CPU time is 3m30s compared to 3m20s wall-clock time, so that seems to be more single-threaded) [20:29:32] Oh what do y'all think of having determinism (and if not, some kind of meta info about its caching guarantees) as function metadata that can be thought of as part of the function's type? Then pure-function abstractions can freely call each other but would get a compile time error calling a not guaranteed JS function, with options to do safe but slow opt in/out, or refactoring data flow to make the programs type [20:29:32] guarantees cleaner? [20:30:11] Anyway that might be a way to give us practical bon deterministic tools while still being able to have strong determinism for functions that can make that guarantee [20:30:25] Then we can optimize each case for it's strengths [20:31:05] that kind of sounds like a new version of https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ to me [20:31:11] (I hope that link makes it across the IRC bridge) [20:43:29] the link does, the link text doesn't [20:47:45] I guess that’s alright