On 11/14/2012 06:43 PM, Andrei Alexandrescu wrote:
> On 11/14/12 7:29 AM, H. S. Teoh wrote:
>> But since this isn't going to be fixed properly, then the only solution
>> left is to arbitrarily declare transient ranges as not ranges (even
>> though the concept of ranges itself has no such implication, and many
>> algorithms don't even need such assumptions), and move on. We will just
>> have to put up with an inferior implementation of std.algorithm and
>> duplicate code when one*does*  need to work with transient ranges. It is
>> not a big loss anyway, since one can simply implement one's own library
>> to deal with this issue properly.
>
> What is your answer to my solution?
>
> transient elements == input range && not forward range && element type
> has mutable indirections.
>
> This is testable by any interested clients, covers a whole lot of
> ground, and has a good intuition behind it.
>
>
> Andrei

That is a very imprecise approximation. I think it does not cover any ground: The day eg. 'array' will require this kind of non-transient element range is the day where I will write my own.

On Wednesday, November 14, 2012 20:18:26 Timon Gehr wrote:
> That is a very imprecise approximation. I think it does not cover any ground: The day eg. 'array' will require this kind of non-transient element range is the day where I will write my own.

std.array.array _cannot_ work with a transient front. It's stuffing the elements into an array as iterates over them, and if each of those elements keeps changing on it, then it won't end up with the right result. I don't believe that there is any way around this, not without somehow duping front when necessary, but we have no way to do that generically, and even if we did, there's no way for std.array.array. to know whether front is actually transient or not, just whether it _might_ be - not without the range having a property of some kind which told you that its front was transient. So, automatically duping would just introduce inefficiencies, because it couldn't know when it actually needed to do it or not. Something like

auto arr = array(map!"a.dup"(file.byLine()));

would work, but as long as ByLine reuses its buffer, it will _never_ work with std.array.array. std.array.array is _precisely_ the sort of range that would require the restrictions that Andrei is talking about. We either need restrictions like that, to complicate ranges in general with extra traits and/or functions which support transience, or to make transient fronts outright invalid ranges.

- Jonathan M Davis

On Wednesday, November 14, 2012 07:29:34 H. S. Teoh wrote:
> On Wed, Nov 14, 2012 at 12:51:45AM +0100, deadalnix wrote:
> > Le 13/11/2012 20:13, Jonathan M Davis a écrit :
> > >On Tuesday, November 13, 2012 09:45:17 H. S. Teoh wrote:
> > >>Unfortunately, using ranges in their most general sense is looking like a pipe dream to me right now, and I'm ready to just move on.
> > >
> > >The reality of the matter is that there are limits to any abstraction. In order to make it take more use cases and situations into account, it must become increasingly complicated, and eventually the abstraction becomes complicated enough that it's hard to use for even basic cases.
> 
> In that case, I argue that the abstraction is a leaky one, and needs to be improved/replaced.

Most (all?) abstractions are leaky on some level. But the real problem is simply that to make it so that you can do absolutely everything with complete control, it becomes too complicated to be useable in the normal case. It's pretty much inevitable that you have to cut off some use cases or it's going to be too complicated. The trick is figuring out how to make it work with as many use cases as reasonably possible and still be quite useable in the average case, and that's not necessarily an easy balance to strike.

- Jonathan M Davis

On 11/14/12 11:18 AM, Timon Gehr wrote:
> On 11/14/2012 06:43 PM, Andrei Alexandrescu wrote:
>> On 11/14/12 7:29 AM, H. S. Teoh wrote:
>>> But since this isn't going to be fixed properly, then the only solution
>>> left is to arbitrarily declare transient ranges as not ranges (even
>>> though the concept of ranges itself has no such implication, and many
>>> algorithms don't even need such assumptions), and move on. We will just
>>> have to put up with an inferior implementation of std.algorithm and
>>> duplicate code when one*does* need to work with transient ranges. It is
>>> not a big loss anyway, since one can simply implement one's own library
>>> to deal with this issue properly.
>>
>> What is your answer to my solution?
>>
>> transient elements == input range && not forward range && element type
>> has mutable indirections.
>>
>> This is testable by any interested clients, covers a whole lot of
>> ground, and has a good intuition behind it.
>>
>>
>> Andrei
>
> That is a very imprecise approximation. I think it does not cover any
> ground: The day eg. 'array' will require this kind of non-transient
> element range is the day where I will write my own.

What would be an example where array would have trouble with using this definition?

Andrei

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:k80l8p$397$1@digitalmars.com...
> On 11/14/12 7:29 AM, H. S. Teoh wrote:
>> But since this isn't going to be fixed properly, then the only solution left is to arbitrarily declare transient ranges as not ranges (even though the concept of ranges itself has no such implication, and many algorithms don't even need such assumptions), and move on. We will just have to put up with an inferior implementation of std.algorithm and duplicate code when one*does*  need to work with transient ranges. It is not a big loss anyway, since one can simply implement one's own library to deal with this issue properly.
>
> What is your answer to my solution?
>
> transient elements == input range && not forward range && element type has mutable indirections.
>
> This is testable by any interested clients, covers a whole lot of ground, and has a good intuition behind it.
>
>
> Andrei

Is it just me, or would this still refuse: array(map!"a.dup"(stdin.byLine())) ?

On 11/14/12 5:30 PM, Daniel Murphy wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message
> news:k80l8p$397$1@digitalmars.com...
>> On 11/14/12 7:29 AM, H. S. Teoh wrote:
>>> But since this isn't going to be fixed properly, then the only solution
>>> left is to arbitrarily declare transient ranges as not ranges (even
>>> though the concept of ranges itself has no such implication, and many
>>> algorithms don't even need such assumptions), and move on. We will just
>>> have to put up with an inferior implementation of std.algorithm and
>>> duplicate code when one*does*  need to work with transient ranges. It is
>>> not a big loss anyway, since one can simply implement one's own library
>>> to deal with this issue properly.
>>
>> What is your answer to my solution?
>>
>> transient elements == input range&&  not forward range&&  element type has
>> mutable indirections.
>>
>> This is testable by any interested clients, covers a whole lot of ground,
>> and has a good intuition behind it.
>>
>>
>> Andrei
>
> Is it just me, or would this still refuse:
> array(map!"a.dup"(stdin.byLine())) ?

It would accept mapping to!string.

Andrei

On Tuesday, 13 November 2012 at 21:45:50 UTC, Brad Roberts wrote:
> On Tue, 13 Nov 2012, Walter Bright wrote:
>
>> On 11/13/2012 11:26 AM, David Nadlinger wrote:
>> > The only question raised by my suggestion is hosting. I don't know what
>> > infrastructure dlang.org is hosted on right now, and if running a MediaWiki
>> > instance on it would be possible. Given the moderate amounts of traffic to
>> > expect, I don't think this should be an insurmountable problem, though ?
>> > heck,
>> > if it wouldn't occasionally be unstable, I would even offer my own VPS (1 GB
>> > RAM, reasonably fast CPU/disk).
>> 
>> Brad Roberts is experienced at hosting mediawiki.
>
> Minimally.  I'm not prepared to host one for a wide audience where I need
> to be prepared to deal with the internet masses.

I host a number of MediaWikis and have some experience running and maintaining them. The biggest one is http://worms2d.info/. I consider spam a solved problem, on that wiki at least.

I'd love to look into writing a wiki syntax converter to move all the content from ProWiki to a new MediaWiki instance (and a bot to replace the ProWiki pages with links to the new pages), but unfortunately I don't have the time to spare for such an endeavour at the moment. But if the D community is interested in just a MediaWiki setup on the same server as the D forum (with me taking care of maintenance), I could look into that.

On 11/15/12, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> I'd love to look into writing a wiki syntax converter to move all the content from ProWiki to a new MediaWiki instance

Well even if we don't have that we will have an opportunity to review and update outdated articles.

On Thursday, 15 November 2012 at 08:28:09 UTC, Andrej Mitrovic wrote:
> On 11/15/12, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
>> I'd love to look into writing a wiki syntax converter to move all
>> the content from ProWiki to a new MediaWiki instance
>
> Well even if we don't have that we will have an opportunity to review
> and update outdated articles.

We really should do that and remove everything not proven to be uptodate.

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:k81k6s$1qm7$1@digitalmars.com...
> On 11/14/12 5:30 PM, Daniel Murphy wrote:
>> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message news:k80l8p$397$1@digitalmars.com...
>>> On 11/14/12 7:29 AM, H. S. Teoh wrote:
>>>> But since this isn't going to be fixed properly, then the only solution
>>>> left is to arbitrarily declare transient ranges as not ranges (even
>>>> though the concept of ranges itself has no such implication, and many
>>>> algorithms don't even need such assumptions), and move on. We will just
>>>> have to put up with an inferior implementation of std.algorithm and
>>>> duplicate code when one*does*  need to work with transient ranges. It
>>>> is
>>>> not a big loss anyway, since one can simply implement one's own library
>>>> to deal with this issue properly.
>>>
>>> What is your answer to my solution?
>>>
>>> transient elements == input range&&  not forward range&&  element type
>>> has
>>> mutable indirections.
>>>
>>> This is testable by any interested clients, covers a whole lot of
>>> ground,
>>> and has a good intuition behind it.
>>>
>>>
>>> Andrei
>>
>> Is it just me, or would this still refuse:
>> array(map!"a.dup"(stdin.byLine())) ?
>
> It would accept mapping to!string.
>
> Andrei
>

Is that really good enough?  Keeping ranges simple is important, but so is making the obvious solution 'just work'.