Feature Proposal: dynamicPriceFormula

[PatriikPlays]

I think it would make sense to have an optional dynamic price formula. I'm not sure what it should use, though - possibly just Lua with only some math functions? I think that would make implementing parsing for it without Lua not too complex, and simple with Lua.

[Erb3]

Note

My idea was clear in my head, but become way too over engineered. This is probably not a great solution.

I suggest we add an optional dynamicPriceFormula on items. If it is not used it should be nil. If it is used, dynamicPrice must be true, but dynamicPriceFormula isn't required if you have dynamicPrice. dynamicPriceForumula's string contains tokens. Spaces are not permitted. There are three types of tokens. PEMDAS must be respected.

Operators must have a value before or after. Operator tokens:

• +
• -
• /
• *
• ^
• (
• )

Function tokens must have values inside of the parentheses, separated by , . Function tokens:

• abs
• acos
• asin
• atan
• ceil
• floor
• round
• tan
• sqrt
• min
• max

Static tokens are static. Static tokens:

• pi

There are placeholders which should be replaced by the consumer:

• {{AMOUNT}} The amount of items to get the price for.

Examples:

• floor(69^{{AMOUNT}})
• {{AMOUNT}}*20+{{AMOUNT}}^2+2 - Every item costs 20 krist, an additional x ^ 2 volume tax, and a static 2 krist receipt printing tax

[scmcgowen]

I'd say that using Lua syntax would make sense considering it could be executed in a limited environment. I'll see what I can do, PRs are ofc welcome

[Kan18]

I am against this idea - I feel like, with the amount of shops using dynamic pricing, it might just be easier for ShopSync receivers to hardcode the formulas for specific shops. I believe SP uses an iterative formula for calculating item pricing, which wouldn't really fit into the proposed scheme anyways, and otherwise there's only the LP.

If we do want to include this anyways, I have a few ideas:

• using S-expressions, e.g. {"floor", {"^", "69", "amount"}} so that receivers don't have to write parsers. I like this option the best because it's both fairly simple and language-agnostic (and it complies with Greenspun's tenth rule)
• just using Lua expressions but with no function creation or string metatable allowed
• some expansion of the two options above to support iterative formulas

[PatriikPlays]

S-expressions seem to make more sense, so we should probably use those. I don't like the idea of implementing iterative formulas, though, because they likely wouldn't be very fast and it sounds like a pain to make calculating them safe.