Stuck with -Wimplicit-function-declaration

48 views
Skip to first unread message

August Alm

unread,
Apr 17, 2017, 8:02:12 PM4/17/17
to ats-lang-users
I've begun to implement the very basics of the FAUST language in ATS. FAUST is a very elegant
functional language for audio/signal processing. The syntax is based on a certain "block diagram algebra",
where a block is like a black-box function with some number of input signals and some number of outputs,
and the algebra is given by five "composition" operations for grafting together inputs and outputs.  The block
diagram algebra can be mathematically explained as a (wheeled) PROP or as an form of arrow enrichment.
I've done a lot of mathematical research on PROPs, properads and the like, so recreating this in a programming
language is something I'm very enthusiastic about.
In FAUST the in-/outputs are audio signals and the blocks are audio processors. FAUST is written in C++
and is very performant, but it is also very limited in what type an audio signal can be given. (Essentially, only
streams of ints or floats, I believe). My idea is that it should be possible to give a very direct implementation of
the block diagram algebra in ATS, that works for signals of any [viewt0ype].

My code so far is here: https://github.com/August-Alm/ATS-Experiments/blob/master/faust.dats

Everything works just fine except the most elusive of the five operations: the [recursive_composition] which grafts
in- and outputs into a feedback loop. The compiler says:

$ patscc -DATS_MEMALLOC_LIBC -o faust faust.dats
faust_dats.c: In function ‘__patsfun_32__32__1’:
faust_dats.c:9229:1: warning: implicit declaration of function ‘__patsfun_32__32’ [-Wimplicit-function-declaration]
 ATSINSmove(tmp81__1, __patsfun_32__32(env0, env1, env2, arg0)) ;
 ^
In file included from faust_dats.c:15:0:
/usr/lib/ATS2/ccomp/runtime/pats_ccomp_instrset.h:270:35: warning: assignment makes pointer from integer without a cast
 #define ATSINSmove(tmp, val) (tmp = val)
                                   ^
faust_dats.c:9229:1: note: in expansion of macro ‘ATSINSmove’
 ATSINSmove(tmp81__1, __patsfun_32__32(env0, env1, env2, arg0)) ;
 ^
/tmp/ccF3c5gZ.o: In function `__patsfun_32__32__1':
faust_dats.c:(.text+0x21e1): undefined reference to `__patsfun_32__32'
collect2: error: ld returned 1 exit status

I've tried everything that I can think of. In the github code I use [int]-signals but I've tried boxed types as well, and
various other things. I've meticulously annotated all templates, and so on. Always the same compiler error. Any suggestions?

Best wishes,
August

Hongwei Xi

unread,
Apr 17, 2017, 8:31:54 PM4/17/17
to ats-lan...@googlegroups.com
You are definitely using a feature in ATS that has not been tested :)

Here is a problem I see:

You have

val f = fix f(...) =<lincloptr1> ...

As 'f' is a lincloptr, it cannot really be defined recursively (because 'f' is supposed to be
called only once). To put it in another way, f1 and f2 are to be called and freed once the
first call to f happens; any subsequent call to 'f' are unable to use either 'f1' or 'f2'.

I really need to insert some form of checking to stop a lincloptr function from being recursively
defined (via the use of 'fix').


--
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.
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/87d806f5-1ed8-4173-82d6-0b3ef7075084%40googlegroups.com.

August Alm

unread,
Apr 17, 2017, 9:03:51 PM4/17/17
to ats-lang-users
Thanks for the heads up!

I think too much like a mathematician sometimes; to me it is not an immediate instinct that solving fix-points
require recursive function applications.

I changed the code to

         fun{a: vt0ype}
         recursive_composition
         {m1, n1, m2, n2: int| n1 >= m2; m1 > n2; m2 > 0}
         (pr1: processor(a, m1, n1), pr2: processor(a, m2, n2)):
         processor(a, m1-n2, n1) =
           let
             val ~PROC(p1) = pr1
             val ~PROC(p2) = pr2
             val m2 = p2.ins
             val n2 = p2.outs
             val f1 = p1.hom
             val f2 = p2.hom
             val f1 = $UN.castvwtp0{ptr}(f1)
             val f2 = $UN.castvwtp0{ptr}(f2)
             val f = fix
               f(us: signals(a, m1-n2)): signals(a, n1) =<cloptr1> let
                   val f1 = $UN.castvwtp0{hom(signals(a, m1), signals(a, n1))}(f1)
                   val f2 = $UN.castvwtp0{hom(signals(a, m2), signals(a, n2))}(f2)
                   val us' = dataget(us)
                   val us' = $UN.castvwtp0{signals(a, m1-n2)}(us')
                 in
                   f1[signals_append<a>{n2, m1-n2}
                      ( f2[signals_mem<a>{m2}(signals_take<a>{n1}(f(us), m2))]
                      , us' )]
                 end
             val phi = defn(llam(us) =<cloptr1> evcloptr(f, us))
           in
             PROC @{ hom = phi
                          , ins = p1.ins - p2.outs
                          , outs = p1.outs }
           end
 
and it typechecks but gives me the same compiler error, verbatim. Did I misunderstand your hint?
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.

Hongwei Xi

unread,
Apr 17, 2017, 9:24:31 PM4/17/17
to ats-lan...@googlegroups.com
There seems to be a bug here. I managed to compile your code. But in
the definition of f(us), you have a recursive call f(us), which caused a segfault.

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

unread,
Apr 18, 2017, 12:31:29 AM4/18/17
to ats-lan...@googlegroups.com
I made some changes to fix the issue with compiling your code
(fix-function inside a template).

However, there seems to be infinite computation in your code as of now.


Reply all
Reply to author
Forward
0 new messages