On 9/20/12 10:16 AM, deadalnix wrote:
> What is Sininimp-Mulinint object-oriented style ?

Single inheritance of implementation, multiple inheritance of interface.

Andrei

On 9/20/12 11:06 AM, David Nadlinger wrote:
> Bummer that they didn't hold the event in Zurich – maybe I would have
> managed to sneak in… ;)
>
> On Thursday, 20 September 2012 at 12:56:44 UTC, Andrei Alexandrescu wrote:
>> http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf
>>
>
> The code on slide 6 contains an issue resp. inaccuracy: Not all random
> access ranges are sliceable. Sometimes I wonder (and this is not at all
> intended as a snide remark!) if it is too easy to make mistakes
> regarding template constraints, if even you as the (co-?) designer of
> std.range get them wrong occasionally.

In fairness, this issue is in the air at this time. We're still mulling over on characterizing infinite ranges that offer random access.

Andrei

On 9/20/12 6:03 PM, renoX wrote:
> Thank for these slides.
>
> I didn't get some part of the VRP slides: p40 of the third lesson:
> byte a, b, c;
> a = 1;
> b = c | a; // error
> Is-this really an error? A binary-or operation on bytes should return a
> byte..
>
> BR,
> renoX

Yes, it's a bug in the slides. Thanks! A correct example would be:

byte a, b;
int c = 1;
b = c | a;


Andrei

On Friday, 21 September 2012 at 04:56:04 UTC, Andrei Alexandrescu wrote:
> On 9/20/12 6:03 PM, renoX wrote:
>> Thank for these slides.
>>
>> I didn't get some part of the VRP slides: p40 of the third lesson:
>> byte a, b, c;
>> a = 1;
>> b = c | a; // error
>> Is-this really an error? A binary-or operation on bytes should return a
>> byte..
>>
>> BR,
>> renoX
>
> Yes, it's a bug in the slides. Thanks! A correct example would be:
>
> byte a, b;
> int c = 1;
> b = c | a;
>
>
> Andrei


Ah, I understand better now.

Thanks for your reply.

BR,
renoX

On Fri, 21 Sep 2012 05:58:21 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 9/20/12 10:06 AM, Simen Kjaeraas wrote:
>> Cool. And now the inevitable: Will there be video?
>
> No video was taken.
>
> Andrei

*sadface*

-- 
Simen

On 21-Sep-12 03:27, Timon Gehr wrote:
> On 09/21/2012 12:51 AM, bearophile wrote:
>> Timon Gehr:
>>
>>> chain has type Result. dynRange takes an arbitrary range and transforms
>>> it into a range with the same value/vs reference behaviour whose static
>>> type depends only on the element type.
>>
>> I see. So that chain() is the normal chain of Phobos :-)
>>
>
> Exactly.
>
>> (But is DynRange a lazy stream/sequence? This is the most important
>> thing, because creating an eager linked list is kind of easy already,
>> and misses the main point of my "request".)
>>
>> Bye,
>> bearophile
>
> Proof of concept:
>
> import std.range, std.algorithm;
> struct DynRange(T){
>      @property T front(){ return frontImpl(); }
>      @property bool empty(){ return emptyImpl(); }
>      void popFront(){
>          auto u = popFrontImpl();
>          frontImpl = u.frontImpl;
>          emptyImpl = u.emptyImpl;
>          popFrontImpl = u.popFrontImpl;
>      }
> private:
>      T delegate() frontImpl;
>      bool delegate() emptyImpl;
>      DynRange!T delegate() popFrontImpl;
> }
> DynRange!(ElementType!R) dynRange(R)(R range)if(isInputRange!R){
>      DynRange!(ElementType!R) result;
>      result.frontImpl = ()=>range.front;
>      result.emptyImpl = ()=>range.empty;
>      result.popFrontImpl = (){
>          auto newRange = range;
>          newRange.popFront();
>          return dynRange(newRange);
>      };
>      return result;
> }
>
> void main(){
>      auto r = iota(0,10).dynRange;
>      auto t = [1,2,3,4,5].dynRange;
>      import std.stdio;
>      writeln(r,r,t,t);
> }
>
> To allow the definition of recursive lazy ranges, we'd also need
> a facility to 'delay' computation. I'll post a proof of concept
> tomorrow, by implementing eg. a lazy prime sieve.

I swear I've seen it somewhere in Phobos:
http://dlang.org/phobos/std_range.html#InputRangeObject
and friends. Maybe we ought to lay a better infrastructure for it.

-- 
Dmitry Olshansky

On 09/21/2012 07:46 PM, Dmitry Olshansky wrote:
> On 21-Sep-12 03:27, Timon Gehr wrote:
>> On 09/21/2012 12:51 AM, bearophile wrote:
>>> Timon Gehr:
>>>
>>>> chain has type Result. dynRange takes an arbitrary range and transforms
>>>> it into a range with the same value/vs reference behaviour whose static
>>>> type depends only on the element type.
>>>
>>> I see. So that chain() is the normal chain of Phobos :-)
>>>
>>
>> Exactly.
>>
>>> (But is DynRange a lazy stream/sequence? This is the most important
>>> thing, because creating an eager linked list is kind of easy already,
>>> and misses the main point of my "request".)
>>>
>>> Bye,
>>> bearophile
>>
>> Proof of concept:
>>
>> import std.range, std.algorithm;
>> struct DynRange(T){
>>      @property T front(){ return frontImpl(); }
>>      @property bool empty(){ return emptyImpl(); }
>>      void popFront(){
>>          auto u = popFrontImpl();
>>          frontImpl = u.frontImpl;
>>          emptyImpl = u.emptyImpl;
>>          popFrontImpl = u.popFrontImpl;
>>      }
>> private:
>>      T delegate() frontImpl;
>>      bool delegate() emptyImpl;
>>      DynRange!T delegate() popFrontImpl;
>> }
>> DynRange!(ElementType!R) dynRange(R)(R range)if(isInputRange!R){
>>      DynRange!(ElementType!R) result;
>>      result.frontImpl = ()=>range.front;
>>      result.emptyImpl = ()=>range.empty;
>>      result.popFrontImpl = (){
>>          auto newRange = range;
>>          newRange.popFront();
>>          return dynRange(newRange);
>>      };
>>      return result;
>> }
>>
>> void main(){
>>      auto r = iota(0,10).dynRange;
>>      auto t = [1,2,3,4,5].dynRange;
>>      import std.stdio;
>>      writeln(r,r,t,t);
>> }
>>
>> To allow the definition of recursive lazy ranges, we'd also need
>> a facility to 'delay' computation. I'll post a proof of concept
>> tomorrow, by implementing eg. a lazy prime sieve.
>
> I swear I've seen it somewhere in Phobos:
> http://dlang.org/phobos/std_range.html#InputRangeObject
> and friends. Maybe we ought to lay a better infrastructure for it.
>

(Assuming you relate to the range part, and not the delay part.)
I am aware of that. That one is unusable in its current state.

import std.range;
void main(){
    auto r = iota(0,10).inputRangeObject;
    auto t = [1,2,3,4,5].inputRangeObject;
    import std.stdio;
    writeln(r,r,t,t); // [0,1,2,3,4,5,6,7,8,9][][1,2,3,4,5][]
}

Yes, I could use 'save' everywhere, but I really do not want to. The
'dynamic' range should behave the same as the one exposing the full
static type. It shouldn't be made so easy to make aliasing-related
errors.