On Thursday, August 8, 2019 at 8:24:02 AM UTC-5, gmhwxi wrote: > > > Because tracking effects is no longer planned in ATS3, we need to > think about how to handle effects incurred by calling external functions. > > We can introduce an abstrace linear VIEW IO: > > absview IO > > Say a function foo needs to do IO. Then it has to have a proof of the view > IO: > > fun foo(!IO | ...): ... > > This is just a monadic style of handing effects in Haskell. >
This seems very similar to how Mercury handles I/O: the program entry point gets (and requires back) a unique value representing the state of the world, and Mercury's uniqueness system requires that this be value be singly-threaded throughout the program, allowing the 'optimization' of in-place modifications to the universe, i.e., side-effects. So you have 1. a type 'io.state' 2. the main entry point and all I/O functions supplying and requiring a value of this type, with 'destructive input' and 'unique output' parameters to enforce its uniqueness 3. something in the implementation that prevents all this value-passing from causing any work at runtime This system is very easy to work with. Going with an absview instead of a (Mercury-like) viewtype makes it more obvious that nothing happens at runtime. OTOH, I thought ATS3 was supposed to be easier than ATS2? :-) Is it so much easier in other respects that making it pure is fine? IO is so-called because there is I and O in IO. So we may also introduce > > absview I and O > > and proof functions > > prfun IO_split : IO -> (I, O) > prfun IO_unsplit: (I, O) -> IO > > If a function only does I but no O, then it only needs a proof of the I > view: > > fun foo2 (!I | ...): ... > > Again, this is just a note put here as a reminder. > Even though the term is I/O, I don't think it's a useful distinction to separate I from O. The most basic interaction is prompted input, which requires the prompt. Graphically, in order to receive a click to a button, you have to show the dialog window with the button. And, the prompt absolutely must happen before the input: even if you separate I and O, they can't be separately ordered so that some runs of the program would show the prompt after asking for the input. Operations like 'make directory' and 'delete a file' need to be treated like I/O but don't much make sense as either I or O, and even if you suggest that they're O, the program can gain information from the result of these operations. -- You received this message because you are subscribed to the Google Groups "ats-lang-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/d5118001-9937-4dba-9cae-8a644017b8e7%40googlegroups.com.
