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

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.

On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei Alexandrescu wrote:
> 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.

Anyway it's a new level of type system. Does D still accept new features of such complexity?

On Wednesday, 6 April 2016 at 16:56:17 UTC, Kagamin wrote:
> On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei Alexandrescu wrote:
> Anyway it's a new level of type system. Does D still accept new features of such complexity?

D3?

On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei Alexandrescu wrote:
> 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.

Aside from the explicit annotations, I don't see how their solution is more flexible than D's CTFE, but I might be missing something.

What I think could be really interesting is a unification of functions and templates. Template argument inference aside, a template is basically just a memoized pure function that can take types as arguments and/or return them. It would be interesting to have a language that uses CTFE as its only "template" mechanism.

On Wednesday, 6 April 2016 at 18:25:11 UTC, BLM768 wrote:
>
> Aside from the explicit annotations, I don't see how their solution is more flexible than D's CTFE, but I might be missing something.

Never mind. Just saw their language embedding example. Neat!

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

On Wednesday, 6 April 2016 at 18:27:25 UTC, BLM768 wrote:
> On Wednesday, 6 April 2016 at 18:25:11 UTC, BLM768 wrote:
>>
>> Aside from the explicit annotations, I don't see how their solution is more flexible than D's CTFE, but I might be missing something.
>
> Never mind. Just saw their language embedding example. Neat!

Compared to CTFE, in Sparrow you can run at compile-time *any* algorithm you like. No restrictions apply. Not only you can do whatever your run-time code can do, but can also call external programs at compile-time.

Imagine that you are calling the D compiler from inside the Sparrow compiler to compile some D code that you encounter.

On Wednesday, 6 April 2016 at 20:48:20 UTC, Lucian Radu Teodorescu wrote:
> On Wednesday, 6 April 2016 at 18:27:25 UTC, BLM768 wrote:
>> On Wednesday, 6 April 2016 at 18:25:11 UTC, BLM768 wrote:
>>>
>>> Aside from the explicit annotations, I don't see how their solution is more flexible than D's CTFE, but I might be missing something.
>>
>> Never mind. Just saw their language embedding example. Neat!
>
> Compared to CTFE, in Sparrow you can run at compile-time *any* algorithm you like. No restrictions apply. Not only you can do whatever your run-time code can do, but can also call external programs at compile-time.
>
> Imagine that you are calling the D compiler from inside the Sparrow compiler to compile some D code that you encounter.

Wow, could be dangerous to compile source code.

On Wednesday, 6 April 2016 at 20:48:20 UTC, Lucian Radu Teodorescu wrote:
> Compared to CTFE, in Sparrow you can run at compile-time *any* algorithm you like. No restrictions apply. Not only you can do whatever your run-time code can do, but can also call external programs at compile-time.
>
> Imagine that you are calling the D compiler from inside the Sparrow compiler to compile some D code that you encounter.

Interesting. I guess that's why you'd have annotations on variables that are set at compile time; without those annotations, there would be no way to tell when the value is calculated, and with non-pure functions, that becomes important. In a way, requiring annotations is almost more elegant than requiring functional purity...