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.


On Mon, Apr 17, 2017 at 9:24 PM, Hongwei Xi <gmh...@gmail.com> wrote:

> 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.
>
> On Mon, Apr 17, 2017 at 9:03 PM, August Alm <august...@gmail.com> wrote:
>
>> 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?
>>
>>
>> Den tisdag 18 april 2017 kl. 02:31:54 UTC+2 skrev gmhwxi:
>>>
>>> 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').
>>>
>>>
>>> On Mon, Apr 17, 2017 at 8:02 PM, August Alm <augu...@gmail.com> wrote:
>>>
>>>> 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
>>>>
>>>> --
>>>> 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/ms
>>>> gid/ats-lang-users/87d806f5-1ed8-4173-82d6-0b3ef7075084%40go
>>>> oglegroups.com
>>>> <https://groups.google.com/d/msgid/ats-lang-users/87d806f5-1ed8-4173-82d6-0b3ef7075084%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-users+unsubscr...@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/ms
>> gid/ats-lang-users/c4f49335-34a4-424a-b90f-05a83ad82a13%40go
>> oglegroups.com
>> <https://groups.google.com/d/msgid/ats-lang-users/c4f49335-34a4-424a-b90f-05a83ad82a13%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-users+unsubscr...@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/CAPPSPLpcG%2BMNyHp%3DnFc0k-SE2Z3Wf3mZmgm%3DWtgnO11eQCLZtg%40mail.gmail.com.

Reply via email to