<div dir="ltr"><div>I sort of see why you might now, but I'm not sure it's what you mean? Could you elaborate?</div><div><br></div><div>I think you can if you base this in some sort of indexed monad and have a way to join indices. Your process then become a -> (ioM e) a, where e is the neutral element or index for the index join operation. Perhaps indices could denote sets of permissions or capabilities.<br></div><div><br></div><div>Ivan<br></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 5 Oct 2018 at 22:09, Vanessa McHale <<a href="mailto:vanessa.mchale@iohk.io">vanessa.mchale@iohk.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another thing that would be different in the OS case would likely be<br>
that one could not have programs/processes of type<br>
<br>
a -> a<br>
<br>
...which would make any types stored in an ABI a good deal less flexible<br>
than those in Haskell.<br>
<br>
<br>
On 10/05/2018 02:46 PM, MarLinn wrote:<br>
><br>
>> You'd probably want an ABI for types, no? You'd need a new executable<br>
>> format (among many other things!).<br>
>><br>
>> The question is: would it be worth it? Types are wonderful in Haskell<br>
>> because they allow us to structure our programs. What would structuring<br>
>> processes via types accomplish? It would improve the situation with<br>
>> shell scripting/pipes as you allude, but that's still an immense amount<br>
>> of effort.<br>
><br>
> Now that I think about it… having something like an ABI or a "Haskell<br>
> binary format" with types in it might indeed be useful in more cases<br>
> than this one.<br>
><br>
> It seems when a Haskell projects gets a bit larger people tend to<br>
> search for ways to make it more modular. They try plugin frameworks,<br>
> OS-level dynamic linking, on-the-fly compilation etc. But I repeatedly<br>
> get the feeling that all these current approaches aren't actually very<br>
> good. But what if we had some kind of specialized format for compiled,<br>
> dynamically loadable, typed Haskell libraries? Something between a<br>
> plain OS library and bytecode. This might help make programs more<br>
> modular while keeping them type safe.<br>
><br>
> One thing that might be useful to add next would be some kind of<br>
> centralized registry of types, so that a plugin/library could extend<br>
> the ways the system could be extended.<br>
><br>
> And going along this line of thought even further leads to… uhm…<br>
> oh.    OH.<br>
><br>
> Ok, so, it's the month of Halloween, right?<br>
><br>
> Because… OSGi, but in Haskell.<br>
><br>
> Well, maybe there's some sane point in between?<br>
><br>
> Cheers,<br>
> MarLinn<br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>