We shouldn't exaggerate.
The Unicode database is necessary for case conversion (uc/lc) and regex matches (is something a whitespace? or a letter? or a number?). Whereas the OEIS database would be only useful for one operator, and even there it's only part of the solution - if you know that a sequence represents a part of the prime numbers, you still have no really efficient way of generating them lazily.
However a library could easily override the infix:<...> operator and thus do what you want. | [reply]
[d/l] |
perhaps the perl6 source could carry the OEIS database. ;-)
I personally believe that (the smiley should suggest me that you're joking, but in case there's even the slightest attempt at being serious about this, I should point out that) a major problem with the OEIS is that it's continuously updated. So this pretty much already rules it out. Also, only a limited number of terms is recorded per sequence in the database, even taking into account ones that can be easily computed to a large extent: thus each one should be accompanied with suitable generating code too, if such code exists!
| [reply]
[d/l] |
Well, yes, I was joking. But to address your problems:
- It being updated isn't a problem. The Unicode database gets updated as well. Just decide at some point in time before you make a release which version of the OEIS you're going to include. That's what we've been doing with the Unicode database as well. The version included in 5.10 is later than the one in 5.8.x, and the one that comes with blead perl is a later version than what's in 5.10. And perl itself gets continuously updated as well. But that doesn't stop many vendors from including perl in their distros.
- As for your second point, many entries in the OEIS have generating formula; sometimes recursive, sometimes closed.
Personally, I don't think the OEIS should be included just to make ".. *" smarter - but for other reasons than you point out.
| [reply] |
| [reply]
[d/l] |