Big update to prettier-extension-monkeyc

var x = jparts[0]; // julian 2000.0 date, a double
var y = null as Boolean;
testType(x, y);

public function testType(arg1 as Number, arg2 as Boolean) {
	System.println("arg1 " + arg1 + ", arg2 " + arg2);
}

Gives this:

arg1 8701.133116, arg2 null
arg1 8701.133128, arg2 null
arg1 8701.133139, arg2 null
arg1 8701.133151, arg2 null

So, yeah, I'm not seeing the point of specifying types for the compiler. Time spent trying to resolve compiler type warnings was and is wasted. I assume that's why everyone says to turn off the type checker and not worry about it. Maybe the documentation should lead with that.

TL;DR Monkey Types can be useful if you know what you're doing. Monkey Types would be more useful if Garmin fixed a few things, and if they had chosen a slightly different design for certain things.

The history of Monkey C and Monkey Types is similar to the history of Javascript and Typescript. In the case of Monkey C and Javascript, both languages were designed to be loosely typed to make it easier for devs (as opposed to Java and C# where types are mandatory everywhere.) This ease of use obviously comes with the tradeoff that it's very easy to have runtime type errors that the compiler can't prevent.

e.g.

function f(x) {
  return 42 + x; // IIRC, this will crash if x is a string, for example
}

Let's say f is called with a value that comes from the (untyped) JSON response to a network request in CIQ. (The response has to be a dictionary, but the dictionary's value types aren't known at compile-time.) There's no way that the compiler can tell whether the call to f will crash or not.

Monkey Types and Typescript both represent the pendulum swinging the other way to where it's possible to specify types for everything and (hypothetically) make your code bullet-proof in terms of run-time type errors. They also represent a compromise where you don't have to specify types when the compiler can infer them (in the case of Monkey Types, you *can't* do so), and you don't have to specify types for everything.

The point of Monkey Types (compile-time type checking for Monkey C), as with Typescript, is that if you "use it correctly", you can actually prevent certain types of run-time type errors (by having the compiler generate an error at compile time.) Monkey Types are not the same thing as Monkey C run-time types, but the former can say something about the latter.

The problem with Monkey Types is it's not yet mature enough (imo) nor is it as well-designed as it could be --  "using it correctly" isn't straightforward in some cases.

Even with Typescript, if you incorrectly use "as" (which is always a cast and never a type declaration), you can circumvent the type checker and allow certain types of runtime errors to slip through the cracks.

Monkey Types exacerbates the weaknesses of a Typescript-ish compile-time type checker by:

- forcing you to use "as" (cast) in common scenarios such as array/dictionary usage (maybe this will be fixed eventually)

- using the same syntax ("as") for type declarations and type casts (because again, type casts are dangerous and should be used sparingly whereas type declarations should be used as often as possible)

- not preventing the dev from casting between 2 unrelated types. (In typescript, "let x = null as Boolean" is an error)

[https://www.typescriptlang.org/play?#code/DYUwLgBAHhC8EDsCuxgQIYGcICED2eo6CA3EA]

Of course, you will note that in the case of external input like a network request, simply specifying the complete complex type of the response in either Monkey Types or Typescript won't guarantee that the actual response fits the specified type. That's one case where run-time type checks such as instanceof or has are still useful and necessary.

andyj713 said:

It's a fundamental rule of programming to move code that always gives the same result independent of the loop and just do it once before entering the loop

No. That's a fundamental rule of optimizing for speed. The primary goal of my optimizer is to optimize for size - which often *also* optimizes for speed, but not always.

In any case, I admit that I was surprised to see it doing that (but after thinking about it, I realize it's exactly what the algorithm is supposed to do). But I can easily add an option to prevent doing single-use copy-prop into the body of a loop, so I'll do that when I get time.

So how does the code you generate relate back to the original code when it comes to things like the stack trace in ciq_log and ERA?   That to me is a bigger issue.

jim_m_58 said:

As I've said before, the best optimizer is located between the chair and keyboard and there is a learning curve for this with CIQ

This is certainly true. Better algorithms will almost always beat better optimizations.

But an enormous amount of work has still gone into many different compilers over the years, and it's not because the compiler writers don't understand this. It's because in many cases there are optimizations that you either can't do at all at the language level; or that would result in unmaintainable code.

Obviously with a source to source compiler the first type isn't relevant (if a source to source optimizer can do it, a human can do it), but readability and maintainability is very important. Making the kind of changes my optimizer makes (or at least, some of them) would lead to horribly unmaintainable code.

And of course, that first one is the reason I added the post build optimizer; I ran up against things that I simply couldn't do at the source level, but which were easy in bytecode (on the other hand, by the time you get to the bytecode, there's no type information, so I still need both optimizers).

jim_m_58 said:

So how does the code you generate relate back to the original code when it comes to things like the stack trace in ciq_log and ERA?   That to me is a bigger issue

Sure, thats one of the downsides. But if you read FlowState's post on this a few replies up, his description of how he thinks it should work is pretty much exactly how it does...

First, you can configure an export task that generates the source code anywhere you like (by default it goes in the bin directory, and isn't expected to be preserved). So you just add an exports directory to your project, and commit the results along with the rest of your source code as part of your release process.

Second, if you install a specific version of @markw65/monkeyc-optimizer in your project, the extension will use that, rather than the one that's included in the extension. As long as you commit your package-lock.json along with the rest of your sources that means you can recreate the original build just by checking out the release, re-running "npm install" and re-building your project.

So yes, era will point to the optimized source. But its easy to ensure that you keep a copy of that; and it's relatively easy to ensure that you can recreate it exactly.

But this isn't part of a compiler.  It generates different code that's sent to the compiler. The post mod of bytecodes scares me more, as the debug.xml may no longer even reflect what's in the modified bytecodes.

This is why the original code should be sent to the compiler, but things can be noted by the extension which "the optimizer between chair and keyboard" can make if appropriate

This makes things very complex, especially for new users.

so if the stack trace points to line 100 (in the modified source) how do you find what line that is in the original source? An example would help.

markw65 said:

The primary goal of my optimizer is to optimize for size - which often *also* optimizes for speed, but not alway

Since we are constrained on both memory and number of instructions we can execute in one call to onUpdate / onPartialUpdate and probably a few others, optimizing should target both goals. Saving a few bytes for a few thousand opcode executions is not likely to be a good trade-off.