Well this is not a response to outline my concerns with the proposal (which I have to say is ambitious). Instead, I'd like to add my support to the project to convert all of Sage to LISP.
In particular, I'd be happy to work on forking MPIR and FLINT and rewriting them in LISP (given appropriate funding of course). This will probably come as a surprise, but over the last 6 months I've been playing with various languages (even tried writing my own) to replace C in my projects. I'm sick of typing: for (ulong i = 0; i < poly->length; i++) (and having it segfault due to overrun, for my trouble. I figured there must be a better language for writing mathematics out there. I knew Python was easy, and so I worked through some python tutorials. But it's just too hard for me to get used to. I'm dumb I guess. Reluctantly I have been coming to the same conclusions as you. The canonical language for this sort of thing is obviously LISP. I mean that is what it was created for. Sure, we've got a lot of work to do to make this work. But we can do it if we are persistent (and we are :-)). I did already write a couple of FLINT files in LISP. They are much shorter than the original C files, and performance doesn't differ much from the C versions. Given that we are going to fork CLISP, I am sure there is plenty of opportunity to speed this all up, and even *exceed* the speed of a C implementation in many cases. I should point out that by "files" I'm not talking about the whole of fmpz_poly or something like that. Just a handful of functions at this point. I think the 4 year goal is ambitious, but doable. And in 30 years we should have something quite usable. Anyhow, short story is, I'm in - though probably for different reasons to you guys. Bill. On 1 Apr, 18:59, William Stein <wst...@gmail.com> wrote: > Hi, > > About two years ago we made the painful transition from using Darcs to > Mercurial for our revision control system. This was difficult, but had > to be done because it was hard to get Darcs to run everywhere, and > there were weird corner cases where Darcs would hang. Mercurial isn't > optimal but it gets the job done. > > Frankly, I think we have similar problems using Python at the core of > Sage. I've been thinking very hard about how to deal with this for > nearly a year now, and have come to the conclusion that we should make > a switch from using Python at the core of Sage to Lisp. The > transition won't be easy, but it will be well worth the effort, since > in the time frame I have in mind (30 years, say) I see Lisp really > taking off, and despite its faults, anyone who has used Lisp a lot > knows that Lisp is clearly a far better language than Python in > several critical ways. The strategy for switching will go something > like this: > > 1. Forking: We fork clisp. We have been using clisp for several > years now in Sage, so we're very familiar with their build system. > However, they don't make regular releases, and their foreign function > interface is severely lacking, as is their Solaris support. So we're > forking, and will call the fork LispX. I've talked with Robert > Bradshaw about creating a new language called CylispX, which will be > similar to Cython but for LispX, and I'm confident we can pull this > off. > > 2. Porting: We have an intense sequence if "Lisp days", both > workshops and 1-day long IRC events, where we go line-by-line through > the Sage library and rewrite everything in Lisp. As we go, we'll > make sure that the rewritten code is always at least as fast as the > original code (this shouldn't be a problem, because of LispX's > extremely good profiling and dynamic optimization features). I hope > everyone here is willing to pitch in significant time to this effort. > If you're not, I would really like to know what your concerns are. > > 3. Polish: I estimate step 2 will take about 3 years, given the > amount of time it took to write the original Sage library, and also > the level of familiarity of most Sage developers with Lisp. Also, we > will likely run into subtle snags with SageLisp's interface for > calling C functions. But with everybody's hard work, we'll get > through this. > > 4. Sage-4.0: On April 1, 2012, we'll release Sage-4.0, which will be > the complete Lisp-rewritten version of Sage. We will then get to work > on porting all of the nasty C/C++/Fortran dependencies in Sage to > Lisp. We'll likely start with GMP/MPIR (we may have to fork, though I > *hope* Bill Hart will be on board), then moving onto mpfr, mpfi, > FLINT, PARI, etc. I estimate that with lots of hard work by everybody > reading this email, we can accomplish this in at most 4 years. This > will be a great contribution to mankind. > > 5. Finally, on April 1, 2016, we'll release Sage-5.0, the fully > Lisp-ified Sage. We will then get back to porting Sage to Windows, > Solaris, and implementing new functionality for combinatorics, linear > algebra, number theory, algebraic geometry, optimization, etc. > > If anybody isn't 100% convinced that this change isn't -- in the long > run (30 years) -- well worth our effort, please respond. > > -- Best Regards, > William Stein > > -- > William Stein > Associate Professor of Mathematics > University of Washingtonhttp://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
