You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes I want to experiment with new ideas that would break the language, but I do not want to write a new runtime from scratch. For example, when working on Higher Order Operator Overloading (link: https://github.com/advancedresearch/path_semantics/blob/master/sequences.md#higher-order-operator-overloading), I figured out that it got very complex when implementing it for Dyon, but it got better when implementing it for a simpler language designed for theorem proving, which gave me some new insights.
You have to work on languages that are complex enough to be useful, but at the same time you want some control over the complexity.
For example:
there could be a static type checking experiment
testing how Dyon would be like with extended types
different way of evaluating programs
domain specific languages, e.g. for image processing, parallel computing or shaders
I also believe that refactoring can make the runtime code more readable.
Also, the compile times of Dyon is pretty high. By moving a lot of the complexity into a core library, the compile times might be reduced when working on Dyon.
The text was updated successfully, but these errors were encountered:
Starting PR: #628
Sometimes I want to experiment with new ideas that would break the language, but I do not want to write a new runtime from scratch. For example, when working on Higher Order Operator Overloading (link: https://github.com/advancedresearch/path_semantics/blob/master/sequences.md#higher-order-operator-overloading), I figured out that it got very complex when implementing it for Dyon, but it got better when implementing it for a simpler language designed for theorem proving, which gave me some new insights.
You have to work on languages that are complex enough to be useful, but at the same time you want some control over the complexity.
For example:
I also believe that refactoring can make the runtime code more readable.
Also, the compile times of Dyon is pretty high. By moving a lot of the complexity into a core library, the compile times might be reduced when working on Dyon.
The text was updated successfully, but these errors were encountered: