There's an XY problem floating around in this question. I'll try to answer both parts of it.
From comments, the core problem:
I am trying to ease the job of the people in my company who came to me requesting to find a better solution than using Excel spreadsheets to do various custom-product computations, that change frequently. They want to move away from Excel, and onto the web, and they want to be able to update formulas and variables themselves. Excel is not on the web and they have to pass excel sheets to each other each time they make a change, creating tons of outdated excel sheets in the process that linger on people's machines. I am to try and make this process better.
This is a content management problem - not a programming one. You are looking for solutions that involve the use of Excel on the web. One option is a enterprise content management solution such as Sharepoint. Another is the Excel Web App. This is the problem you are really trying to solve - having a consistent single source of the data and calculation.
Now, the "lets try to implement this in another language." Your options are:
- Unsafe full language with
- Writing a domain specific language that is as powerful as Excel
One should realize that the spreadsheet is, at its heart, a functional language with equations and data mapped onto a cartesian plane of rows and columns.
You are going to run headlong into Greenspun's tenth rule
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
You are writing another functional language in php (if you're lucky - thats to help users retain as much of their skills from Excel to this language). You are going to try to make it so that it is 'safe', and 'easily understood by someone who has no more programing experience than writing Excel equations' (and lacking the useful checking that excel provides you).
You are going to persist this information (the code is data) into a database (if you are lucky - some other data store if you aren't) somehow, pull it out of the persistence, evaluate it all on the fly, allow someone to make a change, content management on top of that (who made the change?), and possible versioning too once you're done with the project.
The thing you are going to end up building to try to support the core problem is not going to be small. Ever time you turn around users are going to be asking for another function to be added. Could you add
ACCRINT? How about
LINEST? How do I do a
VLOOKUP in this language?
This is a wonderful idea to have a team of talented coders to be working on as a product to sell. It is an impossible task for a side project for a single programmer (or even small team) with other priorities and fires going.
I'm not saying you can't do it. But the problem that you are trying to solve with this solution isn't even going to be a suitable duct tape solution for any duration of time... and the support of the hypothetical application will be a full time job of its own.
Use an existing tool that solves your problem. Its price is likely a small fraction of a FTE.