Anton (Sep 07 2026 at 10:10): Anton (Sep 07 2026 at 10:10):Now that packages can call effectful functions with PR#11079 "Allow packages to depend on platforms", I feel like it should be super clear when a package is pure.
One way to do this would be to require the name to start with impure-, or effect-, maybe even dirty- :p
What do you think?
Luke Boswell (Sep 07 2026 at 11:06):maybe the package alias should include a ! -- like instead of terrocotta: "https://... and import terrocotta.Thing it must be terrocotta!: "https://... and import terrocotta!.Thing?
Richard Feldman (Sep 07 2026 at 12:02):hm, does that matter at the package level when we already have it at the function level? :thinking:
Richard Feldman (Sep 07 2026 at 12:02):like just depending on a collection of functions is harmless; it only matters if I actually call an effectful function
Luke Boswell (Sep 07 2026 at 12:34):I'm not really following the concerns here about impure packages... is it that you have to audit what the package is doing now because it could be making effects when you use it?
Anton (Sep 07 2026 at 16:23):Richard Feldman said:
like just depending on a collection of functions is harmless; it only matters if I actually call an effectful function
It could help remind people that they need to audit the code of a package (for the functions they use) when doing a version upgrade. Because now after an upgrade a package could steal your ssh keys
Richard Feldman (Sep 07 2026 at 20:39):that's a good point :+1:
Luke Boswell (Sep 07 2026 at 21:48):If you provided a bundle of effects to a package it could have done that before too though... like its the same isn't it?
Luke Boswell (Sep 07 2026 at 21:48):Or I guess now you don't really have the opportunity to wrap it in a closure and sandbox those effects (i.e. sit in the middle between the package and the platform)
Richard Feldman (Sep 08 2026 at 01:30):Luke Boswell said:
If you provided a bundle of effects to a package it could have done that before too though... like its the same isn't it?
also a good point :smile:
Richard Feldman (Sep 08 2026 at 01:32):well, in terms of the attack vector of "now after an upgrade a package could steal your ssh keys" it's always been the case that if you are giving the package access to effectful functions that can complete a given attack (e.g. stealing ssh keys) then upgrades become risky
Richard Feldman (Sep 08 2026 at 01:33):on the one hand, with platform-agnostic packages you have more control over what effectful functions they can access, so it's less risky - but the counterpoint would be that if we have a special "this package accesses platform operations directly" marker, that could give people a false sense of security around platform-agnostic packages
Richard Feldman (Sep 08 2026 at 01:34):a more thorough solution might be to have an upgrade tool which tells you how your code is using these packages - e.g. are you actually calling any effectful functions of theirs, and if so, where? etc.
Anton (Sep 08 2026 at 10:00):Yeah, that's a good direction. I'd like a tool that would give me a useful diff showing how the functions I use from a package have changed after an upgrade.
Luke Boswell (Sep 08 2026 at 10:15):Just spitballing here ... but wouldn't it be cool if we had some way to do fuzzing style coverage guided search through a roc app based purely on the host boundary.
I'm imaging a roc cli subcommand roc fuzz or something that basically simulates throwing random types at the roc entrypoints AND also random results from each effectful call with the goal to get as much coverage through the compiled (and instrumented) roc paths as possible...
Maybe this could show you which effects are being called and the paths to get there etc. Culturally we would be wanting people to build tests that help the tool get deeper coverage so you could have more confidence in the analysis.
What I like about fuzzing is that it is automatic in a way that means it finds things you would never have thought of yourself.
Luke Boswell (Sep 08 2026 at 10:19):I've tried recording "traces" of inputs and outputs around the roc calls but it blows up quickly with the amount of data you need to store. Maybe if we use a PRNG from a seed and the types we generate can be fully deterministic so we have infinite generation and avoid that cost.
Luke Boswell (Sep 08 2026 at 10:20):Or maybe some kind of static analysis would be way more efficient here.
Last updated: Sep 24 2026 at 15:59 UTC