I'm still working on the type system. But I find multiple ways of procrastinating. One of them is my work on 'bitcopiable'. And, as this is a good feature, I'm going to drop a few words here about it
The problem
Objects can be self-referentiable. That is, an object, can have a pointer, directly or indirectly to itself. One of the best examples is a node in a circular linked list. The content of the node will contain a pointer that will point to the node itself.
Another example, relatively common, is the following:
Read More →
The problem
Objects can be self-referentiable. That is, an object, can have a pointer, directly or indirectly to itself. One of the best examples is a node in a circular linked list. The content of the node will contain a pointer that will point to the node itself.
Another example, relatively common, is the following:
1 2 3 4 5 ... |
Over the holidays there was a big debate on compilation time in the C++ community. It started with a blog post by Aras Pranckevičius: "Modern" C++ Lamentations. The post picks on the Standard Ranges by Eric Niebler, that shows how you would implement Pythagorean Triples with Ranges, a new addition to C++20 standard.
At the heart of Aras' argument was the following two facts:
At the heart of Aras' argument was the following two facts:
- the range-based Pythagorean Triples is much longer and more complex than a simple C-style implementation
- compilation time increases from 0.071s to 3.02s (when going from C-style to range-based implementation -- that is 42 times slower ...
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, some ... 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, some ... Read More →
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 back a bit, I realize that:
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 back a bit, I realize that:
- I don't ...
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 powerful to ... 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 powerful to ... Read More →
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! Read More →
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:
Expected first ... 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 move semantics
- support forwarding pass semantics
Expected first ... Read More →
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 ... |