Dear all,
I am a strong believer in the value generated by unit-tests. We programmers are not as great as we would like to be. We introduce subtle bugs everywhere (if not obvious ones), we make a lot of copy-paste errors, we make a lot of bad-replace errors, and we claim to understand the code much more than we actually do. Not to mention the fact that our memory is not as good as we think it is; when we don't make mistakes, we simply don't fully understand the code, even our code. Our mind is not that ...
Read More →
I am a strong believer in the value generated by unit-tests. We programmers are not as great as we would like to be. We introduce subtle bugs everywhere (if not obvious ones), we make a lot of copy-paste errors, we make a lot of bad-replace errors, and we claim to understand the code much more than we actually do. Not to mention the fact that our memory is not as good as we think it is; when we don't make mistakes, we simply don't fully understand the code, even our code. Our mind is not that ...
I finally finalized the blog post with the proposed design of the new Sparrow type system. It is still high-level, but I wanted to make sure we have enough understanding of the main features that the design proposes.
Here it is: http://lucteo.ro/2018/07/08/designing-Sparrow-type-system/
Any feedback is welcomed!
Read More →
Here it is: http://lucteo.ro/2018/07/08/designing-Sparrow-type-system/
Any feedback is welcomed!
I'm currently focusing on redesigning the Sparrow type system. It's currently too simple.
Based on the low-level analysis I've made for C++ (http://lucteo.ro/2018/06/17/beyond-the-type-system/), I'm trying to analyze the desired features of the Sparrow type system, and how we can achieve that in the simples way.
Currently, the list of goals are:
Read More →
Based on the low-level analysis I've made for C++ (http://lucteo.ro/2018/06/17/beyond-the-type-system/), I'm trying to analyze the desired features of the Sparrow type system, and how we can achieve that in the simples way.
Currently, the list of goals are:
- have proper support for immutability; if possible immutability by default
- allow safe const reference passing for input parameters, preferably, without the user needing to type too much
- simpler and safer rules for lifetime of objects passed as parameters
- support ...
I just merged to master the feature branch that implements the dot operator. This feature was planned a while ago, and it got pushed around for some time. It is intended to simplify the handling of some type wrappers.
The problem
Imagine a simple pointer class:
Each time the user would want to use this, the code would look something similar to:
Read More →
The problem
Imagine a simple pointer class:
1 2 3 4 5 6 7 8 9 | package A
[initCtor]
datatype Ptr(type: Type)
using ValueType = type
_ptr: @ValueType
[protected]
fun get(this: Ptr) = _ptr
|
Each time the user would want to use this, the code would look something similar to:
1 2 3 4 5 6 7 8 9 10 11 ... |