Problem With Template Instantiation (ATSPMVenv())

[William Blair]

I'm having some trouble compiling code that makes heavy use of templates. I am using a library that parses JSON into an array of tokens. Each token refers to a value which can be retrieved from the original JSON string. I have a template function that returns this string. Before any information is taken from the tokens, the user must implement this function with the correct string. This avoids having to set up a global variable or add parameters to functions. When I try to compile the corresponding C code, I find many instances of the following error, but only for some template functions.

    parsing_dats.c:86143:186: error: use of undeclared identifier 'data'

    ATSINSmove(tmpret762__4, parse_s2rt__131__4(ATSPMVenv(data), arg0)) ;

The highest level code looks like the following

    let val (data, jsv) = jsonval_parse_from_stdin ()

  

    implement

    jsonval_src<> () = data

  

    val c3nstrs = jsv["c3nstrbody"]

    in

        parse_c3nstr (c3nstrs)

    end

I made a simpler version that uses the same technique, but the C code produced by patsopt compiles without any errors. You can find this small example on github.

    https://gist.github.com/wdblair/2b5e0bd054b91abfe71d

Is it possible I am using too many layers of templates in my code? You can see the whole picture in the following repo:

    https://github.com/wdblair/ATS-Postiats-contrib/tree/jsmn/projects/MEDIUM/ATS-extsolve/parsing

Thanks,

Will

[gmhwxi]

I think I know the cause of this problem, but fixing it requires some thoughts.

Basically, you used some templates that are defined mutually recursively:

implement{} f () = g<> ()
implement{} g () = f<> ()

Let me first investigate the issue a bit further.

[gmhwxi]

I have managed to produce this kind of bug using the following simple code:

https://github.com/githwxi/ATS-Postiats/blob/master/doc/BUGS/bug-2015-01-07.dats

[gmhwxi]

This is a VERY tricky issue because this kind of use was *not*
part of the design. On the other hand, it seems natural to use templates
this way. So ...

[William Blair]

Are mutually recursive templates only an issue when instantiating one of the templates requires bringing in variables from the environment? If so, I could just replace the jsonval_src template with a global variable for now.

What would you have to do to support using templates in this way?   

[Hongwei Xi]

>>Are mutually recursive templates only an issue when instantiating one of the templates requires bringing in variables from the environment? If so, I could just replace the jsonval_src template with a global variable for now.

That should work.

I think that a better way for now is to break the mutual dependency:

implement

{}(*tmp*)

parse_s2rt (...) = let

fun aux_S2RTfun (...) = (code for parse_S2RTfun)..

in
   ...
end

implement

{}(*tmp*)

parse_S2RTfun (...) = ... // if you still need it.

--
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/562bff4d-d74e-4d6f-9f07-a0adb027e0df%40googlegroups.com.

[gmhwxi]

>>What would you have to do to support using templates in this way?

Not really sure yet.

This kind of thing is inevitable as it is impossible to plan/design everything
ahead.

[William Blair]

Ah I see, that should be easy to implement. Thanks!

[gmhwxi]

I came up with a fix for this issue.

Basically, the idea is to allow the programmer to indicate to the compiler that a particular
dynamic variable should be included in the environment of a template instance. For instance,

implement
main0 (argc, argv) = let
//
val () = $closurenv(argc) // [argc] is put into the environment of the following instance of [foo]
//
in
  ... foo<> (...) ...
end // end of [main0]

For a running example, please see:

https://github.com/githwxi/ATS-Postiats/blob/master/doc/BUGS/bug-2015-01-07.dats

You need ATS2-github to test this example.

[gmhwxi]

I changed the keyword $closurenv to $tempenver as this is only
related to compiling template instances.

[William Blair]

>> I changed the keyword $closurenv to $tempenver as this is only
>> related to compiling template instances.

Thanks! That fixed the environment variable issue. 

Another problem I ran into was using templates to parse lists of lists. I've made a small example to demonstrate the issue I'm running into.

    https://gist.github.com/wdblair/33010d8544d79c263ccf

If you try to compile the above gist using 

    patscc -c -o printlists_dats.o printlists.dats

The C compiler complains about the following line:

/*

emit_instr: loc0 = /Users/wdblair/tmp/printlists.dats: 437(line=33, offs=13) -- 454(line=33, offs=30)

*/

ATSINSmove_void(tmp3__2, PMVtmpltcstmat[0](print_t0ype<S2Eexi(n$8536$8538(13787); S2Eapp(S2Ecst(>=); S2Evar(n$8536$8538(13787)), S2Eintinf(0)); S2Eapp(S2Ecst(list); S2Ecst(itm), S2Evar(n$8536$8538(13787))))>)(tmp1__2)) ;

It seems that it isn't finding the implementation of print_t0ype<itmlst> given inside print_itmlstlst. Does it look like I am using templates incorrectly here?

Thanks,

Will

[gmhwxi]

For now, a template argument needs to be a non-dependent type.
List0 is dependent. The problem can be fixed by changing List0 to list0:

fun{}
print_itmlstlst
  (iss: itmlstlst): void = let
  typedef itmlst0 = list0(itm)
  implement
  print_t0ype<itmlst0>
    (is) = print_itmlst (g1ofg0(is))
in
  print_list<itmlst0> ($UNSAFE.cast{List0(itmlst0)}(iss))
end

You need the following line for list0:

staload "prelude/libats/ML/SATS/list0.sats"

[gmhwxi]

The following two lines are needed:

staload "libats/ML/SATS/basis.sats"
staload "libats/ML/SATS/list0.sats"

Or just do:

#include "share/HATS/atspre_staload_libats_ML.hats"

[William Blair]

>>Or just do:
>>
>>#include "share/HATS/atspre_staload_libats_ML.hats"

Thanks! That worked well. I've run into this issue before, and it's good to know what the cause of it is.

[gmhwxi]

>> I've run into this issue before, ...

Maybe you should have reported it earlier :)

I plan to add Part V to my book on Intro to ATS. It will be about
template-based programming.

[Artyom Shalkhakov]

Hello Hongwei,

On Thursday, January 15, 2015 at 11:30:14 PM UTC+6, gmhwxi wrote:

For now, a template argument needs to be a non-dependent type.

What do you mean here by 'non-dependent'?

List0 is dependent because it is indexed? What about parameterized types? Can a parameterized type be a template argument?

[Hongwei Xi]

I should have said non-quantified types (instead of non-dependent types).

List0(a) is quantified:

List0(a) = [n:int] list(a, n)

--
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/086278ab-75b2-498d-b8b4-09ccb274ef5d%40googlegroups.com.