Linking with abstract types

[M88]

Hello,

This doesn't seem to affect compilation, but I often get this warning when attempting to link .dats files into mylibies_link.hats:

"warning(3): the static constant [....] is not abstract at this point"

This happens when I want to link a .dats file that implements abstract types. 

// mylibies.hats

staload "./SATS/foo.sats" //    expose the interface  (declares abstract types)

staload _ = "./DATS/foo.dats" // expose the templates  (implements abstract types)

// mylibies_link.hats

local

#include "./DATS/foo.dats"  // link the file (for non-template functions, etc)

in end

It seems that all three declarations are necessary for compilation to succeed. There is no compilation error.

Is this warning safe to ignore, and/or is there a preferred way of linking in this case? 

[Hongwei Xi]

I myself have seen this warning quite a few times.

The reason is that some abstract type, say XYZ, is implemented in foo.dats.

After foo.dats gets staloaded, it is also included, which causes the compiler to

complaint that XYZ gets implemented repeatedly. This is a harmless warning

(because you are not compiling foo.dats).

If you want to suppress it, you can try to use absreimpl (or reassume).

--
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 https://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/9da1f4c4-136e-4885-8e24-6dcb3e5d9aa1%40googlegroups.com.

[Julian Fondren]

On Tuesday, October 16, 2018 at 11:53:53 PM UTC-5, M88 wrote:

// mylibies_link.hats

local

#include "./DATS/foo.dats"  // link the file (for non-template functions, etc)

in end

Why are you doing that? If a file is using foo.dats' non-template functions, all it should have to do is staload the foo.sats that has their types, and then its object should be linked with one with their definitions (i.e., foo_dats.o).

[gmhwxi]

Here is an example of using 'absreimpl':

#include
"share\
atspre_staload.hats"

#staload "./abcde.sats"

(*

// This is the content of abcde.sats:

abstype X = ptr
local assume X = $tup(int, int) in end

*)


local

absreimpl X

in

fun f(): X = $tup(0, 1)
fun f0(x: X): int = x.0
fun f1(x: X): int = x.1

end

implement main0() = let val x = f() in print!(f0(x) + f1(x)) end

On Wednesday, October 17, 2018 at 1:11:00 AM UTC-4, gmhwxi wrote:

I myself have seen this warning quite a few times.

The reason is that some abstract type, say XYZ, is implemented in foo.dats.

After foo.dats gets staloaded, it is also included, which causes the compiler to

complaint that XYZ gets implemented repeatedly. This is a harmless warning

(because you are not compiling foo.dats).

If you want to suppress it, you can try to use absreimpl (or reassume).

On Wed, Oct 17, 2018 at 12:53 AM M88 <...> wrote:

Hello,

This doesn't seem to affect compilation, but I often get this warning when attempting to link .dats files into mylibies_link.hats:

"warning(3): the static constant [....] is not abstract at this point"

This happens when I want to link a .dats file that implements abstract types. 

// mylibies.hats

staload "./SATS/foo.sats" //    expose the interface  (declares abstract types)

staload _ = "./DATS/foo.dats" // expose the templates  (implements abstract types)

// mylibies_link.hats

local

#include "./DATS/foo.dats"  // link the file (for non-template functions, etc)

in end

It seems that all three declarations are necessary for compilation to succeed. There is no compilation error.

Is this warning safe to ignore, and/or is there a preferred way of linking in this case? 

--
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-users+unsubscribe@googlegroups.com.
To post to this group, send email to ats-lang-users@googlegroups.com.

[Hongwei Xi]

Sometimes, you may want to have one single file that

contains all the C code generated from some ATS code contained in

multiple files. This often allows a C compiler to produce better optimized

code.

--

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 https://groups.google.com/group/ats-lang-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/eca6f467-d5a5-4de5-b8cd-2523abc97ed0%40googlegroups.com.

[Hongwei Xi]

Another way to do this is to use the -dd flag associated with the patsopt command.

[M88]

Thanks for the responses.

Along with the gcc optimizations, code generated in a single file (with `patsopt -dd` or `mylibies_link.hats`) tends to play more nicely with codegens, which may or may not have a notion of a "static" function like in C (making namespace collisions possible with separate compilation).  I suppose if one is using codegens, it's also more convenient to have the library in a single file (eg, for JS).

I will experiment with reabsimpl -- I would like to keep a single .hats file for downstream users when it's time for packaging.

[Hongwei Xi]

Here is one way of using codegens that I perceive:

Use codegens to generate code and the generated code is

stored in a file, say, of the name xyz.hats. Then one can do

local

#include xyz.hats

in

  [Some code that needs the content of xyz.hats]

end

The generated code often contains a lot of templates and usually cannot

be typechecked separately; it needs to be put into a context to pass typechecking.

--
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 https://groups.google.com/group/ats-lang-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/deeccf71-2719-42eb-9c89-03a2b4e326a3%40googlegroups.com.

[M88]

Ah -- I was referring to atscc2js / atscc2php / atscc2py3, etc, not the built-in codegen2 feature (sorry if I was ambiguous).  If one compiles to separate files in say, PHP, then some of the functions that are normally static or inlined in C (eg, __patsfun_*) may have duplicate names, causing the script to crash.   In JS, it may produce some strange bugs, because named functions overwrite one another. 

Eg:

// JS behavior

function foo() { console.log("foo 1") }

function bar() { foo() }

function foo () {  console.log("foo 2") }

bar();

// outputs "foo 2" !!!!

 To avoid errors like these, it's good to use `patsopt -dd` to compile to a single file (which creates a unique name for each function) before sending the C to the code generator. 

I realize that codegen refers to the datcon / datcontag / fprint generation utility.  Again, sorry for the ambiguity.