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 ... |