The Sparrow language

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Sun Apr 10 04:00:56 PDT 2016


On 10.04.2016 12:01, Lucian Radu Teodorescu wrote:
> On Wednesday, 6 April 2016 at 21:42:31 UTC, Timon Gehr wrote:
>> The sum of squares of odd fibonacci numbers example is...
>> unconvincing. It is inefficient and incorrect.
>
> How would you do it?
> The Fibonacci example isn't very complex, but the idea was to go from
> really-simple examples to more complex examples.
>
>> - He wrongly claims that dynamic memory allocation is disallowed in D
>> during CTFE, dismissing it immediately.
>
> Unfortunately I'm not a D expert, so I cannot argue with you.

Sure, but note that D is among the most closely related works to yours.

> I remember
> I read somewhere that dynamic memory allocation is disallowed in D at
> compile-time. And it makes sense if you think that global variablles
> cannot be accessed during CTFE, and that functions need to be "free of
> side-effects". I have a hard time imagining how an allocator would work
> on these conditions. How does D implement the memory allocation at
> compile-time?
> ...

There's a heap at compile time, so one can use constructs that allocate 
heap memory. (Except closures, which are not currently supported at 
compile time by the reference implementation.)

import std.range, std.algorithm, std.array, std.conv;
class C{
     int x;
     this(int x)in{assert(__ctfe);}body{ // (contract for illustration)
         this.x=x;
     }
     override string toString(){ return text("C(",x,")"); }
}

auto x=[new C(1),new C(3),new C(4)]~iota(6).map!(x=>new C(x)).array; // 
run at compile time, multiple heap allocations

void main(){
     import std.stdio;
     writeln(x); // use at run time
}


>> - Concepts such as ctorFromCt are not discussed sufficiently well.
>
> Although I discussed them several times in the thesis, I might have been
> less convincing than I wanted to.
>
> The concept of ctorFromCt is a little bit of advanced concept, but the
> idea behind it is pretty simple. If you have arbitrarily complex data
> structures, you cannot simply move them from compile-time to run-time.

In D, the transformation is done by the compiler. (In the cases that 
have been implemented so far. Unfortunately, the reference 
implementation does not currently support moving some kinds of mutable 
data to run time). What is an example where I would want to use a custom 
ctorFromCt?

> ...
>> - No discussion of of out-of-bounds vector accesses. It seems that the
>> compiler implementation might allow UB during compile time?
>
> There should be no distinction between out-of-bounds as compile-time at
> out-of-bounds at
> run-time. With that said, I must admit that out-of-bounds are not
> handled properly by the compiler at this point.

Which means that the benchmarks might report slightly optimistic times.

> I was assuming the
> presence of exceptions, but I never get around to implement exceptions;
> it's a feature so popular these days, that I don't think that I can have
> something different there.
>
> The purpose of the compiler and the language as they are now was to
> prove that we can build a language on the three fundamental goals:
> flexibility, efficiency and naturalness.

I think this is an example of a trade-off between efficiency and 
naturalness.

> I've answered the question "is
> such a language possible?" If you would like me to answer to the
> question of "can I use such a language in commercial applications?",...

(That is not what I was asking.)

> I would say "not yet, but I'm confident that with some work, and a little
> bit of luck, it would be a great language to be used in commercial
> applications."
> ...

Nondeterminism in the build process might be a deal-breaker for some.

>> - I haven't found anything about modules, forward references or
>> ordering of compile-time computations (which can have externally
>> observable effects).
>
> Modules is very high on my TODOs (and pains) lists. Any help is greatly
> appreciated :)
>
> Forward references are implemented by allowing the compiler to traverse
> your source code non-linearly.
>
> Ordering of compile-time computations is entirely implementation
> defined.

The design of CTFE in D is such that ordering of compile-time 
computations does not matter. (Except where it is forced to be a certain 
way by data dependencies.)

> Word of caution if you plan to abuse it.
>

I.e., your stance on accidents based on unclean language semantics is 
that they are the fault of the user?

>> - No array literal enum mess.
>
> As I said, the language is yet a proof-of-concept. I would like to have
> these implemented as library features instead of a compiler-feature.
> ...

I was referring to a specific weakness of D here, e.g.:

import std.range, std.algorithm, std.array, std.conv;
class C{
     int x;
     this(int x)immutable in{assert(__ctfe);}body{
         this.x=x;
     }
     override string toString(){ return text("C(",x,")"); }
}

immutable x=[new immutable(C)(1),new immutable(C)(3),new 
immutable(C)(4)]~iota(6).map!(x=>new immutable(C)(x)).array;
auto y=x;

void main(){
     import std.stdio;
     writeln(x is y); // false
}

What would be a similar code snippet in Sparrow, and what does it do?

>> - Overloading based on constants.
>
> I actually find this a strength of the language.

I don't consider it a weakness. (Although, one drawback is that it is 
easy to accidentally block partial evaluation during subsequent edits, 
leading to performance regressions.)

> Types are just another kind of compile-time values.
>

Do you support custom computations on types?


More information about the Digitalmars-d mailing list