Show HN: calcl – A Programmatic Calculator
github.com
github.com
I also developed developers calculator, but I didn't add support for float as you did. https://www.github.com/mellowcandle/bitwise
Sorry, no. I used to be really into parsing algorithms and tools, and I still consider them useful for more mundane tasks. But the last thing I need when exploring the syntax of a new language is someone else's arbitrary limitations.
My language parsers [0] tend to be rather messy recursive-decentish creations. But I think that's fine; since in a new language the syntax should be allowed to move around freely, and prematurely nailing it to the floor to check a box isn't really going to help anyone.
What usually happens is I'll tighten the parser as needed along the way when I feel confident enough. Which brings us to the issue with parsing tools, they're all in from the start rather than gradual.
https://github.com/codr7/g-fu/blob/master/v1/src/gfu/read.go
However, if you don't need them, I don't see an advantage over regular languages - for example, Python's interactive shell will do the same and much more
Agreed, same is true of many general purpose languages. One advantage is a stronger compiler with more static guarantees than Python that produces significantly faster code.
What is gained from restricting the use case is simplification of syntax and semantics. Once you don't have to cover all bases any more, you don't have to make as many compromises. I'm barely getting started here, once I get around to defining functions/equations/integrals etc. it will become more obvious.
Easier embedding/integration is another good reason. Let's say you need to evaluate formulas in some application. Adding Python as a build dependency is serious business and writing your own means reinventing a lot of infrastructure along the way.
Finally, building on top of cidk [0] means smooth integration with any language targeting the same framework. The calc opcode mentioned in the README is a good example.