Definitely. Numbers are defined recursively (or, inductively), so anything involving arithmetic represents recursive processes.
But that does not mean that machine recursion is the best implementation - if you can map an unfamiliar recursive system onto a recursive system with an efficient representation, you typically see many orders of magnitude speed improvement over a naive implementation. On the other hand, of course, a naive implementation may be the way to go - either because it's instructive or because it's expedient. But that's also not always the case. And, sometimes it's worth re-examining the implementation, to perhaps resolve conflicts between assumptions at different layers. Anyways... it pays to understand what's going on. Thanks, -- Raul On Wed, Jan 8, 2020 at 1:56 PM Vanessa McHale <vamch...@gmail.com> wrote: > > As I understand it, the problem there is that most interesting things are > recursive functions, and one must decide what can be evaluated at compile > time. The idea went somewhere but never made it into the mainstream: > https://ndmitchell.com/downloads/paper-a_supercompiler_for_core_haskell-01_may_2008.pdf > > <https://ndmitchell.com/downloads/paper-a_supercompiler_for_core_haskell-01_may_2008.pdf> > > Cheers, > Vanessa > > > On Jan 8, 2020, at 12:41 PM, Raul Miller <rauldmil...@gmail.com> wrote: > > > > Haskell's lazy evaluation also offers significant opportunities for > > partial compile time (aka "eager") evaluation of expressions, which > > tends to result in blazing fast run-time (since the calculations were > > already completed, or to some degree). > > > > The downside has to do with debugging in some of the remaining cases. > > But people experienced with a language tend to learn to avoid many of > > its pain points. > > > > Thanks, > > > > -- > > Raul > > > > On Wed, Jan 8, 2020 at 1:32 PM Vanessa McHale <vamch...@gmail.com > > <mailto:vamch...@gmail.com>> wrote: > >> > >> Haskell’s lazy evaluation is also more complex than it might seem at first > >> glance: it’s not quite the same as non-strictness, and in particular in a > >> proper lazy language various data structures are more efficient due to > >> caching &c. > >> > >> Cheers, > >> Vanessa > >> > >>> On Jan 8, 2020, at 12:28 PM, Raul Miller <rauldmil...@gmail.com > >>> <mailto:rauldmil...@gmail.com>> wrote: > >>> > >>> On Tue, Jan 7, 2020 at 8:24 PM Raoul Schorer <raoul.scho...@gmail.com > >>> <mailto:raoul.scho...@gmail.com> <mailto:raoul.scho...@gmail.com > >>> <mailto:raoul.scho...@gmail.com>>> wrote: > >>>> 'Is it possible to define infinite data structures and operate on them in > >>>> J?' > >>> > >>> There are an infinity of infinities and any useful approach at > >>> representing infinities can only handle a finite subset. > >>> > >>>> For example, take the first ten elements of an infinite list, as in > >>>> Haskell. > >>>> The 'F.' primitive family seems promising indeed. > >>> > >>> You can think of J's i. (when used without a left argument) as > >>> representing an infinite list and its right argument as specifying how > >>> much of that infinite list you want. And, you can use functions > >>> incorporating i. to extend the possibilities. > >>> > >>> That said, Haskell is (in this context) more LISP like: with a bias > >>> towards micro-recursions and a bias away from numeric representations > >>> of size. J can indeed emulate that, but performance tends to suffer if > >>> or when you don't understand how to map the micro-recursions onto > >>> arithmetic. (Or, more simply: Haskell is a better Haskell than J is.) > >>> > >>> Does this help? > >>> > >>> Thanks, > >>> > >>> -- > >>> Raul > >>> > >>> > >>>> > >>>> Le mer. 8 janv. 2020 à 01:56, Henry Rich <henryhr...@gmail.com> a écrit : > >>>> > >>>>> I don't understand the task at all. You might look in NuVoc for $:, F. > >>>>> etc., and M. > >>>>> > >>>>> Henry Rich > >>>>> > >>>>> On 1/7/2020 7:51 PM, Raoul Schorer wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Implementing Minikanren <http://minikanren.org/> in J by translating > >>>>> from > >>>>>> Scheme, I stumbled on the following: > >>>>>> I have a Scheme procedure 'fives' > >>>>>> < > >>>>> https://github.com/jasonhemann/microKanren/blob/master/microKanren-test-programs.scm > >>>>>> > >>>>>> that is passed a vector and yields a procedure that then takes a pair. > >>>>>> ((fives (vector 0)) '(() . 0)) > >>>>>> > >>>>>> My problem is that this then evaluates to a pair data -- procedure: > >>>>>> ((((#(0) . 5)) . 0) . #<procedure at > >>>>>> microKanren-test-programs.scm:677>) > >>>>>> > >>>>>> The second member of the pair (the procedure) is then evaluated on > >>>>>> demand > >>>>>> to yield another similar structure of length n+1, therefore allowing > >>>>>> the > >>>>>> lazy evaluation of this infinite "stream". > >>>>>> > >>>>>> Is switching to iterative/eager eval the only realistic way? > >>>>>> Can someone help me with lazy eval of infinite structures in J, or give > >>>>> me > >>>>>> pointers to resources on the topic? > >>>>>> > >>>>>> Thanks! > >>>>>> Raoul Schorer > >>>>>> ---------------------------------------------------------------------- > >>>>>> 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 > >>> <http://www.jsoftware.com/forums.htm> > >>> <http://www.jsoftware.com/forums.htm > >>> <http://www.jsoftware.com/forums.htm>> > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> <http://www.jsoftware.com/forums.htm> > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > <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
