unit to other unit

[stefnotch]

I'm used to other unit converters that are able to deal with the to keyword.

Essentially, 3cm to ft should behave just like 3cm -> 3ft. I'm guessing this part of the code would have to be tweaked? https://github.com/gissehel/BarLauncher-UnitConverter/blob/09d23f7a98c3e92cd33ee7f96a51c6ba3da723fc/BarLauncher.UnitConverter.Lib/Service/UnitConversionService.cs#L42

[gissehel]

Hello,

Yes, that seems the only place to change.

There are also other occurrences used for feedback. Using "word" like "to" may be dangerous as you can add both units and prefixes. So "to" may collide with that...

Currently, in the default base, it doesn't.

I can try to add a way to configure that for example with:

unit config conversionSyntax=to

and with an "easy" way to find how to convert things ("unit config" would list all keys to config, at first only "conversionSyntax", and selecting it would pre write "unit config conversionSyntax=->" and you would just need to edit that and validate.

Would that be ok ?

[stefnotch]

I see, that's a good point. Some potential ways of resolving this would be

• Adding a config, as you mentioned.
• Always validating that the added units do not conflicts with the keyword. Alternatively, this validation could disable the "to" keyword if it finds a unit that conflicts with it.
• Figuring out how to add to, while keeping the grammar unambiguous.

Now, as for my reasons behind opening this issue:

• Typing -> takes more effort than typing to.
• I'm used to being able to use to, it actually took me a while to figure out that -> is the correct syntax.

[stefnotch]

I think as long as units with spaces don't make sense, having a keyword with letters would be reasonably unambiguous.

Here is a very rudimentary EBNF grammar. Link to playground%3F%0A%0A%3CValue%3E%20%3A%3A%3D%20(%3CNumber%3E%20(%3CSpace%3E)%3F)%3F%20%3CUnitValue%3E%0A%0A%3CNumber%3E%20%3A%3A%3D%20%22.%22%20%3CDigits%3E%20%7C%20%3CDigits%3E%20(%22.%22%20(%3CDigit%3E))%3F%0A%3CDigits%3E%20%3A%3A%3D%20%3CDigit%3E%20(%3CDigit%3E)%0A%3CDigit%3E%20%3A%3A%3D%20%220%22%20%7C%20%221%22%20%7C%20%222%22%20%7C%20%223%22%20%7C%20%224%22%20%7C%20%225%22%20%7C%20%226%22%20%7C%20%227%22%20%7C%20%228%22%20%7C%20%229%22%0A%3CSpace%3E%20%3A%3A%3D%20%22%20%22%0A%0A%3CUnitValue%3E%20%3A%3A%3D%20%22cm%22%20%0A%2Fa%20proper%20unit%20without%20spaces%20%2F%0A&name=)

Value = [Number [Space]] UnitValue

Number = Dot Digits | Digits [ Dot {Digit} ]
Digits = Digit {Digit}
Digit = "0" | "1" | ... | "9"
Space = " "

UnitValue = a proper unit without spaces

Conversion = Value [("to" | "->") Value]

[stefnotch]

Okay, I took a look at how this library works:

• It first reads a conversion string like 3 cm -> m and splits it where the -> is. https://github.com/gissehel/BarLauncher-UnitConverter/blob/09d23f7a98c3e92cd33ee7f96a51c6ba3da723fc/BarLauncher.UnitConverter.Lib/Service/UnitConversionService.cs#L33
• And in there, it uses the Unit.Lib.UnitService to actually parse the units

[stefnotch]

The probably elegant way of fixing this would be

1. Extend the Unit.Lib with a parsing function that "consumes" whatever it can parse. For example .Parse("3 cm cat") should end up parsing the "3 cm" part, and tell the caller that the remaining part is " cat"
2. Change convert to first call .Parse(search). And then, convert would check if there is a -> or a to (separator). If yes, it would attempt to .Parse(search.Substring(indexAfterSeparator))

This essentially mimics how parser combinator libraries like Pidgin approach this problem.

It would still be tricky with to being a unit, let's say "tonne" Then 3 to m would be parsed as 3 to with a m left over.

[gissehel]

• Always validating that the added units do not conflicts with the keyword. Alternatively, this validation could disable the "to" keyword if it finds a unit that conflicts with it.

The problem here is that "t" may be a prefix, and "o" the unit. So all combination should be tested.

I'll try to see how to do that.

[gissehel]

• And in there, it uses the Unit.Lib.UnitService to actually parse the units

Yes, the main problem here is that parsing for "bar stuff" is done in this project, while parsing of the unit is done in the lib (while I wrote and maintain both, I still think that having a dedicated lib for unit, and the bar project just as an usage example of that lib is cleaner).

I don't use a bnf grammar at all (I could, I've already done that is other projects), but the parsing splitted in two different layers make it more complex. Still not impossible. I think I'll prefer a solution with basic parsing.

[AlennGK]

• Always validating that the added units do not conflicts with the keyword. Alternatively, this validation could disable the "to" keyword if it finds a unit that conflicts with it.

The problem here is that "t" may be a prefix, and "o" the unit. So all combination should be tested.

I'll try to see how to do that.

I was used to use ":" separator like 5l/s:m3/hod ... no time for spacing, or power function aka simple math wont work like in keypirinha and launchy: "un 10**3kg" = err. Do you think that it is possible to parse and precompile to number before conversion?