Big update to prettier-extension-monkeyc

flocsy🤠 said:

but the Dictionary.get does return null if the key is not in the dictionary

Yes. I'll try to get a fix for this and the Char comparison issue out in the next day or so.

Actually there's another bug (from the end-user's perspective) in this code, though not many users will find it:

The pmc-analysis assumes that value.weak() returns WeakReference and thus doesn't complain that I add it to the Dictionary<Symbol, WeakReference>. Since that is what is written incorrectly in the documentation, I might imagine that it's also incorrect in the mir files? Anyway, I don't know if you have a way to override this if it's indeed a bad mir file, but the reality is (if you read the documentation Note, not only the Returns) it returns... well, it's complicated... WeakReference or Any is not a bad guess, and I think it's good enough for pmc-analysis (in theory Any could be a bit narrowed down to the immutable types)

Another bug, this time in the monkey.jungle parser. I noticed today that the syntax higlighting and especially the click and go to usage / definition stopped working. I realized now that it's because of a variable I introduced in my monkey.jungle:

DEFAULT_LANG=hun
base.sourcePath = source;gen/$(DEFAULT_LANG)/source;lang/$(DEFAULT_LANG)/source
base.resourcePath = resources;gen/$(DEFAULT_LANG)/resources

It both puts a red error on the $ in the jungle file, and it causes the other things not to work either,

I realized that one of the "classic" optimizations you could do (either in code or byte-code) is to replace container.get(k) with container[k], and container.put(k, v) with container[k] = v

I am surprised this is not done yet. (also strange that the 2 create different bytecodes in the Garmin compiler)

flocsy🤠 said:

eplace container.get(k) with container[k], and container.put(k, v) with container[k] = v

Does this work if the keys don't already exist? The long form is "new" key safe for sure, I remember (maybe incorrectly) that the short form doesn't behave well in that case.

flocsy🤠 said:

I am surprised this is not done yet. (also strange that the 2 create different bytecodes in the Garmin compiler)

Remember that Garmin's compiler doesn't really optimize based on type knowledge. So it generates the same code whether the type checker is enabled or not. Given that, it has no way to do this optimization.

But even if it did, they're not necessarily equivalent. Suppose I extend Dictionary with my own class that overrides put, and then pass a MyDictionary object to a function that takes a Dictionary. If I change d.put(foo, bar) into d[foo]=bar it won't call my override. In fact, I just tried this, and the d[foo]=bar syntax doesn't work on a user defined class that extends Dictionary (it crashes), but put does.

Yes, container[k] is null if container is a dictionary, and it doesn't contain k.

I didn't think about inheritance. I thought (at the beginning) that [] is a syntactic sugar for get, put. I still don't understand though what is the difference when there's no inheritance, just simple Dictionary or array, and even more so: Garmin please add this to the documentation of Dictionary and Array, please.

And for the optimizer: since you do know about the type, I think it's worth to try optimize it, it's a relatively big gain (8, 9 bytes)

I found some old code in github and trying to adjust it for strict typecheck. I run into the following interesting issue:

original code:

    function foo() {
        longPressTimer = new Timer.Timer();
        longPressTimer.start( method(:onNextPage), LONG_PRESS_UPDATE_FREQUENCY, true );
    }

    function onNextPage() {
        return true;
    }

added types:

    function foo() as Void {
        longPressTimer = new Timer.Timer();
        longPressTimer.start( method(:onNextPage) as Method() as Void, LONG_PRESS_UPDATE_FREQUENCY, true );
    }

    function onNextPage() as Boolean {
        return true;
    }

And I get the following warning, which is true, but I'm not sure what to do with it:

The type Method() as Boolean cannot be converted to Method() as Null because they have nothing in common [pmc-analysis]

On one hand the original code worked, the new code works, so I tend to think that this is a very specific case and the pmc-analyzer could be adjusted to let this.

On the other hand, I don't know if it's always OK. What if the "bytecode" thinks that there is no return value, and thus doesn't remove the return value from the stack so it's left there?