Better ergonomics when defining functions

[bsidhom]

In the context of #364, I tried implementing a unit list display function for "pace" units (expressed in time units per mile).

Here's what I came up with. Please let me know if I'm missing something obvious and there's a cleaner, simpler way to do this:

fn _pace_sec(p: Time / Length, str: String, append: Bool) -> String =
    if append
        then "{str} + {p -> sec/mi}"
        else "{p -> sec/mi}"

fn _pace_min(p: Time / Length, str: String, append: Bool) -> String =
    if p >= 1 min / mi
        then _pace_sec(p - floor(p -> min/mi), if append then "{str} + {floor(p -> min/mi)}" else "{floor(p -> min/mi)}", true)
        else _pace_sec(p, str, append)

fn _pace_hr(p: Time / Length) -> String =
    if p >= 1 hr / mi
        then _pace_min(p - floor(p -> hr/mi), "{floor(p -> hr/mi)}", true)
        else _pace_min(p, "", false)

fn pace(v: Velocity) -> String =
    _pace_hr(1/v)

This works, but I have a few issues with the above, which was loosely based on the implementation of human() time display function.

• There are no let bindings allowed in functions as far as I can tell. This makes defining local reusable variables impossible and mandates helper functions/recursion to get new variables with scoping.
• There's an explosion of "private" helper functions which unfortunately leak into the global namespace. It would be great if there were a way to define nested functions (or somehow give private scoping when defining them in modules).
  • Note that you can see the human() helper functions in the REPL as well.
• At least this function could be written just once and reused for arbitrary user-defined unit lists if there were variadic function arguments or--better yet--vector types to define the target unit lists. I just want functionality that turns a unit list into a new heterogeneous "base" system within a given type of dimension.
• Variable names in functions do not shadow global definitions. Instead, they clash and cause errors at definition time. I was bitten by this above when I tried to use s for the partially-built string in helper function calls and got an error because it conflicted with the alias for seconds. This makes it difficult to use short, readable local variable names.
• As far as I can tell, function invocations have to appear on a single line (despite the argument lists being unambiguous thanks to mandatory parentheses). It took me quite a while to figure out why I was getting parse errors when trying to call my functions after reformatting across lines for readability.
  • Multi-line input may be a more general problem that could hopefully be solved by relaxing the parser and allowing parenthesized multi-line expressions.

There are probably other things to be done to improve ergonomics, but these are the ones that jumped out at me. Not sure how feasible each of these is, but I'd like to hear others' thoughts.

[bsidhom]

One more nit: since unit lists are not first-class ideas in Numbat, I had to manually define the string formatter above. Thanks to f64 precision, you end up with some unexpected/ugly results with the above implementation. For example:

>>> pace(10 mph)

  pace(10 mph)

    = 6 min/mi + 4.99600e-14 s/mi    [String]

Obviously the seconds field should be rounded to zero, but Numbat isn't aware of that because I produced that value by subtracting out a floor() value from an original floating point value that wasn't precise. Numbat loses rounding information in this case and doesn't realize that this is spurious precision. Admittedly, the pace function could do more to address this directly, but it's generally a tricky problem. I'm not sure how or if it can be solved in general and automatically by Numbat.

[sharkdp]

There are no let bindings allowed in functions as far as I can tell. This makes defining local reusable variables impossible and mandates helper functions/recursion to get new variables with scoping.

See #112 (comment)

There's an explosion of "private" helper functions which unfortunately leak into the global namespace. It would be great if there were a way to define nested functions (or somehow give private scoping when defining them in modules).

* Note that you can see the `human()` helper functions in the REPL as well.

See #201

• At least this function could be written just once and reused for arbitrary user-defined unit lists if there were variadic function arguments or--better yet--vector types to define the target unit lists.

See #261

• I just want functionality that turns a unit list into a new heterogeneous "base" system within a given type of dimension.

Let's discuss this in #364

Variable names in functions do not shadow global definitions. Instead, they clash and cause errors at definition time. I was bitten by this above when I tried to use s for the partially-built string in helper function calls and got an error because it conflicted with the alias for seconds. This makes it difficult to use short, readable local variable names.

This is extremely annoying, yes. See #150

As far as I can tell, function invocations have to appear on a single line (despite the argument lists being unambiguous thanks to mandatory parentheses). It took me quite a while to figure out why I was getting parse errors when trying to call my functions after reformatting across lines for readability.

* Multi-line input may be a more general problem that could hopefully be solved by relaxing the parser and allowing parenthesized multi-line expressions.

Good idea. I added a comment in #112 (comment)