Design Goals for Runtime module

[benhutchison]

@erikerlandson Can you comment on the design goals of the new runtime module you are building?

If the unit check is done at runtime and fails, then we still have a runtime error. Is the main point that the resultant error is clearer, more precise, and potentially earlier?

[erikerlandson]

My personal main goal for runtime is to allow ingest of unit-aware data. In scala-2 this was supported via coulomb-parser and looked like this:
https://github.com/erikerlandson/coulomb/tree/scala2/coulomb-pureconfig#examples

(other formats besides pureconfig were supported, although I may drop everything except pureconfig for scala 3).

Note that in the scala-2 world, there was no RuntimeQuantity, only parsing. However, @armanbilge had some interest in true runtime quantity objects, and so I have been experimenting with what that could look like.

As you say, when unit information is run-time, all operations can fail, and so all of my operations return Either[...] objects, where failure manifests as a Left value.

In terms of my goals for things like pureconfig ingestion, in a world with RuntimeQuantity, the ingest will probably return one of these, and then one can "lift" it into typelevel Quantity via toQuantity - again, this must return Either but it is a principled way of moving between the runtime and typelevel world.

[erikerlandson]

@armanbilge I'm interested in your take on how this concept for RuntimeQuantity is shaping up and whether you would/could use it. I have proven to my satisfaction that an entire parallel runtime implementation is very do-able. It has the additional benefit of being able to re-use all of the static unit definitions.

However, it does require an entire parallel re-implementation of the operations, unit conversions, etc, and associated unit testing, so it would be some work for sure, and I'm trying to get a feel for what the benefits are to the community.

As I explained above, my own primary interest is being able to parse external inputs at runtime. I actually think RuntimeQuantity is a decent vehicle for that, but I could easily implement just a "skeleton" of that without all the associated operators, etc. All I really need for supporting something like pureconfig i/o is a RuntimeQuantity that has toQuantity to lift into static type-level.

One approach could be to implement the pieces I need now, and adding a full parallel runtime universe could be deferred.

[erikerlandson]

Here's another design question I am pondering: In the original scala-2 world, I parsed unit expressions that look like this:

{"value": 1, "unit": "meter/second"}

(see here)

However, I proposed a somewhat more structured format to avro:

{"value": 1, "unit": {"lhs": "meter", "op": "/", "rhs": "second"} }

(see here)

Clearly, the first is more human readable, however it has some drawbacks:

• it requires a dedicated custom parser
• its expressions are also human authored and potentially more prone to error

The second is not as easy for a human to read, however:

• it can leverage standard json parsers
• it can include checking using JSON schema specs, such as the one I defined here

I'm actually leaning toward the second one, since pureconfig and most config libraries can ingest json and this design makes better use of json structures, and I can provide the json schema for checking if people want to take advantage of that.

[erikerlandson]

I just refreshed myself on how pureconfig integration actually works, and most i/o parsing is handled by pureconfig itself, so it's debatable how important an official json schema is, although it might still be a useful resource if it can be aligned with what pureconfig itself is doing.

xref: pureconfig/pureconfig#1330 (comment)

[erikerlandson]

I have a nice idiomatic ConfigReader and ConfigWriter for RuntimeUnit. It looks like this:

scala> RuntimeUnit.of[Meter / (Second ^ 2)]
val res3: coulomb.RuntimeUnit = Meter/(Second^2)
                                                                                                                                                
scala> ConfigWriter[RuntimeUnit].to(res3)
val res4: com.typesafe.config.ConfigValue = SimpleConfigObject({"den":{"b":{"path":"coulomb.units.si$.Second","type":"type"},"e":{"d":"1","n":"2"},"type":"pow"},"num":{"path":"coulomb.units.si$.Meter","type":"type"},"type":"div"})
                                                                                                                                                
scala> ConfigReader[RuntimeUnit].from(res4)
val res5: pureconfig.ConfigReader.Result[coulomb.RuntimeUnit] = Right(Meter/(Second^2))

From a software perspective this is very clean. From the perspective of humans authoring config files with these expressions, or reading them, I find it a bit unsatisfying.

I'm thinking about whether there is any alternative "codec" scheme that is a better compromise with structured-ness and readability, that doesn't require a custom parser for a unit expression language.

[erikerlandson]

Another interesting aspect of the above is that "named units" like "meter" are denoted by their fully qualified type name. In some ways I kind of like that, although again the human UX suffers a bit. I'd have to plumb in a "mapper" to allow something like reading "meter" as "coulomb.units.si.Meter", or similarly some kind of logic to parse out "kilometer" into Kilo * Meter, which I liked in scala2 but it required some weird lexing hackery.

very weird: I baked prefix-units and regular units right into the lexing regex:
https://github.com/erikerlandson/coulomb/blob/scala2/coulomb-parser/src/main/scala/coulomb/parser/parsing.scala#L50

[erikerlandson]

I might still do a unit expression parser. I'd probably try using typelevel cats-parse this time.
https://index.scala-lang.org/typelevel/cats-parse

cats-parse has no lexing layer, however I could build my logic for unpacking kilometer -> Kilo * Meter into the parsing layer. In fact it would be cleaner.

[benhutchison]

Second option with a more structured unit definition seems entirely usable to me. Can still be hand written when needed for examples, tests and docs.

…

On Sat, 25 Feb 2023, 6:41 am Erik Erlandson, ***@***.***> wrote: Here's another design question I am pondering: In the original scala-2 world, I parsed unit expressions that look like this: {"value": 1, "unit": "meter/second"} (see here <https://github.com/erikerlandson/coulomb/tree/scala2/coulomb-pureconfig#examples> ) However, I proposed a somewhat more structured format to avro: {"value": 1, "unit": {"lhs": "meter", "op": "/", "rhs": "second"} } (see here <https://github.com/erikerlandson/unit-analysis-json-schema>) Clearly, the first is more human readable, however it has some drawbacks: - it requires a dedicated parser - it's expressions are also human authored and potentially more prone to error The second is not as easy for a human to read, however: - it can leverage standard json parsers - it can include checking using JSON schema specs, such as the one I defined here <https://github.com/erikerlandson/unit-analysis-json-schema/blob/master/unit-analysis-schema.json> I'm actually leaning toward the second one, since pureconfig and most config libraries can ingest json and this design makes better use of json structures, and I can provide the json schema for checking if people want to take advantage of that. — Reply to this email directly, view it on GitHub <#433 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXJZDECZON7N7ULNOWGRTWZEFHNANCNFSM6AAAAAAVE6FBLQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>