(* Normally in a SATS file *)
abst@ype 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
// 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*)
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').
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/7340a848-ec98-4d8a-9673-13ac241bcd2e%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.
(* ****** ****** *)
//
#include
"share/atspre_define.hats"
#include
"share/atspre_staload.hats"
//
(* ****** ****** *)
(* 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*)
Does this one help? https://groups.google.com/d/msgid/ats-lang-users/dcde4b29-ca89-4d3f-abb0-768a0311587d%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.
To post to this group, send email to ats-lan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/4ba1e8ab-8e55-4990-8fd9-c3d516fb49e6%40googlegroups.com.
I read in another thread that this could cause c compilation issues:
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*)
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/84f7ed4f-8558-42ae-b0f7-641944bb6749%40googlegroups.com.
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.