Pascal, I have thought about this too. I tinker in another language, picolisp, that has a friendly interface to gcc.
Here is a example fibonacci: https://code.google.com/p/picolisp/source/browse/misc/fibo.l `(== 64 64) # Only in the 64-bit version (load "@lib/native.l") (gcc "fibo" NIL (cFibo (N) "Fibo" 'I N) ) int Fibo(int n) { if (n <= 2) return 1; return Fibo(n-1) + Fibo(n-2); } gcc is very light: https://code.google.com/p/picolisp/source/browse/lib/native.l With J, I've dabbled with the idea of dynamically compiling a dll (using 0 : 0) and calling it from 15!:0 with either gcc or tcc (http://bellard.org/tcc/) Just haven't gotten around to it and haven't had the need On Mon, Aug 4, 2014 at 6:05 PM, 'Pascal Jasmin' via Programming <[email protected]> wrote: > Was thinking of something similar this morning, though simpler to implement > even if tedious. I call it "client side compiling" > > the idea is to have a bunch of templates that are filled in by J code on a > socket connection (on same machine), with fairly simple client connection. > The socket process would fill in the templates with provided parameters, and > start a compile, then return binding signature when it is done compiling. > > For C, the parameters would be ; function definition ; include section ; > compiler optimizations switches > with the latter 2 optional. > the host language needs to either be able to read j arrays of at least > numbers and characters, and with high desirability, boxes of these, or J can > convert its data into something understandable by host (I think this mostly > exists for C) > > The idea is that C code could be dynamically compiled from J while only > writing simple functions, and requiring no knowledge of the ceremony of C > (other than the right include files), and no knowledge of the client side > tool chains. > > Regarding include files, that could be pre-filled by certain templates for > instance an OPENCL function template. > > Maybe J's explicit control. style can be autoconverted to C as well. SHAPE_Y > and such are part of J data that would be silently passed along to C. > Default variables of Y0 (0{:: ]), Y1, Y2... could also be silently available. > There would need to be some type annotation system, but one already exists > in J's foreign function bindings. > > The last part is 2.0 features though. Just being able to write a C function > in a 0 : 0 block with some documented J like macros would be pretty useful. > > > ----- Original Message ----- > From: Raul Miller <[email protected]> > To: Programming forum <[email protected]> > Cc: > Sent: Monday, August 4, 2014 3:39:37 PM > Subject: Re: [Jprogramming] Memoizing (Project Euler problem 14) > > It probably would be nice to have something like an ML-flavored compiler > for some subset of J. > > J already lets you link to freshly built shared objects (also known as > "DLLs") using 15!: so all the next step is probably for someone to build a > suitably small example implementation. > > There's actually a huge variety of such tools. They accumulate faster than > most people can study them. Fortunately, no one needs to use most of their > features - especially for starting projects. > > Thanks, > > -- > Raul > > On Mon, Aug 4, 2014 at 3:30 PM, Alex Giannakopoulos <[email protected] >> wrote: > >> Hm, interesting approach, that of Roger's, I still haven't digested it all, >> but sometimes it would be nice to be able to tackle these problems the same >> as everybody else in the world... >> >> >> On 4 August 2014 20:12, Alex Giannakopoulos <[email protected]> >> wrote: >> >> > I used the following memoized code, >> > >> > nextcol =: 3 : 0 >> > >> > if. 0=2|y do. -: y >> > >> > else. >: 3*y >> > >> > end. >> > >> > ) >> > >> > >> > colchain =: 3 : 0 M. >> > >> > if. y=2 do. 1,2 >> > >> > else. chain=. colchain nextcol y >> > >> > (>:0{chain),x:y>.1{chain >> > >> > end. >> > >> > ) >> > >> > but it took forever to generate the following I aborted it. >> > colchain"0 (2}.i.1000001) >> > >> > I wonder if I did something wrong. >> > It seems to work if, for instance, you give >> > colchain"0 (2+i.9999) >> > Which makes me think the memoization isn't working >> > Even my slow Scheme interpreter gives the answer in 10 seconds or so, C++ >> > in less than a second. >> > >> > >> > OTOH, old hands say that J isn't really meant for recursion. I wonder if >> > this problem should be tackled differently. >> > >> > OK, I'm off to read Roger's post that Dan pointed to... >> > >> > >> > >> > On 4 August 2014 17:30, mvillarino <[email protected]> wrote: >> > >> >> 2014-08-04 14:12 GMT+02:00 Dan Bron <[email protected]>: >> >> > If you're OK with spoilers, have you seen Roger's Collatz Conjecture >> >> essay >> >> > on the Wiki? >> >> > >> >> > http://jsoftware.com/jwiki/Essays/Collatz%20Conjecture >> >> > >> >> >> >> ? I googled for information on a J spoiler... but no, I haven't found >> it. >> >> Thanks a lot !!! >> >> ---------------------------------------------------------------------- >> >> For information about J forums see http://www.jsoftware.com/forums.htm > > > >> >> >> > >> > >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
