[BUGFIX] Fix map comprehension only working with Int keys

[NotHyper-474]

Description

The way map comprehension was recently implemented completely disregards the type the Map may have on runtime, as the way it directly calls makeMap will always cause the generated Map to be an IntMap. This is the exact reason I said a typer should be implemented first.

So, after being disgruntled at my suggestion having absolutely no consideration put into it, I decided to spend some hours fixing the jank by replacing with a different jank: a hacky fix.
Basically, we hijack the map comprehension body, manually initializing the temporary _g variable with an object that intercepts the generated set calls to populate arrays of keys and values, then finally we copy the result over to a Map with the correspondent type.

Screenshots

(Note: the __name__ is exclusive to HashLink and I used it 'cause I was lazy to type Type.getClassName(Type.getClass(...)).)

[nykwono]

So, after being disgruntled at my suggestion having absolutely no consideration put into it, I decided to spend some hours fixing the jank by replacing with a different jank: a hacky fix.

That was lowkey my bad I apologize🥀 as when I implemented it it was working fine with me and figured it would ALWAYS return to be an IMap<Dynamic, Dynamic> at the least which I hadn't really figured to why it wouldn't with makeMap?

Though I will say I feel as if your implementation may be a bit, TOO hacky, as it's checking specifically for the expression count which we can't always make sure is 3 (EParent 😬), I feel like maybe re-implementing the comprehension that accounts more for the entries that are provided would be a better solution, no?

[NotHyper-474]

I feel like maybe re-implementing the comprehension that accounts more for the entries that are provided would be a better solution, no?

Care to elaborate?

[nykwono]

I feel like maybe re-implementing the comprehension that accounts more for the entries that are provided would be a better solution, no?

Care to elaborate?

Well, since we know explicitly from the parser that we're dealing with a map/array comprehension. I feel like we could use that to easily make a new Expr enum field that defines the properties for said Map/Array comprehension. This could also help with a bit of psuedo-typing with Arrays as well if im not mistaken 🤔

[NotHyper-474]

Well, since we know explicitly from the parser that we're dealing with a map/array comprehension. I feel like we could use that to easily make a new Expr enum field that defines the properties for said Map/Array comprehension. This could also help with a bit of psuedo-typing with Arrays as well if im not mistaken 🤔

So... with that the Parser would just tell to the Interpreter if the comprehension is either a Map or Array one, then it would populate it? I'm not sure I follow.

[nykwono]

Well, since we know explicitly from the parser that we're dealing with a map/array comprehension. I feel like we could use that to easily make a new Expr enum field that defines the properties for said Map/Array comprehension. This could also help with a bit of psuedo-typing with Arrays as well if im not mistaken 🤔

So... with that the Parser would just tell to the Interpreter if the comprehension is either a Map or Array one, then it would populate it? I'm not sure I follow.

Yes, the parser already tells you whether its a Map or Array compr thanks to the _a & _g, I feel like you could use this to your advantage to then have a new expr to then make initialize a array/map comprehension instead if that makes sense.

[NotHyper-474]

After trying to implement it via a new AST/Expr node, I realized I'd have to somehow turn it back into the original code in the Printer because script merging would rely on it, and so I gave up 'cause that's a can of worms I'd rather not open.

So the only change I did was remove the specific block expr length check. Maybe I'm too stupid to make a proper implementation.

[NotHyper-474]

...I think I have an idea, though it'll have to wait.

[nykwono]

...I think I have an idea, though it'll have to wait.

I think you'll cook, I trust you hard brother ❤️🙏