Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IronCalc – Open-Source Spreadsheet Engine

ironcalc.com

Post reply on HN
Print view View original

31–40 of 238 posts

Re: IronCalc – Open-Source Spreadsheet Engine

#32

Post by dwroberts »

Had a comment here about larger values/arbitrary precision (e.g. 74829901923401860/14408150751351922) and realised that it isn't choking on the number but it seems to error if I paste in values? In Firefox:

Uncaught RuntimeError: unreachable executed pasteCsvText assets/index-BxqQcmeI.js:40

Re: IronCalc – Open-Source Spreadsheet Engine

#33

Post by bonzini »

fatih-erikli-cg wrote: post #25
bonzini wrote: post #20

Earlier quoted context omitted.

The function for asterisks and slashes is called from the functions for pluses and minuses. The result is that asterisks and slashes are evaluated before pluses and minuses. It's actually very easy to understand once you get the idea. https://en.wikipedia.org/wiki/Recursive_descent_parser

I don't think a recursion should be involved in the parser. Shift-reduce may be an answer but it does not fix the problem either if you try to implement that. I would like to see real code rather than written homework pieces.

You're conflating parsing of expressions with operator precedence parsers (aka Pratt parsers). IronCalc uses a recursive descent parser, and Pratt parsers are an optimization of recursive descent parsers. Pratt parsers have one function that implements all precedence levels, while recursive descent parsers have one function per precedence level, but they contain basically the same logic.

Source: 20 years ago I converted GCC's C++ parser from recursive descent to an operator precedence parser; obviously GCC respected precedence even before my work, which was purely an optimization. In fact the code I replaced had the note "The expression parser recurses through the various levels of precedence as specified in the grammar, rather than using an operator-precedence technique".

https://github.com/gcc-mirror/gcc/commit/b8b94c5ba81744d325f...

Re: IronCalc – Open-Source Spreadsheet Engine

#35

Post by nhatcher »

ericra wrote: post #30
nhatcher wrote: post #5

Hey! This is my project! Amazed to see this here. I'll try to answer questions people might have

Great project. I particularly love the: 1) mit license 2) using plausible instead of Google analytics. Practically speaking, uBO is going to block both by default, but for non-tech users this is great. 3) appreciate how the app respects your pc when the web app is running in the background. Very low footprint, no random CPU spikes or anything. Wish you guys the best.

Thanks :).

WRT: Plausible. I think I will remove all kinds of analytics, I'm not yet convinced I should be using them at all. That being said I had been longing to try Plausible for the a long time and this seemed like a good opportunity.

Re: IronCalc – Open-Source Spreadsheet Engine

#36

Post by amluto »

fatih-erikli-cg wrote: post #25
bonzini wrote: post #20

Earlier quoted context omitted.

The function for asterisks and slashes is called from the functions for pluses and minuses. The result is that asterisks and slashes are evaluated before pluses and minuses. It's actually very easy to understand once you get the idea. https://en.wikipedia.org/wiki/Recursive_descent_parser

I don't think a recursion should be involved in the parser. Shift-reduce may be an answer but it does not fix the problem either if you try to implement that. I would like to see real code rather than written homework pieces.

Better not use popular toolchains then:

https://gcc.gnu.org/wiki/New_C_Parser

https://clang.llvm.org/features.html

I think this is a quite popular approach for multiple reasons. That being said, tree sitter uses GLR.

Re: IronCalc – Open-Source Spreadsheet Engine

#37

Post by nhatcher »

dwroberts wrote: post #32

Had a comment here about larger values/arbitrary precision (e.g. 74829901923401860/14408150751351922) and realised that it isn't choking on the number but it seems to error if I paste in values? In Firefox: Uncaught RuntimeError: unreachable executed pasteCsvText assets/index-BxqQcmeI.js:40

Thanks for the bug report!

I just added csv copy/paste, most likely an error there. We don't support arbitrary precision arithmetic but I would like to.

Re: IronCalc – Open-Source Spreadsheet Engine

#38

Post by fatih-erikli-cg »

bonzini wrote: post #33
fatih-erikli-cg wrote: post #25

Earlier quoted context omitted.

I don't think a recursion should be involved in the parser. Shift-reduce may be an answer but it does not fix the problem either if you try to implement that. I would like to see real code rather than written homework pieces.

You're conflating parsing of expressions with operator precedence parsers (aka Pratt parsers). IronCalc uses a recursive descent parser, and Pratt parsers are an optimization of recursive descent parsers. Pratt parsers have one function that implements all precedence levels, while recursive descent parsers have one function per precedence level, but they contain basically the same logic. Source: 20 years ago I conver…

Operator precedence is an addition to parsing of expressions. Both of them is needed if you accept "2 + 1" kind of expression. "2 + 2 * 2" must be evaluated like "2 + (2 * 2)". Only expression parsing will evaluate them like 8.

Re: IronCalc – Open-Source Spreadsheet Engine

#39

Post by nhatcher »

iamthejuan wrote: post #34

I am genuinely looking forward for the success of this project. I am just wondering will this support scripting language like VBA for Microsoft Excel?

Thanks. I am thinking a lot about this recently. We will definitely support a scripting language, or rather several scripting languages. VBA won't be one of them, I think. I wouldn't want to create a language just for this. Maybe use a language like Lua or perhaps Rhai[0]. By design extending and embedding IronCalc should be very easy. Work in this direction will not start in the next 9 months though.

[0]: https://github.com/rhaiscript/rhai

Post reply on HN