Expression parser: zero-based or one-based?

[josdejong]

With last update we consistently changed the behavior of indexes to zero-based, with upper-bounds excluded. I think this is a good choice for the library - most programming languages are zero-based (including JavaScript), so programmers will be familiar with this.

I also changed the expression parser to zero-based indexes, to be consistent with the underlying library. However I'm in doubt whether that is the right thing move. I think the expression parser is typically used to allow end-users (non-programmers) to enter mathematical expressions. This is a very different audience, consisting of mathematical oriented people. I think most of them will be used to one-based indexes including upper-bound, as all big math applications (Mathematica, Maple, Matlab, Octave, SciLab) use one-based indexes. An exception is Sage though, which is zero-based.

I would like to use the expression parser in my own math application, but right now I can't use the expression parser because I think the zero-based behavior will alienate users. I will have to fork the project and change the expression parser to one based before I can use it. I'm affraid it will be the same with other people, which makes the expression parser as it is right now kind of useless...

Maybe it is not such a bad thing to have an expression parser which works different from the underlying library, as it targets a different audience (also suggested by @garrison in #59. Actually this is already the case with for example range syntax using colons :, and matrix concatenation with [A, B], etc. I think this will remove a lot of friction, and allows to offer an optimized API for two different audiences on two different application levels.

Any thoughts on this?

[garrison]

I think you are correct that math.js is simultaneously trying to appeal to two different audiences. I expect this will lead to tensions now and eventually, so I see two clear paths forward which you must choose between.

1. Make the expression parser match the underlying math.js library as much as possible. This may mean that the high-level language is a bit less intuitive to the math audience, but it will mean consistency for the project as a whole.
2. Decide that the expression parser should be its own high-level language, with its own quirks and nuances not necessarily conforming to the underlying low-level math.js API. In this case, I would expect the expression parser to eventually be spun off into its own project with its own name, separate priorities, etc, in order to reduce confusion. For the time being, it will make much sense to continue developing them in the same git repository as they influence each other and stabilize together, but in the long term I would expect them to become separate if they have separate (though related) goals and visions. (They can, of course, be part of the same meta-project, but it would be good to have names that distinguish between them, so that a person can e.g. say "math.js uses zero-based indices" and people know whether that is a statement about the low-level library or the expression parser.)

I think the first choice simplifies matters for now, and always leaves open the possibility of migrating down path #2. But it sounds like you are experiencing tension between the competing audiences/goals of the project, and it seems to me like the best way to handle that would be to eventually have two projects, one of which builds upon the other, and both of which enable a different audience to get exactly what they want.

Aside from zero/one-based indices, it would be great if the differences between the two platforms were minimized. But maybe that is difficult to do and still have the flexibility you want in the expression parser? I think you are the best judge, as you know more than anyone the eventual goals for the expression parser. (Do you have any desire for it to become its own Turing-complete programming language? If it becomes successful, people will probably want to be able to extend it such that they can program it on its own. If you keep with the normal JavaScript conventions, you can allow people to simply extend it naturally using JavaScript. But if you start doing things that break JavaScript conventions, then you will need to extend and eventually build a full language as people want to do more and more complicated things with it. It all depends on how much work you want to put in, eventually...)

Please note that I am more interested in the low-level API than the expression parser (at the moment, at least!) so keep that in mind too when weighing my opinion :).

[sebpiq]

We have been talking with Jos, that in the near future we'll probably refactor mathjs into a plugin-based library. So it would make sense to have the parser built on top of the core. In which case it can indeed choose its own syntax.

[sebpiq]

See #71

[josdejong]

Thanks for your feedback. I will do this, and fully separate the expression parser from the rest of the library (code, unit tests, examples, docs). Later on we can decide to put the expression parser as a separate plugin.