Adding a view for partially initialized arrays to the prelude/libats?

Google Group
1

Hi all,

In version 1.1.0.0 of my file descriptor library, I introduced a view for
partially initialized arrays 1, which allows me to cleanly represent a
contiguous array that may have some elements initialized but may not have all
elements initialized. This is used in the type of the POSIX read function 2,
which may increase (but not decrease) the number of initialized values in the
array.

It seems like this is a generally useful concept applicable outside of this
library, so I was wondering: Would this be welcome in the prelude or in libats?
If so, where does it best fit?

Thanks,
Shea

2

OK, fair enough. Thanks!> On Apr 16, 2015, at 5:04 PM, gmhwxi gmh...@gmail.com wrote:

I can see some value of having partially_initialized_array_v.
However, in order to use it, I must know it first. I could be wrong, but
I don’t feel it is realistic to expect a programmer to learn the names of
such “secondary” concepts.

Also, I feel that contributions made to ATS should in general be done in
a distributed manner (vs. centralized manner).

The ‘atspkgreloc’ command allows on-line ATS packages to be directly
referred in one’s program. See:

https://github.com/githwxi/ATS-Postiats/tree/master/utils/atspkgreloc

On Thursday, April 16, 2015 at 4:06:02 PM UTC-4, Shea Levy wrote:
Actually, without partially_initialized_array I’m not sure how to write the type signature of read at all. I need to know how many bytes are initialized after the call, don’t I?

Or is your objection just to the presence of max? In that case, the array view itself can still go into the standard library, right?

On Apr 16, 2015, at 15:39, gmhwxi <gmh...@gmail.com <javascript:>> wrote:

As I see it, the question is not whether we can find a scenario where
the type is actually useful. It is a trade-off. In generally, the more informative
a type is, the more effort is needed to actually use it.

On Thursday, April 16, 2015 at 2:48:46 PM UTC-4, Shea Levy wrote:
The way I look at it, read is a very generic function whose semantics support a
wide array of use cases. Using partially_initialized_array reflects the full
generality of those semantics. Surely no one would dispute that if I want the
behavior of any old bytes remaining initialized, that behavior is indeed
guaranteed by the standard and all implementations?

One particular possible use case that comes to mind: Perhaps I store some
default value in my buffer, and then allow it to be overridden by something I
read from a file descriptor. Then if read returns 0 or -1, my buffer is still
ready to go to use however I wanted.

~Shea

On Apr 16, 2015, at 10:51 AM, gmhwxi <gmh...@gmail.com <>> wrote:

Personally, I feel max(fill, res) in the following interface for read
is problematic:

If you call ‘read’, the buffer gets overwritten. Logically, there isn’t
obvious justification for combining old buffer content and new buffer
content in this way.

fn read { fd: nat } { buf: addr } { fill, total: nat | fill <= total }
( ev: !errno_v ( free ) >> neg1_errno ( res )
, fdprf: !readable_filedes ( fd )
, !partially_initialized_array_v ( byte, fill, total, buf ) >>
partially_initialized_array_v ( byte, max ( fill, res ), total, buf )
| fd: int ( fd )
, buf: ptr buf
, total: size_t total
): #[ res: int ] ssize_t ( res ) = “ext#”

On Thursday, April 16, 2015 at 7:52:50 AM UTC-4, Shea Levy wrote:
Hi all,

In version 1.1.0.0 of my file descriptor library, I introduced a view for
partially initialized arrays [1], which allows me to cleanly represent a
contiguous array that may have some elements initialized but may not have all
elements initialized. This is used in the type of the POSIX read function [2],
which may increase (but not decrease) the number of initialized values in the
array.

It seems like this is a generally useful concept applicable outside of this
library, so I was wondering: Would this be welcome in the prelude or in libats?
If so, where does it best fit?

Thanks,
Shea

[1]: https://github.com/shlevy/elvysh-filedes/blob/v1.1.0.0/include/elvysh/filedes.sats#L26-L46 https://github.com/shlevy/elvysh-filedes/blob/v1.1.0.0/include/elvysh/filedes.sats#L26-L46
[2]: https://github.com/shlevy/elvysh-filedes/blob/v1.1.0.0/include/elvysh/filedes.sats#L57-L58 https://github.com/shlevy/elvysh-filedes/blob/v1.1.0.0/include/elvysh/filedes.sats#L57-L58

–
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...@googlegroups.com <>.
To post to this group, send email to ats-l...@googlegroups.com <>.
Visit this group at http://groups.google.com/group/ats-lang-users http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/edd706ea-8cba-4b64-88d8-c39b23f41e83%40googlegroups.com https://groups.google.com/d/msgid/ats-lang-users/edd706ea-8cba-4b64-88d8-c39b23f41e83%40googlegroups.com.

–
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...@googlegroups.com <javascript:>.
To post to this group, send email to ats-l...@googlegroups.com <javascript:>.
Visit this group at http://groups.google.com/group/ats-lang-users http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/55da5425-5385-4345-a388-e69004c04c72%40googlegroups.com https://groups.google.com/d/msgid/ats-lang-users/55da5425-5385-4345-a388-e69004c04c72%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-user...@googlegroups.com mailto:ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com mailto:ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/537977b8-637e-4e7d-8f9b-c9811f3d715e%40googlegroups.com https://groups.google.com/d/msgid/ats-lang-users/537977b8-637e-4e7d-8f9b-c9811f3d715e%40googlegroups.com?utm_medium=email&utm_source=footer.

3

I can see some value of having partially_initialized_array_v.
However, in order to use it, I must know it first. I could be wrong, but
I don’t feel it is realistic to expect a programmer to learn the names of
such “secondary” concepts.

Also, I feel that contributions made to ATS should in general be done in
a distributed manner (vs. centralized manner).

The ‘atspkgreloc’ command allows on-line ATS packages to be directly
referred in one’s program. See:

https://github.com/githwxi/ATS-Postiats/tree/master/utils/atspkgrelocOn Thursday, April 16, 2015 at 4:06:02 PM UTC-4, Shea Levy wrote:

Actually, without partially_initialized_array I’m not sure how to write
the type signature of read at all. I need to know how many bytes are
initialized after the call, don’t I?

Or is your objection just to the presence of max? In that case, the array
view itself can still go into the standard library, right?

On Apr 16, 2015, at 15:39, gmhwxi <gmh...@gmail.com <javascript:>> wrote:

As I see it, the question is not whether we can find a scenario where
the type is actually useful. It is a trade-off. In generally, the more
informative
a type is, the more effort is needed to actually use it.

On Thursday, April 16, 2015 at 2:48:46 PM UTC-4, Shea Levy wrote:

The way I look at it, read is a very generic function whose semantics
support a
wide array of use cases. Using partially_initialized_array reflects the
full
generality of those semantics. Surely no one would dispute that if I want
the
behavior of any old bytes remaining initialized, that behavior is indeed
guaranteed by the standard and all implementations?

One particular possible use case that comes to mind: Perhaps I store some
default value in my buffer, and then allow it to be overridden by
something I
read from a file descriptor. Then if read returns 0 or -1, my buffer is
still
ready to go to use however I wanted.

~Shea

On Apr 16, 2015, at 10:51 AM, gmhwxi gmh...@gmail.com wrote:

Personally, I feel max(fill, res) in the following interface for read
is problematic:

If you call ‘read’, the buffer gets overwritten. Logically, there isn’t
obvious justification for combining old buffer content and new buffer
content in this way.

fn read { fd: nat } { buf: addr } { fill, total: nat | fill <= total }
( ev: !errno_v ( free ) >> neg1_errno ( res )
, fdprf: !readable_filedes ( fd )
, !partially_initialized_array_v ( byte, fill, total, buf ) >>
partially_initialized_array_v ( byte, max ( fill, res ), total, buf )
| fd: int ( fd )
, buf: ptr buf
, total: size_t total
): #[ res: int ] ssize_t ( res ) = “ext#”

On Thursday, April 16, 2015 at 7:52:50 AM UTC-4, Shea Levy wrote:
Hi all,

In version 1.1.0.0 of my file descriptor library, I introduced a view
for
partially initialized arrays 1, which allows me to cleanly represent
a
contiguous array that may have some elements initialized but may not
have all
elements initialized. This is used in the type of the POSIX read
function 2,
which may increase (but not decrease) the number of initialized values
in the
array.

It seems like this is a generally useful concept applicable outside of
this
library, so I was wondering: Would this be welcome in the prelude or in
libats?
If so, where does it best fit?

Thanks,
Shea

–
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...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/edd706ea-8cba-4b64-88d8-c39b23f41e83%40googlegroups.com.

–
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...@googlegroups.com <javascript:>.
To post to this group, send email to ats-l...@googlegroups.com
<javascript:>.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/55da5425-5385-4345-a388-e69004c04c72%40googlegroups.com
https://groups.google.com/d/msgid/ats-lang-users/55da5425-5385-4345-a388-e69004c04c72%40googlegroups.com?utm_medium=email&utm_source=footer
.

4

As I see it, the question is not whether we can find a scenario where
the type is actually useful. It is a trade-off. In generally, the more
informative
a type is, the more effort is needed to actually use it.On Thursday, April 16, 2015 at 2:48:46 PM UTC-4, Shea Levy wrote:

The way I look at it, read is a very generic function whose semantics
support a
wide array of use cases. Using partially_initialized_array reflects the
full
generality of those semantics. Surely no one would dispute that if I want
the
behavior of any old bytes remaining initialized, that behavior is indeed
guaranteed by the standard and all implementations?

One particular possible use case that comes to mind: Perhaps I store some
default value in my buffer, and then allow it to be overridden by
something I
read from a file descriptor. Then if read returns 0 or -1, my buffer is
still
ready to go to use however I wanted.

~Shea

On Apr 16, 2015, at 10:51 AM, gmhwxi <gmh...@gmail.com <javascript:>> wrote:

Personally, I feel max(fill, res) in the following interface for read
is problematic:

If you call ‘read’, the buffer gets overwritten. Logically, there isn’t
obvious justification for combining old buffer content and new buffer
content in this way.

fn read { fd: nat } { buf: addr } { fill, total: nat | fill <= total }
( ev: !errno_v ( free ) >> neg1_errno ( res )
, fdprf: !readable_filedes ( fd )
, !partially_initialized_array_v ( byte, fill, total, buf ) >>
partially_initialized_array_v ( byte, max ( fill, res ), total, buf )
| fd: int ( fd )
, buf: ptr buf
, total: size_t total
): #[ res: int ] ssize_t ( res ) = “ext#”

On Thursday, April 16, 2015 at 7:52:50 AM UTC-4, Shea Levy wrote:
Hi all,

In version 1.1.0.0 of my file descriptor library, I introduced a view
for
partially initialized arrays 1, which allows me to cleanly represent a
contiguous array that may have some elements initialized but may not
have all
elements initialized. This is used in the type of the POSIX read
function 2,
which may increase (but not decrease) the number of initialized values
in the
array.

It seems like this is a generally useful concept applicable outside of
this
library, so I was wondering: Would this be welcome in the prelude or in
libats?
If so, where does it best fit?

Thanks,
Shea

–
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...@googlegroups.com <javascript:>.
To post to this group, send email to ats-l...@googlegroups.com
<javascript:>.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/edd706ea-8cba-4b64-88d8-c39b23f41e83%40googlegroups.com.

5

Personally, I feel max(fill, res) in the following interface for read
is problematic:

If you call ‘read’, the buffer gets overwritten. Logically, there isn’t
obvious justification for combining old buffer content and new buffer
content in this way.

fn read { fd: nat } { buf: addr } { fill, total: nat | fill <= total } (
ev: !errno_v ( free ) >> neg1_errno ( res ) , fdprf: !readable_filedes (
fd ) , !partially_initialized_array_v ( byte, fill, total, buf ) >> partially_initialized_array_v
( byte, max ( fill, res ), total, buf ) | fd: int ( fd ) , buf: ptr buf ,
total: size_t total ): #[ res: int ] ssize_t ( res ) = "ext#"On Thursday, April 16, 2015 at 7:52:50 AM UTC-4, Shea Levy wrote:

Hi all,

In version 1.1.0.0 of my file descriptor library, I introduced a view for
partially initialized arrays 1, which allows me to cleanly represent a
contiguous array that may have some elements initialized but may not have
all
elements initialized. This is used in the type of the POSIX read function
2,
which may increase (but not decrease) the number of initialized values in
the
array.

It seems like this is a generally useful concept applicable outside of
this
library, so I was wondering: Would this be welcome in the prelude or in
libats?
If so, where does it best fit?

Thanks,
Shea

6

By the way, based on this discussion version 1.2.0.0 of my file descriptor
library added some view-changing functions 1 for collapsing a max constraint
in a partially initialized array to the older or newer value. Most of the time
partially_initialized_array_unmax_after will be used, which takes the value
returned by read and ignores however many values were initialized beforehand.

~Shea

1: https://github.com/shlevy/elvysh-filedes/blob/v1.2.0.0/include/elvysh/partially-initialized-array.sats#L23-L71> On Apr 16, 2015, at 9:58 PM, Shea Levy sh...@shealevy.com wrote:

OK, fair enough. Thanks!

On Apr 16, 2015, at 5:04 PM, gmhwxi gmh...@gmail.com wrote:

I can see some value of having partially_initialized_array_v.
However, in order to use it, I must know it first. I could be wrong, but
I don’t feel it is realistic to expect a programmer to learn the names of
such “secondary” concepts.

Also, I feel that contributions made to ATS should in general be done in
a distributed manner (vs. centralized manner).

The ‘atspkgreloc’ command allows on-line ATS packages to be directly
referred in one’s program. See:

https://github.com/githwxi/ATS-Postiats/tree/master/utils/atspkgreloc

On Thursday, April 16, 2015 at 4:06:02 PM UTC-4, Shea Levy wrote:
Actually, without partially_initialized_array I’m not sure how to write the type signature of read at all. I need to know how many bytes are initialized after the call, don’t I?

Or is your objection just to the presence of max? In that case, the array view itself can still go into the standard library, right?

On Apr 16, 2015, at 15:39, gmhwxi gmh...@gmail.com wrote:

As I see it, the question is not whether we can find a scenario where
the type is actually useful. It is a trade-off. In generally, the more informative
a type is, the more effort is needed to actually use it.

On Thursday, April 16, 2015 at 2:48:46 PM UTC-4, Shea Levy wrote:
The way I look at it, read is a very generic function whose semantics support a
wide array of use cases. Using partially_initialized_array reflects the full
generality of those semantics. Surely no one would dispute that if I want the
behavior of any old bytes remaining initialized, that behavior is indeed
guaranteed by the standard and all implementations?

One particular possible use case that comes to mind: Perhaps I store some
default value in my buffer, and then allow it to be overridden by something I
read from a file descriptor. Then if read returns 0 or -1, my buffer is still
ready to go to use however I wanted.

~Shea

On Apr 16, 2015, at 10:51 AM, gmhwxi gmh...@gmail.com wrote:

Personally, I feel max(fill, res) in the following interface for read
is problematic:

If you call ‘read’, the buffer gets overwritten. Logically, there isn’t
obvious justification for combining old buffer content and new buffer
content in this way.

fn read { fd: nat } { buf: addr } { fill, total: nat | fill <= total }
( ev: !errno_v ( free ) >> neg1_errno ( res )
, fdprf: !readable_filedes ( fd )
, !partially_initialized_array_v ( byte, fill, total, buf ) >>
partially_initialized_array_v ( byte, max ( fill, res ), total, buf )
| fd: int ( fd )
, buf: ptr buf
, total: size_t total
): #[ res: int ] ssize_t ( res ) = “ext#”

On Thursday, April 16, 2015 at 7:52:50 AM UTC-4, Shea Levy wrote:
Hi all,

In version 1.1.0.0 of my file descriptor library, I introduced a view for
partially initialized arrays 1, which allows me to cleanly represent a
contiguous array that may have some elements initialized but may not have all
elements initialized. This is used in the type of the POSIX read function 2,
which may increase (but not decrease) the number of initialized values in the
array.

It seems like this is a generally useful concept applicable outside of this
library, so I was wondering: Would this be welcome in the prelude or in libats?
If so, where does it best fit?

Thanks,
Shea

–
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...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/edd706ea-8cba-4b64-88d8-c39b23f41e83%40googlegroups.com.

–
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...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/55da5425-5385-4345-a388-e69004c04c72%40googlegroups.com.

–
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-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/537977b8-637e-4e7d-8f9b-c9811f3d715e%40googlegroups.com.

–
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-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/EDBF81EF-5F7C-4804-A98A-2488CB5A3900%40shealevy.com.

7

The way I look at it, read is a very generic function whose semantics support a
wide array of use cases. Using partially_initialized_array reflects the full
generality of those semantics. Surely no one would dispute that if I want the
behavior of any old bytes remaining initialized, that behavior is indeed
guaranteed by the standard and all implementations?

One particular possible use case that comes to mind: Perhaps I store some
default value in my buffer, and then allow it to be overridden by something I
read from a file descriptor. Then if read returns 0 or -1, my buffer is still
ready to go to use however I wanted.

~Shea> On Apr 16, 2015, at 10:51 AM, gmhwxi gmh...@gmail.com wrote:

Personally, I feel max(fill, res) in the following interface for read
is problematic:

If you call ‘read’, the buffer gets overwritten. Logically, there isn’t
obvious justification for combining old buffer content and new buffer
content in this way.

fn read { fd: nat } { buf: addr } { fill, total: nat | fill <= total }
( ev: !errno_v ( free ) >> neg1_errno ( res )
, fdprf: !readable_filedes ( fd )
, !partially_initialized_array_v ( byte, fill, total, buf ) >>
partially_initialized_array_v ( byte, max ( fill, res ), total, buf )
| fd: int ( fd )
, buf: ptr buf
, total: size_t total
): #[ res: int ] ssize_t ( res ) = “ext#”

On Thursday, April 16, 2015 at 7:52:50 AM UTC-4, Shea Levy wrote:
Hi all,

In version 1.1.0.0 of my file descriptor library, I introduced a view for
partially initialized arrays 1, which allows me to cleanly represent a
contiguous array that may have some elements initialized but may not have all
elements initialized. This is used in the type of the POSIX read function 2,
which may increase (but not decrease) the number of initialized values in the
array.

It seems like this is a generally useful concept applicable outside of this
library, so I was wondering: Would this be welcome in the prelude or in libats?
If so, where does it best fit?

Thanks,
Shea

–
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-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/edd706ea-8cba-4b64-88d8-c39b23f41e83%40googlegroups.com.

8

Actually, without partially_initialized_array I’m not sure how to write the type signature of read at all. I need to know how many bytes are initialized after the call, don’t I?

Or is your objection just to the presence of max? In that case, the array view itself can still go into the standard library, right?> On Apr 16, 2015, at 15:39, gmhwxi gmh...@gmail.com wrote:

As I see it, the question is not whether we can find a scenario where
the type is actually useful. It is a trade-off. In generally, the more informative
a type is, the more effort is needed to actually use it.

On Thursday, April 16, 2015 at 2:48:46 PM UTC-4, Shea Levy wrote:

The way I look at it, read is a very generic function whose semantics support a
wide array of use cases. Using partially_initialized_array reflects the full
generality of those semantics. Surely no one would dispute that if I want the
behavior of any old bytes remaining initialized, that behavior is indeed
guaranteed by the standard and all implementations?

One particular possible use case that comes to mind: Perhaps I store some
default value in my buffer, and then allow it to be overridden by something I
read from a file descriptor. Then if read returns 0 or -1, my buffer is still
ready to go to use however I wanted.

~Shea

On Apr 16, 2015, at 10:51 AM, gmhwxi gmh...@gmail.com wrote:

Personally, I feel max(fill, res) in the following interface for read
is problematic:

If you call ‘read’, the buffer gets overwritten. Logically, there isn’t
obvious justification for combining old buffer content and new buffer
content in this way.

fn read { fd: nat } { buf: addr } { fill, total: nat | fill <= total }
( ev: !errno_v ( free ) >> neg1_errno ( res )
, fdprf: !readable_filedes ( fd )
, !partially_initialized_array_v ( byte, fill, total, buf ) >>
partially_initialized_array_v ( byte, max ( fill, res ), total, buf )
| fd: int ( fd )
, buf: ptr buf
, total: size_t total
): #[ res: int ] ssize_t ( res ) = “ext#”

On Thursday, April 16, 2015 at 7:52:50 AM UTC-4, Shea Levy wrote:
Hi all,

In version 1.1.0.0 of my file descriptor library, I introduced a view for
partially initialized arrays 1, which allows me to cleanly represent a
contiguous array that may have some elements initialized but may not have all
elements initialized. This is used in the type of the POSIX read function 2,
which may increase (but not decrease) the number of initialized values in the
array.

It seems like this is a generally useful concept applicable outside of this
library, so I was wondering: Would this be welcome in the prelude or in libats?
If so, where does it best fit?

Thanks,
Shea

–
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...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/edd706ea-8cba-4b64-88d8-c39b23f41e83%40googlegroups.com.

–
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-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/55da5425-5385-4345-a388-e69004c04c72%40googlegroups.com.