<commit_before># Dart Language and Library Newsletter
2017-10-13
@floitschG

Welcome to the Dart Language and Library Newsletter.

## Follow Up
### Evaluation Order
Last week we discussed the evaluation order of method calls, like `o.foo(bar())`. As some readers correctly pointed out, the section was partially misleading and sometimes based on wrong assumptions. Thanks for the feedback.

We claimed that there was an exception to the left-to-right evaluation in the spec. That's misleading: the is spec is careful (and it uses a lot of otherwise unnecessary machinery) to say that in `e.foo(e1, ..., eN)`, `e.foo` is not an expression that is evaluated. As such, it is meaningless to talk about the "order of evaluation" of method calls, when there are no expressions that are evaluated.

Even after our change - evaluating getters first when they are used as call-targets - it is not meaningful to talk about the evaluation order of expressions, since `o.foo` still isn't an expression.

We also claimed that the expected behavior was to evaluate from left to right. We missed the fact that some method-based languages only look up the method before doing the call. C# and Java, both evaluate the arguments before reporting `null` errors. In contrast, JavaScript and C++ (at least for virtual functions in gcc) report `null` errors before evaluating the arguments to the call.

JavaScript actually changed their behavior in ECMAScript 5.0 (see [es5]). The change was that `GetValue(ref)` in step 2 is now evaluated before evaluating the arguments. The reason for this change was for similar reasons: initially, ECMAScript did not have getters, but with getters it made sense to evaluate the `GetValue(ref)` first, so that the evaluation went from left to right.

[es5]: http://es5.github.io/#x11.2.3

Fundamentally, the question boils down to: Is `o.foo(bar())` the same as `(o.foo)(bar())`?

With the proposed change it will be for most programs. There are some issues with `noSuchMethod` when a function is invoked with the wrong number of arguments, but this corner-case is only relevant in broken programs.

## Did You Know?
### double.toString
Dart has two number types: integers and floating-point numbers. For the latter, Dart uses the IEEE double-precision floating-point type. There are some interesting alternatives, like [unums], but these are not directly supported by our CPUs and are not yet universally available.

[unums]: https://en.wikipedia.org/wiki/Unum_(number_format)

In this section I will focus on Dart's `toString` methods of `double`. There are 4 methods:
- `toString`
- `toStringAsExponential`
- `toStringAsFixed`
- `toStringAsPrecision`

The `double.toString` method is the most commonly used way of converting a double to a string. It uses a mixture of `toStringAsExponential` and `toStringAsFixed` to provide the most visibly appealing output. For large numbers (more than 20 digits) it emits an exponential representation as in `1.3e+21`. The same is true for very small floating-point numbers, strictly smaller than the one represented by `0.000001`. For example  `0.000000998` is printed as `0.98e-7`. All other numbers are printed in the "normal" decimal representation: `5.0`, `1.23`, or `0.001`.

The other methods just force a specific representation. I encourage readers to experiment with them, but I won't explain them in this section.<commit_msg>Fix typo in exponent representation example<commit_after># Dart Language and Library Newsletter
2017-10-13
@floitschG

Welcome to the Dart Language and Library Newsletter.

## Follow Up
### Evaluation Order
Last week we discussed the evaluation order of method calls, like `o.foo(bar())`. As some readers correctly pointed out, the section was partially misleading and sometimes based on wrong assumptions. Thanks for the feedback.

We claimed that there was an exception to the left-to-right evaluation in the spec. That's misleading: the is spec is careful (and it uses a lot of otherwise unnecessary machinery) to say that in `e.foo(e1, ..., eN)`, `e.foo` is not an expression that is evaluated. As such, it is meaningless to talk about the "order of evaluation" of method calls, when there are no expressions that are evaluated.

Even after our change - evaluating getters first when they are used as call-targets - it is not meaningful to talk about the evaluation order of expressions, since `o.foo` still isn't an expression.

We also claimed that the expected behavior was to evaluate from left to right. We missed the fact that some method-based languages only look up the method before doing the call. C# and Java, both evaluate the arguments before reporting `null` errors. In contrast, JavaScript and C++ (at least for virtual functions in gcc) report `null` errors before evaluating the arguments to the call.

JavaScript actually changed their behavior in ECMAScript 5.0 (see [es5]). The change was that `GetValue(ref)` in step 2 is now evaluated before evaluating the arguments. The reason for this change was for similar reasons: initially, ECMAScript did not have getters, but with getters it made sense to evaluate the `GetValue(ref)` first, so that the evaluation went from left to right.

[es5]: http://es5.github.io/#x11.2.3

Fundamentally, the question boils down to: Is `o.foo(bar())` the same as `(o.foo)(bar())`?

With the proposed change it will be for most programs. There are some issues with `noSuchMethod` when a function is invoked with the wrong number of arguments, but this corner-case is only relevant in broken programs.

## Did You Know?
### double.toString
Dart has two number types: integers and floating-point numbers. For the latter, Dart uses the IEEE double-precision floating-point type. There are some interesting alternatives, like [unums], but these are not directly supported by our CPUs and are not yet universally available.

[unums]: https://en.wikipedia.org/wiki/Unum_(number_format)

In this section I will focus on Dart's `toString` methods of `double`. There are 4 methods:
- `toString`
- `toStringAsExponential`
- `toStringAsFixed`
- `toStringAsPrecision`

The `double.toString` method is the most commonly used way of converting a double to a string. It uses a mixture of `toStringAsExponential` and `toStringAsFixed` to provide the most visibly appealing output. For large numbers (more than 20 digits) it emits an exponential representation as in `1.3e+21`. The same is true for very small floating-point numbers, strictly smaller than the one represented by `0.000001`. For example  `0.000000998` is printed as `9.98e-7`. All other numbers are printed in the "normal" decimal representation: `5.0`, `1.23`, or `0.001`.

The other methods just force a specific representation. I encourage readers to experiment with them, but I won't explain them in this section.
{'fraction_non_alphanumeric': 0.06838861168183152, 'fraction_numerical': 0.016436747872028177, 'mean_word_length': 4.622937293729373, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7191481', 'n_tokens_mistral': 1792, 'n_tokens_neox': 1675, 'n_words': 1002}