>>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?
"non-pure" style is still supported:
fun print(i: int): void =
{
val IO = IO_acquire()
val ( ) = print_pure(IO, i)
val ( ) = IO_release(IO)
}
On Thu, Aug 8, 2019 at 6:27 PM Julian Fondren <julian.fond...@gmail.com>
wrote:
> 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
> <https://groups.google.com/d/msgid/ats-lang-users/d5118001-9937-4dba-9cae-8a644017b8e7%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPPSPLodUP%3D7qv3iDM9Kq-dFL%2BvwO5dyDwJ-zTZUdRUuW43LmQ%40mail.gmail.com.
