September 21, 2012 Re: Slides from LASER 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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
|
September 21, 2012 Re: Slides from LASER 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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
|
September 21, 2012 Re: Slides from LASER 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to renoX | 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
|
September 21, 2012 Re: Slides from LASER 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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
|
September 21, 2012 Re: Slides from LASER 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
September 21, 2012 Re: Slides from LASER 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 |
September 21, 2012 Re: Slides from LASER 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. |
Copyright © 1999-2021 by the D Language Foundation