The Sparrow language

[Lucian Radu Teodorescu via Digitalmars-d]

On Wednesday, 6 April 2016 at 14:54:18 UTC, Puming wrote:
> On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei Alexandrescu 
> wrote:
>> I just got word about Sparrow (from its creator no less):
>>
>> presentation_offline_Sparrow.pdf - https://db.tt/m2WwpxIY
>> Speak.mp4 - https://db.tt/RDmrlEu7
>> ThesisLucTeo.pdf - https://db.tt/1ylGHuc1
>>
>> An interesting language that shares a lot of D's vision and 
>> features. The languages differ in a few aspects: Sparrow has a 
>> much more flexible syntax allowing a variety of custom 
>> operators. (I happen to disagree that's a good thing as I 
>> believe highly flexible syntax easily leads to transmission 
>> noise code). On the plus side Sparrow has a smoother 
>> integration of compile-time vs. run-time computation, which 
>> makes it a bit easier to transition from one to another. 
>> Another feature we could consider adding to D is a simple 
>> definition of concepts as complex Boolean predicates. That's 
>> essentially identical to isForwardRange etc. etc. but makes 
>> for simpler use of these predicates.
>>
>>
>> Andrei
>
> Interesting. I've thinking about concepts too. Hopefully they 
> could come into D. Actually, I think concept and interfaces 
> could be combined into one feature. An interface is just a 
> special case of a concept, saying its implementer should have 
> the matching function signatures.

In my opinion implementing concepts in terms of interfaces is 
more restrictive than implementing them as boolean predicates. 
You cannot create interfaces based on existence of attributes, on 
existence of dependent types or on the existence of extern 
function that apply to your types. Moreover, you cannot create 
concepts based on the compile-time values associated with your 
type.

One basic example, from C++, is that you cannot create a concept 
that distinguishes between vector<int> and vector<bool>, as they 
theoretically should have the same interface.

The main uses of concepts are in my view most of the time related 
to dependent types. I would like to have an InputRange concept 
that will also tell me the type of the elements I can read from 
it.

Implementing concepts as predicates, give you much more freedom. 
I would argue that you can represent many more concepts with 
predicates. Not only you can represent all the "has-a" relations, 
but you can also place conditions on the compile-time values that 
your types might have, and how that class may be used.

My two cents,
LucTeo