On Fri, 28 Mar 2014 14:15:10 -0000, Chris <wendlec@tcd.ie> wrote:

> Earlier Walter wrote:
>
> "I don't like being in the position of when I need high performance code, I have
> to implement my own ranges & algorithms, or telling customers they need to do so."
>
> I don't think there is a one size fits all. What if customers ask for maximum security? In any language, if I want high performance, I have to be prepared to walk on thin ice. If I want things to be safe and / or generic, I have to accept additonal checks (= perfomance penalties). I don't think that a language can solve the fundamental problems concerning programming / mathematical logic with all the contradictory demands involved. It can give us the tools to cope with those problems, but not solve them out of the box.

You can build safety on top of performance.  You cannot do the opposite.  Meaning, one could wrap an unsafe/fast range with a safe/slower one.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Friday, 28 March 2014 at 15:49:06 UTC, Regan Heath wrote:
> On Fri, 28 Mar 2014 14:15:10 -0000, Chris <wendlec@tcd.ie> wrote:
>
>> Earlier Walter wrote:
>>
>> "I don't like being in the position of when I need high performance code, I have
>> to implement my own ranges & algorithms, or telling customers they need to do so."
>>
>> I don't think there is a one size fits all. What if customers ask for maximum security? In any language, if I want high performance, I have to be prepared to walk on thin ice. If I want things to be safe and / or generic, I have to accept additonal checks (= perfomance penalties). I don't think that a language can solve the fundamental problems concerning programming / mathematical logic with all the contradictory demands involved. It can give us the tools to cope with those problems, but not solve them out of the box.
>
> You can build safety on top of performance.  You cannot do the opposite.  Meaning, one could wrap an unsafe/fast range with a safe/slower one.
>
> R

But should unsafe+fast be the default or rather an option for cases when you really need it?

On Friday, 28 March 2014 at 09:30:25 UTC, Regan Heath wrote:
> On Fri, 28 Mar 2014 08:59:34 -0000, Paolo Invernizzi <paolo.invernizzi@no.address> wrote:
>> For what concern us, everyone here is happy with the fact that empty *must* be checked prior to front/popFront.
>
> This is actually not true.
>
> R

What I'm meaning, it's that we don't care: we are always respecting the sequence "empty > front > pop", and everybody here find it natural.
--
Paolo

On Fri, 28 Mar 2014 16:23:11 +0000, Paolo Invernizzi wrote:

> On Friday, 28 March 2014 at 09:30:25 UTC, Regan Heath wrote:
>> On Fri, 28 Mar 2014 08:59:34 -0000, Paolo Invernizzi <paolo.invernizzi@no.address> wrote:
>>> For what concern us, everyone here is happy with the fact that empty *must* be checked prior to front/popFront.
>>
>> This is actually not true.
>>
>> R
> 
> What I'm meaning, it's that we don't care: we are always respecting the sequence "empty > front > pop", and everybody here find it natural.


To clarify for Mr. Invernizzi: the "we" to which he refers is the group of people he works with, and /not/ the members of this newsgroup.

--jjs

28-Mar-2014 04:20, Walter Bright пишет:
> On 3/27/2014 2:56 PM, Andrei Alexandrescu wrote:
>> On 3/27/14, 2:24 PM, Walter Bright wrote:
>>> The range protocol is designed to work with streams.
>>
>> It's designed to work with containers.
>
> I know we talked about streams when we designed it.

If streams are like hot raw sockets then certainly it doesn't make sense. Ranges work nice when there are some "slots" down below, that is a buffer.

>>> It's a giant fail
>>> if they do not, or if you want to create a separate, non-range universe
>>> to deal with streams.
>>
>> It's not a giant fail, we just need to adjust the notion.
>
> Are you suggesting that ranges needn't support streams?

Yes they "don't support streams". They are an abstraction somewhere on top of buffering. This is where they fit nicely.


-- 
Dmitry Olshansky

On Fri, 28 Mar 2014 16:04:29 -0000, Chris <wendlec@tcd.ie> wrote:

> On Friday, 28 March 2014 at 15:49:06 UTC, Regan Heath wrote:
>> On Fri, 28 Mar 2014 14:15:10 -0000, Chris <wendlec@tcd.ie> wrote:
>>
>>> Earlier Walter wrote:
>>>
>>> "I don't like being in the position of when I need high performance code, I have
>>> to implement my own ranges & algorithms, or telling customers they need to do so."
>>>
>>> I don't think there is a one size fits all. What if customers ask for maximum security? In any language, if I want high performance, I have to be prepared to walk on thin ice. If I want things to be safe and / or generic, I have to accept additonal checks (= perfomance penalties). I don't think that a language can solve the fundamental problems concerning programming / mathematical logic with all the contradictory demands involved. It can give us the tools to cope with those problems, but not solve them out of the box.
>>
>> You can build safety on top of performance.  You cannot do the opposite.  Meaning, one could wrap an unsafe/fast range with a safe/slower one.
>>
>> R
>
> But should unsafe+fast be the default or rather an option for cases when you really need it?

Pass.  My point was only that it needs to exist.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Fri, 28 Mar 2014 16:30:36 -0000, John Stahara <john.stahara+dlang@gmail.com> wrote:

> On Fri, 28 Mar 2014 16:23:11 +0000, Paolo Invernizzi wrote:
>
>> On Friday, 28 March 2014 at 09:30:25 UTC, Regan Heath wrote:
>>> On Fri, 28 Mar 2014 08:59:34 -0000, Paolo Invernizzi
>>> <paolo.invernizzi@no.address> wrote:
>>>> For what concern us, everyone here is happy with the fact that empty
>>>> *must* be checked prior to front/popFront.
>>>
>>> This is actually not true.
>>>
>>> R
>>
>> What I'm meaning, it's that we don't care: we are always respecting the
>> sequence "empty > front > pop", and everybody here find it natural.
>
>
> To clarify for Mr. Invernizzi: the "we" to which he refers is the group
> of people he works with, and /not/ the members of this newsgroup.
>
> --jjs

Thanks, that was confusing me :)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

28-Mar-2014 13:55, Walter Bright пишет:
> On 3/28/2014 1:32 AM, Johannes Pfau wrote:
>> Ranges have equivalents in other languages:
>> iterators in c++,
>> IEnumerator in c#,
>> Iterator in java
>>
>> all these languages have special stream types for raw data. I don't
>> think it's bad if we also have streams/ranges separate in D.
>
>
> Do you see a point to be able to, in an algorithm, seamlessly swap a
> socket with a string?
>

Certainly NOT a socket. There is no escaping the fact that there are specifics to unbuffered direct streams.
What you mention only makes sense with buffering either implicit or (I'd prefer) explicit.

> empty-front-popFront works with streams and non-streams. Why break this?

Pipe dream.

-- 
Dmitry Olshansky

On Fri, Mar 28, 2014 at 04:30:36PM +0000, John Stahara wrote:
> On Fri, 28 Mar 2014 16:23:11 +0000, Paolo Invernizzi wrote:
> 
> > On Friday, 28 March 2014 at 09:30:25 UTC, Regan Heath wrote:
> >> On Fri, 28 Mar 2014 08:59:34 -0000, Paolo Invernizzi <paolo.invernizzi@no.address> wrote:
> >>> For what concern us, everyone here is happy with the fact that empty *must* be checked prior to front/popFront.
> >>
> >> This is actually not true.
> >>
> >> R
> > 
> > What I'm meaning, it's that we don't care: we are always respecting the sequence "empty > front > pop", and everybody here find it natural.
> 
> 
> To clarify for Mr. Invernizzi: the "we" to which he refers is the group of people he works with, and /not/ the members of this newsgroup.
[...]

FWIW I find it perfectly natural as well. (But I know not everyone
agrees. :P)


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL

Am Fri, 28 Mar 2014 02:55:45 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 3/28/2014 1:32 AM, Johannes Pfau wrote:
> > Ranges have equivalents in other languages:
> > iterators in c++,
> > IEnumerator in c#,
> > Iterator in java
> >
> > all these languages have special stream types for raw data. I don't think it's bad if we also have streams/ranges separate in D.
> 
> 
> Do you see a point to be able to, in an algorithm, seamlessly swap a socket with a string?

Sorry, but no. It sure sounds nice first, but I can't really imagine a use case where I would want any generic algorithms to work directly on a socket. Having a look on the cheat sheet of std.algorithm 99% of these algorithms do not make sense to operate on sockets, those that do (count, until) would be bad in performance terms when operating directly byte per byte.

You at least want buffered reads when doing IO operations. If you then extend range interface to give access to an internal buffer you just reinvented streams.

> 
> empty-front-popFront works with streams and non-streams. Why break this?
> 
> 

It 'works' with streams but it's way too slow. You don't want to read byte-per-byte. Of course you can always implement ranges on top of streams. Usually these will not provide byte-per-byte access but efficient higher level abstractions (byLine, byChunk, decodeText).

The point is you can implement ranges on streams easily, but you can't
use ranges as the generic primitive for raw data. What's the element
type of a data range?
ubyte - performance sucks
ubyte[n], ubyte[] now you have a range of ranges, most algorithms wont
work as expected (find, count, ...).

(the call empty/don't call empty discussion is completely unrelated to this, btw. You can implement ranges on streams either way, but again, using ranges for raw data streams is not a good idea.)