Replies: 1 comment
-
|
I have decided against vectors for now. Nothing prevents them from being added later. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
In the initial Mindcode grammar, there was a place for vectors:
(x, y). With vectors, it is easier to manage coordinates, as we don't have to manually manage both parts of the vector. Instead of:we could write something like:
@schittli, in #9, reported that many functions weren't implemented yet, including
lenandanglevector functions. I wonder if this is a great time to implement vector operations. I was thinking of similar to this:The above would convert into something equivalent to:
Given the above, we could also implement
lenandangleusing:The purpose of adding vectors, and the associated additional complexity in the language and implementation, is be to reduce the number of arguments to function calls, and to make developer's lives easier. Of course, adding vectors means that Mindcode doesn't map 1:1 with Mindustry Logic anymore, and would need more documentation. It's not like Mindustry Logic has tons of documentation, but still... it's more work on our end.
In addition, adding vectors means Mindcode needs to become a typed language. At the moment, Mindcode doesn't really care about types. Mindustry Logic handles everything on its own. Adding vectors means we need to track types, so that the Logic generation code knows to use vectors in one case, and plain old numeric operations in the next.
@ByMartrixx, @schittli, what do you think? Can you think of something that vectors enable that can't be done currently, or would be very awkward to implement right now? If you can find a couple of examples, I would start work on tracking types and implementing vectors.
Thanks, and have a great day!
Beta Was this translation helpful? Give feedback.
All reactions