Easy one.

Is it possible to introduce Abacus.syntax?/[1,2] function, returning {:ok} / {:error, extended_info}? It might be quite handy in case of deferred operations. In my use case, I accept an expression as, say, user input, and execute it later on some alert. I would appreciate having an ability to inform the user that the expression introduced has syntax glitches.

I could provide a pull request for just this feature, but I think it’s up to you to decide whether you want to use it also in eval/[1,2], or not.

Currently the formula’s parser fails with:

{:error, {1, :math_term_parser, ['syntax error before: ', '\'.\'']}}

on floats with omitted leading/trailing zero (.25 / 2..) It is quite common to have floats being written that way, so I would suggest it makes sense to accept this notation.

TODO

• Registry for unit strings to their definitions
  • Possibility to use aliases (for example meter to m)
• Prepare lexer and parser to parse unit expressions
  • m / s should be parsed as {:divide, {:unit, "m"}, {:unit, "s"}}
• Add second parser-pass to map {:unit, binary} to a unit definition
• Change eval/2 functions to support multiplication operations (/, *, ^) on amounts
• Support SI prefixes (m, k, M, ...)
• function to convert units

The parser should be improved so that we can extract the line and column where a syntax error happened in the input.

With this, error reports like the following should be possible:

Input: 1+)
         ^
Unexpected Token '('.

What needs to be done for this:

• Pass the column of a symbol when lexing
• Put this column into the error when the lexer or the parser have a problem
• Get the correct message out of parser errors

• square root
• n-th root
• all hyperbolicus trigonometric functions
• cotan
• div
• mod

• Bitshift >> <<
• & | |^ ~ (and or xor not)

TODO

• Parse to AST
• Write eval code
• Write formatter
• Test all 3

I am suggesting that we add a rand function to the library.

This is just a cosmetic thing, but maybe interesting for others...

The dialyzer is complaining about the eval function and a boolean expression. According to the docs, the return type is always a number(), which is not correct in the case of an boolean expression evaluation. There the return value is an atom(), 'true' or 'false'.
So is there a way to tell the eval function that we have an boolean return value? Or change the return value in general to any()?

• binary 0b...
• octal 0o...
• hex 0x...

AbacusSql.Term.parse ~s["\\""]  == {:ok, "\\"}

should be

{:ok, "\""}

• pi
• euler's number

...

Should return "1234":

iex(13)> Abacus.eval("\"1234\"", %{})
{:ok, 1234}

iex(1)> Abacus.eval "a>5", %{"a" => 4.5}
{:ok, false}
iex(2)> Abacus.eval "a>5", %{"a" => "4.5"}
{:ok, true}

Of course, I can do a coercion to respective Float before evaling, but people expect this to be done by abacus :)

I believe, the coercion might be easily done here. Please confirm, and I will provide the pull request.
Thanks in advance.

• . for accessing key
• [expr] for accessing an index of an array

Supporting Polish Notation would be a cool addition to this library in my opinion. Or a polish notation evaluation library may be a idea for another math library? But I dont know how something like this would be done. Just throwing the idea out here.

https://en.wikipedia.org/wiki/Polish_notation

Thanks for reading my issue!

Offer registering own functions by name in runtime, so they can be called in a abacus expression.

Hey!

Our use case only involves evaluating basic maths and floating point manipulation functions - we would love to be able to disable the evaluation of things we don't need, such as factorial, bitwise, comparison, boolean operators, Enum API, etc.

Do you know of any way we could achieve that right now, and if not, would it be possible to add such a configuration option to the library? For example, a "whitelist" of operations.

• ==
• !=
• <
• >
• <=
• >=
• x ? a : b
• and, or, not