var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid using
refs?
I am a bit rusty: are there other ways to pack/unpack (fold/unfold?) views
with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly better
for non-GC environments (though I guess it is not much difference in this
regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_data outside of a
function. Another function could be created to do the initialization and
return a ‘var’, but just curious what is generally advised.
I tried running the make, and got the following error
postiats_learn/globalvar/TextProcessing.dats: 429(line=30, offs=1) –
461(line=30, offs=33): error(1): the file [{$GLIB}/SATS/glib.sats] is not
available for staloading.
I guess it has something to do with contrib. What’s the best practice to
use contrib currently? (Maybe there’s already a thread discussing about it,
please help me find the link. Thanks)
(I use two git repositories, one for ATS-Postiats, one for
ATS-Postiats-contrib. Therefore I don’t want to move one repository into
another, which is suggested by http://www.ats-lang.org/DOWNLOAD/#installation_atscntrb)On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
abst@ype foo_abstype = ptr // @ should be dropped
typedef foo_type = foo_abstype
Normally, there should be some functions (methods) involving ‘foo_type’
that are declared after the introduction of foo_abstype. If you just want
to have
a global value of the type foo_type, then there is really no need to
introduce
foo_abstype in the first place.On Wednesday, May 14, 2014 12:02:28 AM UTC-4, Brandon Barker wrote:
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.
On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs in
ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the
initialization
code is included in the body of a function (that is called by
‘dynload’).
I am just trying to keep code more tidy and readable by placing it in an
initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid
using refs?
I am a bit rusty: are there other ways to pack/unpack (fold/unfold?)
views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_data outside
of a function. Another function could be created to do the initialization
and return a ‘var’, but just curious what is generally advised.
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs in ATS.
A ‘var’ is stack-allocated, so it cannot be returned.
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the initialization
code is included in the body of a function (that is called by ‘dynload’).On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid using
refs?
I am a bit rusty: are there other ways to pack/unpack (fold/unfold?) views
with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly better
for non-GC environments (though I guess it is not much difference in this
regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_data outside of a
function. Another function could be created to do the initialization and
return a ‘var’, but just curious what is generally advised.
If we drop the @, we should change the
typedef foo_concrete =
@{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
to
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
as well.On Wednesday, May 14, 2014 12:45:43 AM UTC-4, gmhwxi wrote:
Allow me to go back to your original question.
abst@ype foo_abstype = ptr // @ should be dropped
typedef foo_type = foo_abstype
Normally, there should be some functions (methods) involving ‘foo_type’
that are declared after the introduction of foo_abstype. If you just want
to have
a global value of the type foo_type, then there is really no need to
introduce
foo_abstype in the first place.
On Wednesday, May 14, 2014 12:02:28 AM UTC-4, Brandon Barker wrote:
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.
On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs in
ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the
initialization
code is included in the body of a function (that is called by
‘dynload’).
I am just trying to keep code more tidy and readable by placing it in
an initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid
using refs?
I am a bit rusty: are there other ways to pack/unpack (fold/unfold?)
views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_data outside
of a function. Another function could be created to do the initialization
and return a ‘var’, but just curious what is generally advised.
I tried running the make, and got the following error
postiats_learn/globalvar/TextProcessing.dats: 429(line=30, offs=1) –
461(line=30, offs=33): error(1): the file [{$GLIB}/SATS/glib.sats] is not
available for staloading.
I guess it has something to do with contrib. What’s the best practice to
use contrib currently? (Maybe there’s already a thread discussing about it,
please help me find the link. Thanks)
Drop the “= ptr” as well.On Wednesday, May 14, 2014 10:52:13 AM UTC-4, Brandon Barker wrote:
Thanks - I actually did try that after my last mail (should’ve tried
earlier), but then I got errors along these lines when trying to assign to
the record values - maybe I’m doing it wrong:
The 1st translation (fixity) of [abstractTypeReferenced.dats] is
successfully completed!
The 2nd translation (binding) of [abstractTypeReferenced.dats] is
successfully completed!
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
(* Normally in a SATS file *)
abstype foo_abstype = ptr
typedef foo_type = foo_abstype
(* Normally in the DATS file *)
(* ****** ****** *)
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
(* ****** ****** *)
local
var foo_data: foo_type
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
end (end-of-local)
On Wednesday, May 14, 2014 10:40:04 AM UTC-4, Zhiqiang Ren wrote:
If we drop the @, we should change the
typedef foo_concrete =
@{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
to
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
as well.
On Wednesday, May 14, 2014 12:45:43 AM UTC-4, gmhwxi wrote:
Allow me to go back to your original question.
abst@ype foo_abstype = ptr // @ should be dropped
typedef foo_type = foo_abstype
Normally, there should be some functions (methods) involving ‘foo_type’
that are declared after the introduction of foo_abstype. If you just
want to have
a global value of the type foo_type, then there is really no need to
introduce
foo_abstype in the first place.
On Wednesday, May 14, 2014 12:02:28 AM UTC-4, Brandon Barker wrote:
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.
On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs
in ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the
initialization
code is included in the body of a function (that is called by
‘dynload’).
I am just trying to keep code more tidy and readable by placing it in
an initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid
using refs?
I am a bit rusty: are there other ways to pack/unpack
(fold/unfold?) views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_dataoutside of a function. Another function could be created to do the
initialization and return a ‘var’, but just curious what is generally
advised.
Brandon Barker
brandon…@gmail.comFrom: Brandon Barker brandon...@gmail.com
Date: Wed, May 14, 2014 at 7:56 AM
Subject: Re: packing a view and address in local scope
To: gmhwxi gmh...@gmail.com
Normally, there should be some functions (methods) involving ‘foo_type’
that are declared after the introduction of foo_abstype. If you just want
to have
a global value of the type foo_type, then there is really no need to
introduce
foo_abstype in the first place.
This is a good point - I’d been porting some C functions that I’d made to
explicitly not use globals and instead take a couple of function arguments,
but with ATS’s local scope feature, I wanted to drop the function
arguments. I should no longer need the abstypes in these cases.
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs in
ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the
initialization
code is included in the body of a function (that is called by
‘dynload’).
I am just trying to keep code more tidy and readable by placing it in
an initialization function, that is all.
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid
using refs?
I am a bit rusty: are there other ways to pack/unpack (fold/unfold?)
views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_data outside
of a function. Another function could be created to do the initialization
and return a ‘var’, but just curious what is generally advised.
Thanks - I actually did try that after my last mail (should’ve tried
earlier), but then I got errors along these lines when trying to assign to
the record values - maybe I’m doing it wrong:
The 1st translation (fixity) of [abstractTypeReferenced.dats] is
successfully completed!
The 2nd translation (binding) of [abstractTypeReferenced.dats] is
successfully completed!
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
(* Normally in a SATS file *)
abstype foo_abstype = ptr
typedef foo_type = foo_abstype
(* Normally in the DATS file *)
(* ****** ****** *)
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
(* ****** ****** *)
local
var foo_data: foo_type
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
end (end-of-local)On Wednesday, May 14, 2014 10:40:04 AM UTC-4, Zhiqiang Ren wrote:
If we drop the @, we should change the
typedef foo_concrete =
@{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
to
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
as well.
On Wednesday, May 14, 2014 12:45:43 AM UTC-4, gmhwxi wrote:
Allow me to go back to your original question.
abst@ype foo_abstype = ptr // @ should be dropped
typedef foo_type = foo_abstype
Normally, there should be some functions (methods) involving ‘foo_type’
that are declared after the introduction of foo_abstype. If you just want
to have
a global value of the type foo_type, then there is really no need to
introduce
foo_abstype in the first place.
On Wednesday, May 14, 2014 12:02:28 AM UTC-4, Brandon Barker wrote:
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.
On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs
in ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the
initialization
code is included in the body of a function (that is called by
‘dynload’).
I am just trying to keep code more tidy and readable by placing it in
an initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid
using refs?
I am a bit rusty: are there other ways to pack/unpack (fold/unfold?)
views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_data outside
of a function. Another function could be created to do the initialization
and return a ‘var’, but just curious what is generally advised.
I agree with you. I am just trying to understand better how
abstype/absvtype keywords work, but I’ll save that for another thread.
Brandon Barker
brandon…@gmail.comOn Wed, May 14, 2014 at 12:38 PM, gmhwxi gmh...@gmail.com wrote:
Not sure what you wanted to do. As I said before, you declared
an abstract type but not any values or functions creating/using values
of that abstract type. So what is the point of declaring the abstract type
in the first place?
Here is my guess:
typedef foo_concrete =
@{
, m = int
, n = int
}
assume foo_abstype = ref(foo_concrete)
local
var foo_data: foo_concrete
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_concrete}(view@foo_data | addr@foo_data)
in (in-of-local)
end (end-of-local)
On Wednesday, May 14, 2014 10:52:13 AM UTC-4, Brandon Barker wrote:
Thanks - I actually did try that after my last mail (should’ve tried
earlier), but then I got errors along these lines when trying to assign to
the record values - maybe I’m doing it wrong:
The 1st translation (fixity) of [abstractTypeReferenced.dats] is
successfully completed!
The 2nd translation (binding) of [abstractTypeReferenced.dats] is
successfully completed!
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
(* Normally in a SATS file *)
abstype foo_abstype = ptr
typedef foo_type = foo_abstype
(* Normally in the DATS file *)
(* ****** ****** *)
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
(* ****** ****** *)
local
var foo_data: foo_type
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
end (end-of-local)
On Wednesday, May 14, 2014 10:40:04 AM UTC-4, Zhiqiang Ren wrote:
If we drop the @, we should change the
typedef foo_concrete =
@{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
to
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
as well.
On Wednesday, May 14, 2014 12:45:43 AM UTC-4, gmhwxi wrote:
Allow me to go back to your original question.
abst@ype foo_abstype = ptr // @ should be dropped
typedef foo_type = foo_abstype
Normally, there should be some functions (methods) involving ‘foo_type’
that are declared after the introduction of foo_abstype. If you just
want to have
a global value of the type foo_type, then there is really no need to
introduce
foo_abstype in the first place.
On Wednesday, May 14, 2014 12:02:28 AM UTC-4, Brandon Barker wrote:
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.
On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style
of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs
in ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the
initialization
code is included in the body of a function (that is called by
‘dynload’).
I am just trying to keep code more tidy and readable by placing it
in an initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data
)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to
avoid using refs?
I am a bit rusty: are there other ways to pack/unpack
(fold/unfold?) views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_dataoutside of a function. Another function could be created to do the
initialization and return a ‘var’, but just curious what is generally
advised.
Not sure what you wanted to do. As I said before, you declared
an abstract type but not any values or functions creating/using values
of that abstract type. So what is the point of declaring the abstract type
in the first place?
Here is my guess:
typedef foo_concrete =
@{
, m = int
, n = int
}
assume foo_abstype = ref(foo_concrete)
local
var foo_data: foo_concrete
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_concrete}(view@foo_data | addr@foo_data)
in (in-of-local)
end (end-of-local)On Wednesday, May 14, 2014 10:52:13 AM UTC-4, Brandon Barker wrote:
Thanks - I actually did try that after my last mail (should’ve tried
earlier), but then I got errors along these lines when trying to assign to
the record values - maybe I’m doing it wrong:
The 1st translation (fixity) of [abstractTypeReferenced.dats] is
successfully completed!
The 2nd translation (binding) of [abstractTypeReferenced.dats] is
successfully completed!
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
(* Normally in a SATS file *)
abstype foo_abstype = ptr
typedef foo_type = foo_abstype
(* Normally in the DATS file *)
(* ****** ****** *)
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
(* ****** ****** *)
local
var foo_data: foo_type
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
end (end-of-local)
On Wednesday, May 14, 2014 10:40:04 AM UTC-4, Zhiqiang Ren wrote:
If we drop the @, we should change the
typedef foo_concrete =
@{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
to
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
as well.
On Wednesday, May 14, 2014 12:45:43 AM UTC-4, gmhwxi wrote:
Allow me to go back to your original question.
abst@ype foo_abstype = ptr // @ should be dropped
typedef foo_type = foo_abstype
Normally, there should be some functions (methods) involving ‘foo_type’
that are declared after the introduction of foo_abstype. If you just
want to have
a global value of the type foo_type, then there is really no need to
introduce
foo_abstype in the first place.
On Wednesday, May 14, 2014 12:02:28 AM UTC-4, Brandon Barker wrote:
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.
On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs
in ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the
initialization
code is included in the body of a function (that is called by
‘dynload’).
I am just trying to keep code more tidy and readable by placing it in
an initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid
using refs?
I am a bit rusty: are there other ways to pack/unpack
(fold/unfold?) views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_dataoutside of a function. Another function could be created to do the
initialization and return a ‘var’, but just curious what is generally
advised.
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs in ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the initialization
code is included in the body of a function (that is called by ‘dynload’).
I am just trying to keep code more tidy and readable by placing it in an
initialization function, that is all.> On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid using
refs?
I am a bit rusty: are there other ways to pack/unpack (fold/unfold?)
views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly better
for non-GC environments (though I guess it is not much difference in this
regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_data outside of a
function. Another function could be created to do the initialization and
return a ‘var’, but just curious what is generally advised.
I tried running the make, and got the following error
postiats_learn/globalvar/TextProcessing.dats: 429(line=30, offs=1) –
461(line=30, offs=33): error(1): the file [{$GLIB}/SATS/glib.sats] is not
available for staloading.
I guess it has something to do with contrib. What’s the best practice to
use contrib currently? (Maybe there’s already a thread discussing about it,
please help me find the link. Thanks)
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs in
ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the initialization
code is included in the body of a function (that is called by ‘dynload’).
I am just trying to keep code more tidy and readable by placing it in an
initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid
using refs?
I am a bit rusty: are there other ways to pack/unpack (fold/unfold?)
views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_data outside of
a function. Another function could be created to do the initialization and
return a ‘var’, but just curious what is generally advised.
No, this won’t solve the problem.On Wednesday, May 14, 2014 11:04:35 AM UTC-4, Zhiqiang Ren wrote:
Drop the “= ptr” as well.
On Wednesday, May 14, 2014 10:52:13 AM UTC-4, Brandon Barker wrote:
Thanks - I actually did try that after my last mail (should’ve tried
earlier), but then I got errors along these lines when trying to assign to
the record values - maybe I’m doing it wrong:
The 1st translation (fixity) of [abstractTypeReferenced.dats] is
successfully completed!
The 2nd translation (binding) of [abstractTypeReferenced.dats] is
successfully completed!
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
(* Normally in a SATS file *)
abstype foo_abstype = ptr
typedef foo_type = foo_abstype
(* Normally in the DATS file *)
(* ****** ****** *)
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
(* ****** ****** *)
local
var foo_data: foo_type
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
end (end-of-local)
On Wednesday, May 14, 2014 10:40:04 AM UTC-4, Zhiqiang Ren wrote:
If we drop the @, we should change the
typedef foo_concrete =
@{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
to
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
as well.
On Wednesday, May 14, 2014 12:45:43 AM UTC-4, gmhwxi wrote:
Allow me to go back to your original question.
abst@ype foo_abstype = ptr // @ should be dropped
typedef foo_type = foo_abstype
Normally, there should be some functions (methods) involving ‘foo_type’
that are declared after the introduction of foo_abstype. If you just
want to have
a global value of the type foo_type, then there is really no need to
introduce
foo_abstype in the first place.
On Wednesday, May 14, 2014 12:02:28 AM UTC-4, Brandon Barker wrote:
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.
On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style
of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs
in ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the
initialization
code is included in the body of a function (that is called by
‘dynload’).
I am just trying to keep code more tidy and readable by placing it
in an initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data
)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to
avoid using refs?
I am a bit rusty: are there other ways to pack/unpack
(fold/unfold?) views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_dataoutside of a function. Another function could be created to do the
initialization and return a ‘var’, but just curious what is generally
advised.
I think you will like it :)On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs in
ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the initialization
code is included in the body of a function (that is called by ‘dynload’).
I am just trying to keep code more tidy and readable by placing it in an
initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid
using refs?
I am a bit rusty: are there other ways to pack/unpack (fold/unfold?)
views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly better
for non-GC environments (though I guess it is not much difference in this
regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_data outside of
a function. Another function could be created to do the initialization and
return a ‘var’, but just curious what is generally advised.
Thanks - I actually did try that after my last mail (should’ve tried
earlier), but then I got errors along these lines when trying to assign to
the record values - maybe I’m doing it wrong:
The 1st translation (fixity) of [abstractTypeReferenced.dats] is
successfully completed!
The 2nd translation (binding) of [abstractTypeReferenced.dats] is
successfully completed!
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
/home/brand_000/ATStest/initalizeBeforeMakingReference/abstractTypeReferenced.dats:
419(line=32, offs=18) – 421(line=32, offs=20): error(3): the type
[S2Ecst(ptr_type)] is expected to be a tyrec (record-type).
(* Normally in a SATS file *)
abstype foo_abstype = ptr
typedef foo_type = foo_abstype
(* Normally in the DATS file *)
(* ****** ****** *)
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
(* ****** ****** *)
local
var foo_data: foo_type
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
end (end-of-local)
On Wednesday, May 14, 2014 10:40:04 AM UTC-4, Zhiqiang Ren wrote:
If we drop the @, we should change the
typedef foo_concrete =
@{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
to
typedef foo_concrete =
'{
, m = int
, n = int
}
assume foo_abstype = foo_concrete
as well.
On Wednesday, May 14, 2014 12:45:43 AM UTC-4, gmhwxi wrote:
Allow me to go back to your original question.
abst@ype foo_abstype = ptr // @ should be dropped
typedef foo_type = foo_abstype
Normally, there should be some functions (methods) involving ‘foo_type’
that are declared after the introduction of foo_abstype. If you just
want to have
a global value of the type foo_type, then there is really no need to
introduce
foo_abstype in the first place.
On Wednesday, May 14, 2014 12:02:28 AM UTC-4, Brandon Barker wrote:
It is definitely an interesting example, although based on my prior
knowledge, I should have been able to do the relevant parts without it -
somehow I am always hesitant to use pointers (or linear types in general)
in ATS after a while away from them. In C, pointers are a necessity, and
one need only use the syntax ‘*’ (which admittedly is probably the source
of countless troubles), so I tend to get used to pointers quickly in C.
On Tuesday, May 13, 2014 10:40:38 PM UTC-4, gmhwxi wrote:
On Tuesday, May 13, 2014 10:29:33 PM UTC-4, Brandon Barker wrote:
On Tuesday, May 13, 2014 10:21:03 PM UTC-4, gmhwxi wrote:
foo_data is statically allocated. So GC is a non-issue. This style of
coding is even suitable for kernel programming.
All global variables in C are essentially statically allocated refs
in ATS.
That is good to know.
A ‘var’ is stack-allocated, so it cannot be returned.
Makes sense
What is your reason for avoiding initialization outside a function?
Actually, in the C code generated from the ATS source, the
initialization
code is included in the body of a function (that is called by
‘dynload’).
I am just trying to keep code more tidy and readable by placing it in
an initialization function, that is all.
On Tuesday, May 13, 2014 10:01:32 PM UTC-4, Brandon Barker wrote:
var foo_data: foo_type
// have to initialize foo_data before making a ref
val () = foo_data.m := 0
val () = foo_data.n := 0
val foo = ref_make_viewptr{foo_type}(view@foo_data | addr@foo_data)
in (in-of-local)
// We can use foo in functions implemented here, but not foo_data.
end (end-of-local)
Other than passing the ‘var’ to a function, is it possible to avoid
using refs?
I am a bit rusty: are there other ways to pack/unpack
(fold/unfold?) views with addresses other than using references?
Using unsafe.sats with casts seems to be another option, possibly
better for non-GC environments (though I guess it is not much difference in
this regard as long as the refs are not created inside of functions with
multiple calls)?
Basically, I would like to avoid initialization of foo_dataoutside of a function. Another function could be created to do the
initialization and return a ‘var’, but just curious what is generally
advised.
export PATSHOME=${POSTIATS}
export PATSHOMERELOC=${POSTIATS_contrib}On Wednesday, May 14, 2014 11:11:06 AM UTC-4, Zhiqiang Ren wrote:
I tried running the make, and got the following error
postiats_learn/globalvar/TextProcessing.dats: 429(line=30, offs=1) –
461(line=30, offs=33): error(1): the file [{$GLIB}/SATS/glib.sats] is not
available for staloading.
I guess it has something to do with contrib. What’s the best practice to
use contrib currently? (Maybe there’s already a thread discussing about it,
please help me find the link. Thanks)
