
Show HN: calcl – A Programmatic Calculator - codr7
https://github.com/codr7/calcl
======
stdcall83
Nicely done. did you using shunting yard algorithm for parsing the
expressions?

I also developed developers calculator, but I didn't add support for float as
you did.
[https://www.github.com/mellowcandle/bitwise](https://www.github.com/mellowcandle/bitwise)

~~~
codr7
Thank you :)

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](https://github.com/codr7/g-fu/blob/master/v1/src/gfu/read.go)

[https://github.com/codr7/cidk/blob/master/src/cidk/read.cpp](https://github.com/codr7/cidk/blob/master/src/cidk/read.cpp)

------
theamk
The magic precision fixed point numbers are super cool.

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

~~~
codr7
Glad you like them, one of the most underrated abstractions in software if you
ask me. Floats are just plain evil for most use cases. I spent 13 years
maintaining a 2Mloc accounting system written using an exotic mix of float
types and layers upon layers of failed attempts to control the resulting
rounding chaos.

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.

[0] [https://github.com/codr7/cidk](https://github.com/codr7/cidk)

