First, the slow part:
There is little you can do for the first bullet point. Therefore, I'll focus on the other two bullet points.
Before starting the type system work, Sparrow had zero unit-tests. With this effort, I was convinced that we need unit-tests to make considerable progress in Sparrow. That took a lot of work, but it's starting to show signs that it pays off. I have now ...
Read More →
- personal problems for the last two months -- life is hard
- changing the type system is slightly harder than I originally thought
- adding unit tests & refactoring along the way
There is little you can do for the first bullet point. Therefore, I'll focus on the other two bullet points.
Before starting the type system work, Sparrow had zero unit-tests. With this effort, I was convinced that we need unit-tests to make considerable progress in Sparrow. That took a lot of work, but it's starting to show signs that it pays off. I have now ...
For some time now I've started to change the type system of Sparrow. I wanted to add immutability as a first-choice instead of the current "everything is mutable". For more details see: http://lucteo.ro/2018/07/08/designing-Sparrow-type-system/
The problem is that I'm moving too slow. It takes me a long time to make changes that can be seen as minor. I make one change here which seems good, and immediately I find errors in some other part. I fix that error, and a new error appear. It feels like going in circles. Actually, it I step ...
Read More →
The problem is that I'm moving too slow. It takes me a long time to make changes that can be seen as minor. I make one change here which seems good, and immediately I find errors in some other part. I fix that error, and a new error appear. It feels like going in circles. Actually, it I step ...
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 ... |