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): bOn Thursday, July 14, 2016 at 10:39:08 AM UTC-4, gmhwxi wrote:
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].
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 data is handled.
The ‘xs’ on the right-hand side is a variable (with address); its
content needs to be taken out before free@ can be called.
On Thu, Jul 14, 2016 at 9:20 AM, 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 different from stream; stream_vt is essentially just one
node (while stream is a list of nodes).
So when using stream_vt, one may use stream_vt(T) for a very big flat T.On Thu, Jul 14, 2016 at 1:40 PM, Steinway Wu stein...@gmail.com wrote:
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 wrote:
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].
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 data is handled.
The ‘xs’ on the right-hand side is a variable (with address); its
content needs to be taken out before free@ can be called.
On Thu, Jul 14, 2016 at 9:20 AM, Steinway Wu <> wrote:
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].
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 data is handled.
The ‘xs’ on the right-hand side is a variable (with address); its
content needs to be taken out before free@ can be called.On Thu, Jul 14, 2016 at 9:20 AM, Steinway Wu stein...@gmail.com wrote:
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:
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
On Thursday, July 14, 2016 at 10:39:08 AM UTC-4, gmhwxi wrote:
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].
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 data is handled.
The ‘xs’ on the right-hand side is a variable (with address); its
content needs to be taken out before free@ can be called.
On Thu, Jul 14, 2016 at 9:20 AM, Steinway Wu <> wrote: