Runtime polymorphism for unboxed types?

[Shea Levy]

Hi all,

I know ATS2 supports function templates, and polymorphic functions for boxed types. Is there any support for runtime polymorphism (with vtables or standalone structs of functions or similar) available in the language?

Related question: Is there support for *value* templates?

~Shea

[Artyom Shalkhakov]

On Friday, February 20, 2015 at 8:58:01 PM UTC+6, Shea Levy wrote:

Hi all,

I know ATS2 supports function templates, and polymorphic functions for boxed types. Is there any support for runtime polymorphism (with vtables or standalone structs of functions or similar) available in the language?

HX once implemented Smalltalk-style objects in an ATS prototype, but I think he abandoned the plan to implement it a long time ago.
 

Related question: Is there support for *value* templates?

Are you asking about something like:

fun{i:pos}
vec_add(x: &(@[float][i]), y: &(@[float][i]), o: &(@[float][i])): void =
  // do an element-wise addition, putting results into [o]
  // i is known at compile time, so we can get it at runtime
  // using something like constant<int,i>, similarly to sizeof

I'd like to know the answer as well.
 

~Shea

[gmhwxi]

I added an example of loop unrolling here:

https://github.com/githwxi/ATS-Postiats/blob/master/doc/EXAMPLE/ATS-QA-LIST/qa-list-2015-02-20.dats

I do have a plan to implement the following feature

fun vec_add{i:int}(...) =
sif i == 0
  then ...
  else ...

vec_add{10}(...) can then be expanded at compile-time.

[Artyom Shalkhakov]

On Saturday, February 21, 2015 at 2:42:15 AM UTC+6, gmhwxi wrote:

I added an example of loop unrolling here:

https://github.com/githwxi/ATS-Postiats/blob/master/doc/EXAMPLE/ATS-QA-LIST/qa-list-2015-02-20.dats

This is ingenious. :-)
 

I do have a plan to implement the following feature

fun vec_add{i:int}(...) =
sif i == 0
  then ...
  else ...

vec_add{10}(...) can then be expanded at compile-time.

That would be awesome. It would drastically simplify e.g. the implementation of generic vectors in little math libraries for use in graphics.
 

[Shea Levy]

Cool! If we had that feature, would we be able to parameterize function templates by any sort, and have full use of scase/sif in the implementations? That would be very useful, I’m currently adapting your example to implement type lists (to use where in C++ I’d use variadic templates), but having a proper type list datasort would be much nicer than passing around proofs that a given list is proper :)

~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/4e92a56c-bb36-4901-aa58-205fcc67f373%40googlegroups.com.

[gmhwxi]

I tried to implement what is mentioned below. Unfortunately, my plan did not pan out
well. The simple reason is that the condition following each 'sif' is static but the static
information is essentially all erased at the stage where 'sif' needs to be eliminated.
I could try to eliminate 'sif' at the point where such information is still available but this
means templates making use of 'sif' cannot be handled (as template instantiation happens
at a later stage).

For now, I think we simply need to implement a version of array_foreach that supports
loop unrolling. For instance, see:

https://github.com/githwxi/ATS-Postiats/blob/master/doc/EXAMPLE/TYPEVAL/dotprod.dats

[Artyom Shalkhakov]

On Friday, March 6, 2015 at 6:27:26 AM UTC+6, gmhwxi wrote:

I tried to implement what is mentioned below. Unfortunately, my plan did not pan out
well. The simple reason is that the condition following each 'sif' is static but the static
information is essentially all erased at the stage where 'sif' needs to be eliminated.
I could try to eliminate 'sif' at the point where such information is still available but this
means templates making use of 'sif' cannot be handled (as template instantiation happens
at a later stage).

For now, I think we simply need to implement a version of array_foreach that supports
loop unrolling. For instance, see:

https://github.com/githwxi/ATS-Postiats/blob/master/doc/EXAMPLE/TYPEVAL/dotprod.dats

Could you post the resulting C code for dotprod.dats? I'd really like to take a look, even if it's very long.

[Hongwei Xi]

See the attached file.

If you do:

patscc -O2 -S dotprod_dats.c

you can see that gcc can actually does a very thorough job:

dotprod3(...) is already evaluated to 14 at compile-time.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/7c7a0e69-5bb1-4090-bdd3-57f97adb2070%40googlegroups.com.

[H Zhang]

I find the example intriguing and I am trying to understand how the unrolling is actually carried out. Is this paper http://www.cs.bu.edu/~hwxi/academic/papers/icfp05.pdf still a good reference on how this part of ATS works? The erasure function defined in fig 6 seems to simply remove the proof terms. Could you talk about how the program transformation is achieved or give a reference paper?

Thanks,
Haitao

[gmhwxi]

The template system of ATS2 is largely undocumented.

Unlike dependent types and linear types in ATS, I have done very little
theoretical study on templates in ATS. I just don't feel that I have time and energy for it :(

This example is actually quite straightforward.

Say you want to evaluate tally<S(S(Z))>(... | 2)

The compiler essentially generates three functions:

tally_0 for tally<Z>
tally_1 for tally<S(Z)>
tally_2 for tally<S(S(Z))>

It goes like this:

First, the compiler introduces tally_2 for tally<S(S(Z))> using  the template tally<S(t)>;
when generating the body of tally_2, the compiler introduces tally_1 for tally<S(Z)> (as t
is mapped to S(Z) this time); when generating the body of tally_1; the compiler introduces
tally_0 (as t is mapped to Z this time).