The Sparrow language

[Lucian Radu Teodorescu via Digitalmars-d]

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

> - 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. For numbers and strings, this is easily 
doable by just copying the bits. But what do you do with vectors 
of vectors? You cannot simply copy the bits; mainly because you 
don't know what bits are to be copied. The compiler tries to 
generate a default ctorFromCt for all your data structures by 
recursing down, similar to what a compiler does to a copy 
constructor. However, for pointers this cannot be done; the user 
needs to provide its own ctorFromCt. Please also see section 
10.3.2 from the thesis, for a discussion about cases you would 
want to use user-defined ctorFromCt to speed up compilation.

The reason I say that this is an advanced concept is that 
typically the programmer doesn't thing of such things in the 
daily routine. But once you start working with complex structures 
compile-time it comes as a natural concept.

> - 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. 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'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?", 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."

> - 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. Word of caution if you plan to abuse it.

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

> - Overloading based on constants.

I actually find this a strength of the language. Types are just 
another kind of compile-time values.

> Compile-time parsers with meaningful error messages for DSLs 
> should probably also be supported at some point.

I would like to see this feature in D as well. At this point I'm 
not sure how clean would the implementation be if there are no 
"side-effects" allowed in CTFE.