Hi, In the past I have looked at how Python's NumPy and Ruby's NArray are implemented. I then implemented Ruby multiarray (one of the HornetsEye libraries). The point is that ultimately you want a flexible library for umiform arrays with a JIT compiler to match the exressiveness of Guile/Scheme. I am working on something like that at the moment [1]. Any comments and suggestions are welcome.
Jan [1] https://github.com/wedesoft/aiscm On August 13, 2014 6:43:09 AM GMT+01:00, Nala Ginrut <nalagin...@gmail.com> wrote: >On Sat, 2014-08-09 at 14:58 +0200, Federico Beffa wrote: >> > On Fri, 2014-05-30 at 23:33 +0200, Stefan Israelsson Tampe wrote: >> >> I would like to hijack the python2/3 community over to guile. >> >> Hi, I'm a user of python which would very much prefer to use Scheme >:-) >> >> I just wanted to say that the reason for which a lot of >> engineers/scientists are using python, is because it now provides a >> pretty large set of scientific/engineering and plotting functions >with >> the 3 main libraries numpy, scipy and matplotlib. It would be >> fantastic if somehow this functionality could be made available in >> guile :-) >> > >I agree with you, the popular of Python is largely because of some >popular libs. > > >I'm one of the guys who is interested in hacking multi-lang front-end >on >Guile. And I think there're at least two approaches to cut this Gordian >Knot. > >1. Make great effort to be compatible with the original Python, even >the >C interfaces(maybe a wrapper or refactor the C part with Guile CAPIs). >And recompile the whole numpy/scipy/matplotlib with guile-python. This >would be the fantastic and idealism way. But challenging. >One of the reasons is whether our brand new CPS-based backend (in >master >branch) is suitable for Python language would be suspended. In >principle, it's suitable for FP languages especially continuation-based >one. But it's worth to try anyway. >The difficulty contains both workload and indeterminacy. > >2. Write Guile own libs for the same purpose of numpy/scipy/matplotlib, >and users may call the related modules from Python code. I have to >emphasize that any language implemented on Guile could call the modules >written with other languages, if it's on Guile too. >This is also challenging. But IMO, the difficulty of this way contains >workload only. > > >These are my ideas. And I'd like to try the first way because of my >hacking habit. >But the most significant thing is to make the latest Guile-2.2(in >master >branch) better than before. I'm trying to rewrite guile-lua on >Guile-2.2, but it's in a slow progress since there're lot of new stuffs >need to learn. > >Any ideas? > > >Best regards. -- Jan Wedekind http://www.wedesoft.de/