Note also that Haskell has a lot of things to keep you from trying to access anything more than a brief prefix of those infinite lists. (And this includes a rather extensive system of errors and an involved "pattern matching parser".)
You would basically have to give up on J's syntax (and some of J's convenience and features) to do a reasonable job of bringing in the Haskell way of doing things - and if you're going to go that far, why not just use Haskell? (Or you could go the other way, and build up J style arrays and primitives in Haskell - but to do an adequate job of that, you'd wind up having to disable and/or bypass a lot of Haskell's restraints... and if you're going to go that far, why not just use J?) Thanks, -- Raul On Mon, Feb 26, 2018 at 4:51 PM, Jose Mario Quintana <[email protected]> wrote: >> Another fascinating possibility becomes available: 'i._'... > > Two more cents... > > This was also contemplated more than a decade ago by none other than one of > the designers of J [0]. You are in good company. :) > > Is it all academic? (My understanding is that Haskell supports infinite > lists.) > > [0] [Jgeneral] infinity > http://www.jsoftware.com/pipermail/general/2005-December/026024.html > > > On Mon, Feb 26, 2018 at 12:48 PM, james faure <[email protected]> > wrote: > >> I have 2 major propositions: >> >> Recently, I (to my chagrin) demonstarted to a friend that '>: i.1e7' takes >> almost twice as long as 'i.1e7'. Of course I expected them both to execute >> instantly, not after a full second. So my suggestion: i. should return a >> 'range' (or 'i.') object containing three vars: 'start end step'. In this >> way, '+ - * %' and indeed any linear combination of linear operations can >> be executed on only 3 variables rather than #y . besides the immediate >> speed and memory improvements here, other operations (on i. objects), like >> '+/ */ e. i.' etc.. can now be found by direct calculation, without ever >> spawning a physical array! Another fascinating possibility becomes >> available: 'i._'. Thus something like '*/ x * y ^ - i. _' is now able to >> return the result of the infinite geometric series. In fact in general it >> may be very profitable to use virtual arrays only, unless forced otherwise. >> Another concrete example: when searching for the first number to satisfy a >> certain property, one could use 'i.@u seq i. _' rather than some likely >> inefficent variation of ^: or while. . Perhaps this 'array only when >> forced' approach may even void the need for special combinations, a concept >> which feels suspicious to me. >> >> Secondly: operations on extended precision numbers are unbelievably >> slow... The most direct example: '! 100000x' takes 50 (!) times longer than >> python3's math.factorial(100000). It should be well worth looking into >> llvm's APInt and APfloats http://llvm.org/doxygen/classllvm_1_1APInt.html, >> or perhaps Cpython's bigint's https://github.com/python/cpython/blob/ >> 65d4639677d60ec503bb2ccd2a196e5347065f27/Objects/longobject.c, I wouldn't >> think it's necessary to write another custom library. >> >> James Faure >> ---------------------------------------------------------------------- >> 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
