Maybe what your want is some kind of mapfree function?
Please take a look at list_vt_mapfree.
For stream_vt, it makes sense to process a linear stream until some
condition is met
and then process the rest of the stream later.
On Thursday, July 14, 2016 at 1:41:00 PM UTC-4, Steinway Wu wrote:
>
stream_vt_con is considered an internal type; it should be kept as such.
>> fun {a,b:vt@ype} stream_vt_map$fopr (a - b): b
This is probably easier to use but less efficient when [a] is large. In C,
one rarely passes a big struct; always
passes a pointer to a big struct.
stream_vt is very differe
What about this? Let the worker function consume a. And in map, free the
constructor, instead of unfold the constructor.
fun {a,b:vt@ype} stream_vt_map_con (xs: stream_vt a): stream_vt_con b
fun {a,b:vt@ype} stream_vt_map$fopr (a - b): b
On Thursday, July 14, 2016 at 10:39:08 AM UTC-4, gmhwxi
1.
When [a] is a linear type, a?! is only the data part of [a] (that is, there
is no view in a?!).
When [a] is non-linear, then a?! is just [a].
2. When [a] is large (containing many bytes), call-by-reference can be more
efficient. The convention
in ATS is to use call-by-reference when linear
Hi,
In `stream_vt.dats`, I saw the following snippets,
fun {a:vt0p} {b:vt0p} stream_vt_map_con (xs: stream_vt (a)) : stream_vt_con
(b) = let
val xs_con = !xs
in
case+ xs_con of
| @stream_vt_cons(x, xs) => let
val y = stream_vt_map$fopr (x) // fopr is of type {a,b:vt@ype}
&a
