-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
operator overloading (for vectors to start with, probably for colors too) #248
Comments
I was thinking about related stuff today actually; I'm toying with the idea of receiving skeletal data from kinect via OSC for use in LCL, and it would be annoying to not be able to at least use coordinates as vectors, even without operator overloading. But operator overloading would definitely be good and your reasoning about how to implement seems fairly sound. |
so my initial reaction to overloading was somewhat hesitant, but actually I think that it would be very possible to have it work in a sane fashion. reading the paper.js stuff, it seems like the system they've got is reminiscent of haskells type classes. it's a bit more awkward in a language without strong typing, but I think it's the sanest way to do this kind of stuff I've seen. In short, yeah I'm all for this. I think there's a fair bit of stuff we need to do around defining the language and how things should work, but I think it's all good stuff. |
yes indeed there is a potential rabbit hole here. If we really did this properly, we wouldn't just support |
Just to map out other parts of the potential rabbit hole, quaternions could also be useful. |
Matlab could be a good example of some notations we may be shooting for:
As for quaternions, in theory if we support matrixes and complex numbers then we can support calculations on quaternions just fine, but declaring quaternions in matrix form doesn't look right at all. So for other notations:
Are there other sw environments that have other notable notations for quaternions? |
Translations should be able to take a vector as an argument. rotations too should take a vector (and an angle).
The current notation is the Processing one, which knows nothing about vectors, as we do for example
which in a way seems a little limited. We should rather be able to do use arrays for vectors like so
So we should be able to overload '+' and '*' (and others) to make sense of vectors that way.
This overloading thing is a classic topic in Javascript (as in: everybody wants it but it's not really a language feature), BUT it can be done and the best way I've seen it done is in paper.js, where it's handled like so: http://scratchdisk.com/posts/operator-overloading
The coffeescript library that we already use does allow us to get the AST, traverse it to do the required changes, then emit the compiled code. With a bit of luck the parsing/compiling stages of coffeescript should amount to the same work that it does now (only we do it in one pass now), and the visiting of a few lines of code should amount to a visit of a few nodes and I'd hope it to be really be quick.
(Also consider that the current regex transformation stage can be wildly streamlined, I didn't even seriously try).
Once this works, this would open up operations on Colors for example, and potentially some of the current regex transformations could be migrated to be AST operations.
I'd expect this to be OK in @rumblesan 's branch as he works on solid ASTs to start with, so whatever we do on the main branch should be even more "legit" in his branch.
The text was updated successfully, but these errors were encountered: