Re: Are iterators and ranges going to co-exist?

2010-07-20 Thread Peter Alexander
On 20/07/10 4:27 AM, PercentEwe wrote: As for space usage, well, sometimes ranges can give you an improvement, and in the worst case, a range is a struct with begin and end C++ iterators as its members. It's a space improvement unless you don't actually need to iterate through anything, in which

Re: Higher level built-in strings

2010-07-20 Thread Rory McGuire
On Tue, 20 Jul 2010 01:51:51 +0200, Jesse Phillips wrote: What about: struct String { string items; alias items this; } And add the needed functions you wish to have in string and it will still work in existing functions that operate on immutable(char)[] You shouldn't ne

Re: Are iterators and ranges going to co-exist?

2010-07-20 Thread Peter Alexander
Some more arguments for iterators/cursors: 1. How would you implement Floyd's cycle finding algorithm using ranges? (http://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare) It uses two iterators over the same range. You would have to wastefully use 2 ranges that have the same end coordi

Re: Higher level built-in strings

2010-07-20 Thread bearophile
Walter: >As it turns out, indexing by byte is *far* more common than indexing by code >unit, in fact, I've never ever needed to index by code unit.< OK. >Probably too late to change that one. There is very little D2 code around, so little changes as this one are possible still. As alternativ

Re: Are iterators and ranges going to co-exist?

2010-07-20 Thread Rainer Deyke
On 7/20/2010 01:39, Peter Alexander wrote: > Iterator is probably a bad name for describing this concept, as it > implies that they have the same usage as ranges, but they do not. An > iterator/cursor points to one element -- a generic pointer if you like. > Ranges define a self-sufficient machine

Re: Higher level built-in strings

2010-07-20 Thread Michel Fortin
On 2010-07-20 00:31:34 -0400, Walter Bright said: Steven Schveighoffer wrote: I agree here. Anything that uses indexing to perform a linear operation is bound for the scrap heap. But what about this: foreach(c; str) which types c as char (or immutable char), not dchar. Probably too late

Re: Higher level built-in strings

2010-07-20 Thread DCoder
== Quote from Michel Fortin (michel.for...@michelf.com)'s article > On 2010-07-20 00:31:34 -0400, Walter Bright said: > > Steven Schveighoffer wrote: > >> I agree here. Anything that uses indexing to perform a linear > >> operation is bound for the scrap heap. But what about this: > >> > >> fore

D's treatment of values versus side-effect free nullary functions

2010-07-20 Thread Justin Johansson
Perhaps this is a philosophical question, like what is time, though it is also a novice programmer question as well. The question exactly being: "What is the difference between a (constant/immutable) value and the result of calling a side-effect free function that returns the same?" May I pleas

Re: Are iterators and ranges going to co-exist?

2010-07-20 Thread Steven Schveighoffer
On Mon, 19 Jul 2010 17:54:59 -0400, Mafi wrote: I have to say that I'm not a specialist in STL or C++ in general but as far as I know an iterator is class mainly consisting of a pointer to the container, the current index and the operator-overloadd-function for ++. So what can you do with

Re: Higher level built-in strings

2010-07-20 Thread Steven Schveighoffer
On Mon, 19 Jul 2010 20:26:47 -0400, Andrei Alexandrescu wrote: On 07/19/2010 06:51 PM, Jesse Phillips wrote: What about: struct String { string items; alias items this; } And add the needed functions you wish to have in string and it will still work in existing functions

Re: Are iterators and ranges going to co-exist?

2010-07-20 Thread Andrei Alexandrescu
On 07/20/2010 03:01 AM, Peter Alexander wrote: Some more arguments for iterators/cursors: 1. How would you implement Floyd's cycle finding algorithm using ranges? (http://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare) It uses two iterators over the same range. You would have to wastefu

Re: Higher level built-in strings

2010-07-20 Thread Rory McGuire
On Tue, 20 Jul 2010 16:08:06 +0200, Jesse Phillips wrote: But then you can't overload operators. On Tue, Jul 20, 2010 at 12:54 AM, Rory McGuire wrote: On Tue, 20 Jul 2010 01:51:51 +0200, Jesse Phillips wrote: What about: struct String { string items; alias items this; }

Re: Higher level built-in strings

2010-07-20 Thread Rory McGuire
On Tue, 20 Jul 2010 16:51:57 +0200, Rory McGuire wrote: On Tue, 20 Jul 2010 16:08:06 +0200, Jesse Phillips wrote: But then you can't overload operators. On Tue, Jul 20, 2010 at 12:54 AM, Rory McGuire wrote: On Tue, 20 Jul 2010 01:51:51 +0200, Jesse Phillips wrote: What about: st

Re: Higher level built-in strings

2010-07-20 Thread Sean Kelly
Steven Schveighoffer Wrote: > > How do we make this work? > > auto str = "hello world"; > foreach(c; str) > assert(is(typeof(c) == dchar)); foreach (dchar c; str) assert(...); This feature has been in D for years.

Re: Higher level built-in strings

2010-07-20 Thread Sean Kelly
Walter Bright Wrote: > bearophile wrote: > > Walter Bright: > >> 1. most string operations, such as copying and searching, even regular > >> expressions, work just fine using regular indices. > >> > >> 2. doing the operations in (1) using code points and having to continually > >> decode the st

Proposal: Automatic shallow Unqual on IFTI

2010-07-20 Thread dsimcha
Bug 2594 (http://d.puremagic.com/issues/show_bug.cgi?id=2594) has languished in Bugzilla for about 1.5 years and really irks me. Furthermore, std.math.pow(), for example, doesn't work when passed immutable values. In other words, right now you can't do: immutable uint foo = 5; immutable uint bar

Re: Higher level built-in strings

2010-07-20 Thread Simen kjaeraas
Rory McGuire wrote: [snip] Rory, is there something wrong with your newsreader? I keep seeing your posts as replies only to the top post. -- Simen

Re: Higher level built-in strings

2010-07-20 Thread Jérôme M. Berger
Sean Kelly wrote: > Steven Schveighoffer Wrote: >> How do we make this work? >> >> auto str = "hello world"; >> foreach(c; str) >> assert(is(typeof(c) == dchar)); > > foreach (dchar c; str) > assert(...); > > This feature has been in D for years. And what about this one: void fu

Re: Proposal: Automatic shallow Unqual on IFTI

2010-07-20 Thread Lars T. Kyllingstad
On Tue, 20 Jul 2010 16:19:50 +, dsimcha wrote: > Bug 2594 (http://d.puremagic.com/issues/show_bug.cgi?id=2594) has > languished in Bugzilla for about 1.5 years and really irks me. > Furthermore, std.math.pow(), for example, doesn't work when passed > immutable values. In other words, right n

Re: Higher level built-in strings

2010-07-20 Thread Jesse Phillips
Simen kjaeraas Wrote: > Rory McGuire wrote: > > [snip] > > Rory, is there something wrong with your newsreader? I keep seeing your > posts as replies only to the top post. > > -- > Simen Actually I'm getting his messages as emails, and just thought he was only sending to me.

Re: Higher level built-in strings

2010-07-20 Thread awishformore
Am 20.07.2010 19:15, schrieb Jesse Phillips: Simen kjaeraas Wrote: Rory McGuire wrote: [snip] Rory, is there something wrong with your newsreader? I keep seeing your posts as replies only to the top post. -- Simen Actually I'm getting his messages as emails, and just thought he was only

Re: Higher level built-in strings

2010-07-20 Thread Steven Schveighoffer
On Tue, 20 Jul 2010 11:02:57 -0400, Sean Kelly wrote: Steven Schveighoffer Wrote: How do we make this work? auto str = "hello world"; foreach(c; str) assert(is(typeof(c) == dchar)); foreach (dchar c; str) assert(...); This feature has been in D for years. The omission of dchar

Re: Are iterators and ranges going to co-exist?

2010-07-20 Thread Steven Schveighoffer
On Tue, 20 Jul 2010 09:52:00 -0400, Andrei Alexandrescu wrote: On 07/20/2010 03:01 AM, Peter Alexander wrote: Some more arguments for iterators/cursors: 1. How would you implement Floyd's cycle finding algorithm using ranges? (http://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare)

Re: Are iterators and ranges going to co-exist?

2010-07-20 Thread Andrei Alexandrescu
Steven Schveighoffer wrote: On Tue, 20 Jul 2010 09:52:00 -0400, Andrei Alexandrescu wrote: On 07/20/2010 03:01 AM, Peter Alexander wrote: Some more arguments for iterators/cursors: 1. How would you implement Floyd's cycle finding algorithm using ranges? (http://en.wikipedia.org/wiki/Cycle_d

Re: Higher level built-in strings

2010-07-20 Thread Jonathan M Davis
On Tuesday, July 20, 2010 05:30:51 DCoder wrote: > I'm wondering how bad would it be introduce a schar (short char, 1 > byte) type and then let char simply map to a "default" char type: > dchar, wchar, or whatever we tell the compiler. By default, char > would map to dchar. > > alias char dchar; >

Re: Are iterators and ranges going to co-exist?

2010-07-20 Thread Steven Schveighoffer
On Tue, 20 Jul 2010 13:53:37 -0400, Andrei Alexandrescu wrote: Steven Schveighoffer wrote: On Tue, 20 Jul 2010 09:52:00 -0400, Andrei Alexandrescu wrote: On 07/20/2010 03:01 AM, Peter Alexander wrote: Some more arguments for iterators/cursors: 1. How would you implement Floyd's cycle

Re: D's treatment of values versus side-effect free nullary functions

2010-07-20 Thread Jonathan M Davis
On Tuesday, July 20, 2010 06:36:57 Justin Johansson wrote: > Perhaps this is a philosophical question, like what is time, though it > is also a novice programmer question as well. The question exactly > being: > > "What is the difference between a (constant/immutable) value and the > result of ca

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
Andrei Alexandrescu wrote: I think otherwise. In fact I confess I am extremely excited. The current state of affairs described built-in strings very accurately: they are formally bidirectional ranges, yet they offer random access for code units that you can freely use if you so wish. It's model

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
bearophile wrote: Probably too late to change that one. There is very little D2 code around, so little changes as this one are possible still. It's a D1 feature, and has been there since nearly the beginning.

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
Michel Fortin wrote: As for the "too late to change" stance, I'm not sure. It'll certainly be to late to change in a year, but right now D2 is still pretty new. What makes you say it's too late? As I said to bearophile, it's a D1 feature.

Re: Higher level built-in strings

2010-07-20 Thread Rory McGuire
On Tue, 20 Jul 2010 18:35:12 +0200, Simen kjaeraas wrote: Rory McGuire wrote: [snip] Rory, is there something wrong with your newsreader? I keep seeing your posts as replies only to the top post. I'm using opera mail. Any suggestions for Linux+Windows, excluding thunderbird(slow)?

Re: Are iterators and ranges going to co-exist?

2010-07-20 Thread Peter Alexander
On 20/07/10 2:52 PM, Andrei Alexandrescu wrote: I think there's a confusion somewhere. You may want to check out the SList definition in std.algorithm. A SList range is exactly one pointer thick. With singly-linked lists it's the iterator approach that is wasteful because it canonically transport

Re: Higher level built-in strings

2010-07-20 Thread Steven Schveighoffer
On Tue, 20 Jul 2010 14:29:43 -0400, Walter Bright wrote: bearophile wrote: Probably too late to change that one. There is very little D2 code around, so little changes as this one are possible still. It's a D1 feature, and has been there since nearly the beginning. Since when did we c

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
Sean Kelly wrote: I've had the same experience. The proposed changes would make string useless to me, even for Unicode work. I'd end up using ubyte[] instead. At this point, the experience with D strings is that D gets it right. To change it would require someone who has spent a *lot* of hou

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
Jérôme M. Berger wrote: And what about this one: void func(T) (T range) { foreach (elem; range) assert (is (typeof (elem) == ElementType!(T))); } func ("azerty"); auto a = [ 1, 2, 3, 4, 5]; func (a); You can specialize the template for strings: void func(T:string)(T range

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
Steven Schveighoffer wrote: The omission of dchar is on purpose. Phobos has characterized string as a bidirectional range of dchars. For every range where I do: foreach(e; range) e is of the type of the range. Except for char and wchar. This schizophrenia of type induction is very bad for

Re: Higher level built-in strings

2010-07-20 Thread Steven Schveighoffer
On Tue, 20 Jul 2010 15:21:34 -0400, Walter Bright wrote: Steven Schveighoffer wrote: The omission of dchar is on purpose. Phobos has characterized string as a bidirectional range of dchars. For every range where I do: foreach(e; range) e is of the type of the range. Except for char an

Re: Higher level built-in strings

2010-07-20 Thread Jérôme M. Berger
Walter Bright wrote: > Jérôme M. Berger wrote: >> And what about this one: >> >> void func(T) (T range) { >> foreach (elem; range) >> assert (is (typeof (elem) == ElementType!(T))); >> } >> >> func ("azerty"); >> auto a = [ 1, 2, 3, 4, 5]; >> func (a); > > You can specialize the te

Re: TDPL, shared data, and Phobos

2010-07-20 Thread Brian Palmer
Thanks Sean, it's great to at least know where the issue is. As to my other question, why do the D std library docs at http://www.digitalmars.com/d/2.0/phobos/phobos.html have no indication that core.sync and the other core.* packages even exist? Are the APIs not stable enough yet to treat them

Re: TDPL, shared data, and Phobos

2010-07-20 Thread Brian Palmer
> > It probably wasn't very clear from my simplified example, but I'm looking > > to create a shared-reader-one-writer scenario. If I declare MyValue > > synchronized, only one thread can be inside the get() method at a time, > > which defeats the shared-reader requirement. Imagine this is a muc

Re: Higher level built-in strings

2010-07-20 Thread Jérôme M. Berger
Jesse Phillips wrote: > Simen kjaeraas Wrote: > >> Rory McGuire wrote: >> >> [snip] >> >> Rory, is there something wrong with your newsreader? I keep seeing your >> posts as replies only to the top post. >> >> -- >> Simen > > Actually I'm getting his messages as emails, and just thought he was

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
Steven Schveighoffer wrote: On Tue, 20 Jul 2010 14:29:43 -0400, Walter Bright wrote: It's a D1 feature, and has been there since nearly the beginning. Since when did we care about D1 compatibility? We care about incompatibilities that silently break code. const, inout, array appending, fi

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
Steven Schveighoffer wrote: On Tue, 20 Jul 2010 15:21:34 -0400, Walter Bright wrote: Steven Schveighoffer wrote: The omission of dchar is on purpose. Phobos has characterized string as a bidirectional range of dchars. For every range where I do: foreach(e; range) e is of the type of the

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
Jérôme M. Berger wrote: Walter Bright wrote: You can specialize the template for strings: void func(T:string)(T range) { ... } Sure, i can also not use a template and write however many overloaded functions I need. So what are templates for? The overloaded template specialization ca

Re: Higher level built-in strings

2010-07-20 Thread Walter Bright
Rory McGuire wrote: I'm using opera mail. Any suggestions for Linux+Windows, excluding thunderbird(slow)? I use thunderbird on both windows & linux, haven't noticed speed problems other than my slow internet connection. I have noticed that thunderbird uses multithreading fairly effectively t

Re: Higher level built-in strings

2010-07-20 Thread Andrei Alexandrescu
Walter Bright wrote: Steven Schveighoffer wrote: On Tue, 20 Jul 2010 14:29:43 -0400, Walter Bright wrote: It's a D1 feature, and has been there since nearly the beginning. Since when did we care about D1 compatibility? We care about incompatibilities that silently break code. const, inou

Re: Higher level built-in strings

2010-07-20 Thread Andrei Alexandrescu
Walter Bright wrote: Steven Schveighoffer wrote: On Tue, 20 Jul 2010 15:21:34 -0400, Walter Bright wrote: Steven Schveighoffer wrote: The omission of dchar is on purpose. Phobos has characterized string as a bidirectional range of dchars. For every range where I do: foreach(e; range) e

Re: D's treatment of values versus side-effect free nullary functions

2010-07-20 Thread Justin Johansson
Jonathan M Davis wrote: On Tuesday, July 20, 2010 06:36:57 Justin Johansson wrote: Perhaps this is a philosophical question, like what is time, though it is also a novice programmer question as well. The question exactly being: "What is the difference between a (constant/immutable) value and t

Re: Higher level built-in strings

2010-07-20 Thread Jonathan M Davis
On Tuesday, July 20, 2010 11:45:41 Rory McGuire wrote: > On Tue, 20 Jul 2010 18:35:12 +0200, Simen kjaeraas > > wrote: > > Rory McGuire wrote: > > > > [snip] > > > > Rory, is there something wrong with your newsreader? I keep seeing your > > posts as replies only to the top post. > > I'm usin

Re: D's treatment of values versus side-effect free nullary functions

2010-07-20 Thread Justin Johansson
Jonathan M Davis wrote: Also, the function could be used in CTFE to produce the value at compile time and just use that value instead of calling the function at runtime. Depending on how the function is used and how much optimizing the compiler does, the function may never get called at runtim

Re: Higher level built-in strings

2010-07-20 Thread Fawzi Mohamed
I did not read all the discussion in detail, but in my opinion something that would be very useful in a library is struct String{ void *ptr; size_t _l; enum :size_t { MaskLen=((~cast(size_t)0)>>2) } enum :int { BitsLen=8*si

Re: D's treatment of values versus side-effect free nullary functions

2010-07-20 Thread Jonathan M Davis
On Tuesday, July 20, 2010 14:28:16 Justin Johansson wrote: > Jonathan M Davis wrote: > > Also, the > > function could be used in CTFE to produce the value at compile time and > > just use that value instead of calling the function at runtime. > > Depending on how the function is used and how much o

Re: D's treatment of values versus side-effect free nullary functions

2010-07-20 Thread bearophile
Jonathan M Davis: > However, what can be used in CTFE is currently rather limited. Currently its main limitation is the amount of memory it burns. I think Don will eventually remove this problem too, even if this requires a half rewrite of the whole thing :-) > You also generally have to force

Re: Improving std.algorithm.find

2010-07-20 Thread sybrandy
In most cases, the return types are just ranges, but because they're constructed by the algorithm, the algorithm creates its own range type. So, generally, all you need to know is that a range is being returned. But even then, you run into some issues where you need to do stuff like run the return

Re: Improving std.algorithm.find

2010-07-20 Thread sybrandy
On 07/19/2010 10:18 PM, Andrei Alexandrescu wrote: On 07/19/2010 06:36 PM, sybrandy wrote: I think that the problem with find() is not so much find() but it's documentation. In all honesty, anything with a return type like FindResult!(Range, Ranges) is going to scare people off. I fully agree.

Re: D's treatment of values versus side-effect free nullary functions

2010-07-20 Thread Jonathan M Davis
On Tuesday, July 20, 2010 15:49:56 bearophile wrote: > > As far as I know, currently optimization level doesn't influence CTFE. Well, like I said. It depends on what exactly the compiler does, and as far as I know, it only does CTFE when it has to for initialization. But theoretically, it cou

Re: Improving std.algorithm.find

2010-07-20 Thread bearophile
sybrandy: > Agreed. I'm also a big fan of examples as it's very easy to look at an > example and get something working. Then, once you see it work and get > somewhat of an understanding, you can dig deeper into the details to > learn more. I am not sure, but I think find() is not what I need,

Re: D's treatment of values versus side-effect free nullary functions

2010-07-20 Thread bearophile
Jonathan M Davis: > But theoretically, it > could be used for optimizations just like inlining (particularly with pure > functions), and that being the case, it probably will at some point. Pure functions go well with CTFE because they don't use global state, but you can run code at compile tim

C strings

2010-07-20 Thread bearophile
In D.learn in a short thread with Lars T. Kyllingstad we have discussed about possible bugs coming from using C code through D and forgetting to zero-terminate strings given to C libs. You can use the D type system (originally I have used a typedef) to be sure you have applied toStringz() on D

emplace, scope, enforce [Was: Re: Manual...]

2010-07-20 Thread bearophile
Andrei Alexandrescu: > emplace(), defined in std.conv, is relatively new. I haven't yet added > emplace() for class objects, and this is as good an opportunity as any: > http://www.dsource.org/projects/phobos/changeset/1752 Thank you, I have used this, and later I have done few tests too. The "

Re: D's treatment of values versus side-effect free nullary functions

2010-07-20 Thread Jonathan M Davis
On Tuesday, July 20, 2010 17:24:33 bearophile wrote: > Jonathan M Davis: > > But theoretically, it > > could be used for optimizations just like inlining (particularly with > > pure functions), and that being the case, it probably will at some > > point. > > Pure functions go well with CTFE becaus