![image.png](https://files.peakd.com/file/peakd-hive/pibara/Eo8M6Niq3edZsxroSkTVV29FJSZGeomSBb3EVqAcU6ERyjkPSe15hPxCGj8bZvauc1h.png) This is part twenty-two in a series on the language spec for the [Merg-E Domain Specific Language for the InnuenDo Web 3.0 stack](/hive-139531/@pibara/merg-e-a-different-type-of-least-authority-language-and-runtime-top-level-overview). Where most previous posts were about v0.3, this is the third post that is about the v0.4 version of the spec. I'll add more parts to the below list as the spec progresses: * [part 1](/hive-139531/@pibara/version-03-of-the-merge-e-language-specification--files-merging-scoping-name-resolution-and-synchronisation) : coding style, files, merging, scoping, name resolution and synchronisation * [part 2](/hive-139531/@pibara/version-03-of-the-merge-e-language-specification--reverse-markdown-for-comments) : reverse markdown for documentation * [part 3](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--actors-and-pools) : Actors and pools. * [part 4](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--locks-blockers-continuation-points-and-hazardous-blockers) : Semantic locks, blockers, continuation points and hazardous blockers * [part 5](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--semantic-lexing-dags-pruneent-and-alias) : Semantic lexing, DAGs, prune / ent and alias. * [part 6](/@pibara/version-03-of-the-merg-e-language-specification--dags-and-dataframes-as-only-data-structures) : DAGs and DataFrames as only data structures, and inline lambdas for pure compute. * [part 7](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--freezing) : Freezing * [part 8](/@pibara/version-03-of-the-merg-e-language-specification--attenuation-decomposition-and-membranes) : Attenuation, decomposition, and membranes * [part 9](/@pibara/version-03-of-the-merg-e-language-specification--sensitive-data-in-non-mutables-and-future-vault-support) : Sensitive data in immutables and future vault support. * [part 10](/@pibara/version-03-of-the-merg-e-language-specification--scalars-and-serialization-to-and-from-high-fidelity-json-hf-json) : Scalars and High Fidelity JSON * [part 11](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--operators-expressions-and-precedence) : Operators, expressions and precedence. * [part 12](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--robust-integers-and-integer-bitwidth-generic-programming) : Robust integers and integer bitwidth generic programming * [part 13](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--the-merg-e-ownership-model-capture-rules-and-the-trustmebro-compiler-flag) : The Merg-E ownership model, capture rules, and the **--trustmebro** compiler flag. * [part 14](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--actorcitos-and-structural-iterators) : Actorcitos and structural iterators * [part 15](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--explicit-actorcitos-non-inline-structural-iterators-runtimes-and-abstract-sch) : Explicit actorcitos, non-inline structural iterators, runtimes, and abstract scheduler pipeline. * [part 16](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--async-functions-and-resources-and-the-full-use-of-innuendo-vaultfs) : async functions and resources and the full use of InnuenDo VaultFS * [part 17](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--ram-points-ram-points-normalization-bag-and-the-quota-membrane): RAM-Points, RAM-points normalization bag, and the quota-membrane. * [part 18](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--literal-operators-and-rational-and-complex-numbers): Literal operators & Rational and Complex numbers. * [part 19](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--interaction-between-operators-integer-bitwidth-generics-and-the-full-numeric-): Interaction between operators, integer bitwidth generics, and the full numeric type-system. * [part 20](/merg-e/@pibara/version-04-of-the-merg-e-language-specification--compile-time-dimensional-analysis-siplanck-units-and-the-scaling-literal-oper) (v0.4): Compile-time dimensional analysis, SI/Planck units and the scaling literal operator. * [part 21](/hive-139531/@pibara/version-04-of-the-merg-e-language-specification--tensors-and-tensor-literals) (v0.4): Tensors and tensor literals. * **part 22** (v0.4): Deprecating float/complex for rquantity/cquantity for full dimensional type-safety. * [part 23](/hive-139531/@pibara/version-03-of-the-merg-e-language-specification--flow-control-and-exceptions) : Flow control and exceptions. In this post I'm doing a short follow up on my previous post on dimensional analysis on floating point type families `float` and `complex`. As you may have read, in my post on dimensional analysis, I was hesitating if I needed to make dimensions mandatory for all floating point types. I have decided that **yes** I should, Merg-E should be radically safe by default and explicit where being implicit comes with risks. However looking into this, it's not simple because we also need to take into account how we handle operator demotion on exact types. ## How operator demotion fits in In part 19 of this series we saw that exact types will promote when used with operators, that the result of an `int64` times a `whole32` plus an `int16` is an `int128`, and how virtual compile time types somewhat reduce the bitwidth explosion. We also saw the absolute promotion limits stemming from virtual types like `Vint20740`. The biggest `int` family runtime type is `int16384`, and as `Vint20740` has no other place to promote to, it demotes to `float256` (now renamed lfreal256), the highest precision floating point. So if we say that all float and complex based values need dimensional annotations and the un-demoted exact countable types never have such dimensional annotations, how do we keep unintended dimension type errors from occurring? We do that by leveraging a unit static field we already discussed, the **sys** or system field. So far we discussed **SI** and **PLANCK** as possible system designations. We add a third value to our spec: **DEMOTE**. ``` inert whole128 a = 4041424344 * 4041424344 * 4041424344 * 4041424344; inert whole1024 b = ( a + 1 ) * a * a * a; inert int8192 c = b * b * b * b; inert quantity::, dimensions::> d = c * c + 1; ``` So what is the purpose of this? Well, as we discussed earlier, quantities with a defined sys parameter don't mix in expression with quantities with a different defined sys parameter. That was the reason we discussed using an empty sys field for dimensionless quantities, so they work well with both PLANCK and SI quantities. And right here that is exactly what we want. The result of a demotion to a float or complex quantity can **only** be used in expressions with non dimensional quantities, and the result of these expressions also can only be used with non dimensional quantities. This is the highest dimensional safety we think we can achieve in Merg-E. Remember, we are mixing two worlds with demotions, and this is the only dimensional way to do that without implicit anything. ## From float/complex to rquantity/cquantity with modifiers In v0.4 we take the radical step to declare that you can no longer write: ``` inert float16 pi = 3.140635; ``` These types (or rather these types by their new name) can only be used as type in a quantity annotation: ``` inert quantity::, dimensions::> pi = 3.140635; ``` This is quite a bit of verbosity. To overcome this verbosity we introduce a language feature called parameterized aliases. Detailed specs of these will come in a later post on the subject, for now we just show how they will work for floats. The base idea is that a type plus a set of modifiers together have an alias, and the modifiers become parameters in the alias. We use this feature to allow us to write something like: ``` inert nodim rquantity16 pi = 3.140635; ``` Here `rquantity16` is a parameterized alias to something along the lines of quantity:: dimensions::> . The `nodim` modifier defines the two alias parameters. ${SYS} and ${DIMS}. This way other modifiers allow us to create shorter notations for common units as well. Some examples | modifier | SYS | dims | absolute | | --- | --- | --- | --- | | nodim | | | false | | demote | DEMOTE | | false | | plancklength | PLANCK | lengh: 1 | false | | silength | SI | length : 1 | false | | plancktime | PLANCK | time : 1 | false | | sitime | SI | time : 1 | false | | planckmass | PLANCK | mass: 1 | false | | simass | SI | mass : 1 | false | | plancktemp | PLANCK | temp: 1 | true | | sitemp | SI | temp : 1 | true | | planckcurrent | PLANCK | charge : 1, time: -1 | false | | sicurrent | SI | current : 1 | false | | planckcharge | PLANCK | charge : 1 | false | | sicharge | SI | current : 1, time: 1 | false | | planckspeed | PLANCK | length: 1, time: -1| false | | sispeed | SI | length: 1, time: -1| false | | planckaccel | PLANCK | length: 1, time: -2| false | | siacceleration | SI | length: 1, time: -2| false | | sisubstance | SI | substance: 1 | false | | siintensity | SI | intensity: 1 | false | The above table is illustrative for now, a complete version will be part of the language spec but is too long for this blog post series. You might have noticed the `demote` modifier. We can use that one in our first bit of code to rewrite: ``` inert quantity::, dimensions::> d = c * c + 1; ``` as: ``` inert demote rquantity256 d = c * c + 1; ``` Some verbosity is left, but this time it's the right amount of verbosity. Looking at actual quantities, things also become less verbose for most meaningful physical quantities using these parameterized aliases: ``` inert quantity::, units.meter> height = 1.825; inert quantity::, dimensions::> ||| speed = 0.07; inert quantity::,dimensions::> g = 9.80665; inert quantity::, units.meter> tinybit = 1.437 þ -9; ``` becomes ``` inert silength rquantity16 height = 1.825; inert planckspeed rquantity16 speed = 0.07; inert siacceleration rquantity16 g = 9.80665; inert silength rquantity256 tinybit = 1.437 þ -9; ``` ## A note on PLANCK vs SI As you may have noted in the partial modifier table, PLANCK and SI dimensions are usually the same, but not always, and some SI units don't have a PLANCK equivalent unit. | modifier | SYS | dims | | --- | --- | --- | | planckcurrent | PLANCK | charge : 1, time: -1 | | sicurrent | SI | current : 1 | | planckcharge | PLANCK | charge : 1 | | sicharge | SI | current : 1, time: 1 | | sisubstance | SI | substance: 1 | | siintensity | SI | intensity: 1 | The reason for this is that even if they share a lot of dimensions for core units, they are not fully equivalent: | unit | SI | PLANCK | | -- | -- | -- | | length | base | base | | mass | base | base | | time | base | base | | temperature | base | base | | electric current | base | composite (charge / time) | | charge | composite (current * time) | base | | substance | base | - | | intensity | base | - | Note that even an SI quantity will have a charge slot and a PLANCK quantity a current, substance and intensity slot, so it is possible to define a quantity with impossible combinations. Checking for these impossibilities won't be a task the compiler will perform due to semantic lexer design, though it is likely we will provide a separate linter that will include checks for this. ## A Note on nodim Interoperability You might wonder: if `sys: DEMOTE` isolation is so strict, how do we use dimensionless scale factors with it? In Merg-E, a nodim quantity has an empty sys field. This allows it to act as a universal scalar. When you multiply a DEMOTE quantity by a nodim quantity, the expression is valid, but the result immediately locks into the DEMOTE branch. This gives you the flexibility to scale demoted values without ever allowing them to leak back into SI or PLANCK spaces. ## A note on literal aliases. It is important to note that any part of the literal rvalue, including literal aliases, are DAGless bones-stage only literal operators and literal operator modifiers. They aren't in any global namespace or any runtime DAG, they are part of the literal operator modifier capture and evaluation, hardcoded into the bones stage of the compiler pipeline. Consider them part of the numeric literal syntax, not of any $scope.lang DAG or global namespace. They are scoped aliases, scoped only to the capture of surrounding modifiers in the bones stage while processing literal operators like 'þ'. In contrast, literal lvalue aliased **are** part of scope.lang and as such are subject to availability by resolve order, capture rules and prune and ent operation on the $scope.lang DAG. The literal lvalue aliases are processed during the muscle phase of the compiler pipeline. ## Conclusion In this post we discussed a major and breaking change to the language spec from v0.3 to v0.4: The deprecation of `float` family and `complex` family numerics as valid type for immutables and mutables. Instead of float, the new quantity float or `rquantity` parameterized type aliases and `quantity` types now takes their place and in doing so enhances the type safety of Merg-E with full dimensionaly analysis type safety. Dimensional type safety that croses the barrier between countble dimensionless types and inprecise floating point types in case of type demotion of huge precise types.

MEASUREMENTS