Request for more numeric data types Fixed point decimal, and baseN arithmetic.

[keithy]

It looks to me like Nickel may find itself useful for modelling in many domains, not just configuration.
Think, "heirarchical, formula laden spreadsheet." Then consider all the uses that spreadsheets have been applied to, given their "limited" capability, and UI.

Yes I am hoping to use Nickel in my day job, but since I work for a fintech, I am looking to sell the idea higher up the food chain, in order to get some buy in.

One specific limitation I can see is the lack of arbitrary base numeric representation, even binary, and the type of Fixed point decimals (ScaledDecimal class in Smalltalk environments 5.55s) that would be the bread and butter of financial models. and not forgetting first class support for percentages. It might also be worth tagging numerics with a "unit", nothing major, just enough to be able to restrict aithmetic to numbers of the same type. (e.g. 10.00sUSD + 5.00sGBP does not compute!) Percentages could use the same notation 10.2s%.

So it looks like I am requesting the reservation of a syntax, like 10.2xxxx, such that the tag can be passed on to a plugin
of some kind that implements alternative numerical oprations (and operators?). 1100b >> 2 = 0011b binary shift right.

In that case then the same plugin scheme could handle variations on string types, much like pyhton 3's f"super".

Without this, I am thinking that you will eventually find some idiot (i.e. me) hacking all these things into strings.

Perhaps a more generic mapping, 10x4y3z (co-ordinates) 10r5i (complex numbers) 10r1.2 (polar radians) 199.00long0.0lat 22n7d (fractions) 10.5s%1000.00sUSD (loan), mapping these straight into sets? { "s%" = 10.5s , "sUSD" = 1000.00s } still needs the fundamental ScaledDecimal type.

And for strings some further plugin supplied mappings file"system.yaml" -> { name -> "system" , extn -> "yaml" } version"10.12.10" => { major = 10, minor = 12...} uri"https://blah".

Just putting this out there...

Nickel n Dime(s)?

[milahu]

what would haskell do? ; )

[yannham]

It looks to me like Nickel may find itself useful for modelling in many domains, not just configuration.
Think, "heirarchical, formula laden spreadsheet." Then consider all the uses that spreadsheets have been applied to, given their "limited" capability, and UI.

That's an interesting perspective, and it makes sense indeed. Especially if at some point we implement incremental evaluation, then as already noticed in #103, that would make incremental recursive records close to a build system (that is, something that is about managing dependencies and propagating incremental changes across those dependencies). And Build system à la carte does include Excel in their definition of a build system 🙂

So yes, in some view, a configuration can bee sen as a tabular structure (records and list) specifying data and inter-dependencies between those data.

That being said, those are two different usages, with different trade-offs. For example, configuration languages are intuitively not going to do a lot of number crunching, and can afford to not be very efficient on this front. This is also a lot of new syntax for people to read and understand, and to be honest, I am a bit skeptical of

version"10.12.10" => { major = 10, minor = 12...}

being useful over just using a function as a constructor

mylib.version "10.12.10"

Unless you expect it to do more than that?

I guess reserving the syntax and having a constructor is not enough. You also need to overload builtin operators, if you want to be able to do e.g. 10x4y3z + 20x2y30z. This brings in its own lot of complexity (in particular, one can't type such overloaded operators in the type system).

To sum up, it's an interesting usage, and I don't think we plan to use the kind of syntax range your are requesting. But I don't see the Nickel project making any decision based on such use-cases in the near future, such as having a generic interface for plugins to define new number types and operations on them, or to reserve this syntax for sure. Nickel is first and foremost a configuration language, with a focus on Nix integration in the near future.

As a side note, having such kind of overloaded strings (like your version and file) may prove necessary to implement Nix string contexts and other kind of alike dependency inference in general. So, having custom string flavors that delegate the string construction and basic string operation like concatenation to plugins is not out of the question.