www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - reddit.com: first Chapter of TDPL available for free

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/

(Don't tell anyone, but I plan to rewrite it.)

Andrei
Aug 03 2009
next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 
 
 
 (Don't tell anyone, but I plan to rewrite it.)
 
 Andrei

"...and floating-point constants have type double." I thought they had type 'real'! Seems I've learned something already. L.
Aug 03 2009
prev sibling next sibling parent reply The Anh Tran <trtheanh gmail.com> writes:
Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 
 
 
 (Don't tell anyone, but I plan to rewrite it.)
 
 Andrei

Typo spotted, sir! The paragraph before "1.7 Values vs. References": "In C++ lingo, member functions are virtual by default. If you prepend final to a member function, that prohibits derived classes from overriding the function, effectively stopping the virtual mechanism." It's him, Java!!!!!! :)
Aug 03 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
The Anh Tran wrote:
 Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 


 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

Typo spotted, sir! The paragraph before "1.7 Values vs. References": "In C++ lingo, member functions are virtual by default. If you prepend final to a member function, that prohibits derived classes from overriding the function, effectively stopping the virtual mechanism." It's him, Java!!!!!! :)

In fact it's not a typo, it's intentional but the effect is bad: when I started with "In C++ lingo" I was referring to the meaning of "virtual". I rewrote the sentence. Thanks for the feedback, and if anybody has comments about anything referring to the book, please let me know. Andrei
Aug 03 2009
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 
 
 
 (Don't tell anyone, but I plan to rewrite it.)
 
 Andrei

What's a "so-called IEEE 754 double-extended 79-bit format"? :p
Aug 03 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:
 Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 


 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

What's a "so-called IEEE 754 double-extended 79-bit format"? :p

Heck, I didn't know until I googled for it! BTW folks, please please vote the reddit link up. It's a simple and effective way to increase exposure to D and grow the community. http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/ Andrei
Aug 03 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
 
 
 (Don't tell anyone, but I plan to rewrite it.)
 
 Andrei

Dump of thoughts as I read it: -- Personally, I've replaced "Hello, World!" in my own code with "Don't Worry, Be Happy!". Making the program whistle through the PC speaker optional. (Actually, I made that last bit up, but now I have an overwhelming urge to work out how to do it...) -- What's with all the quote marks in the heights example? I... OOOH... feet and inches. Out of interest, is it correct to replace "''" with "\""? Also, maybe put " cm" on the end of the line. -- Why immutable and not enum? They're not only unlikely to change, they don't need to be stored in the program. -- Re: writefln example. I thought integers were %d, not %i. -- "Assigning to arr.length reallocates the array." Shouldn't that be something along the lines of "Assigning to arr.length reallocates the array if you try to make it larger."? -- "by setting to write a binarySearch" -- "by setting" doesn't really parse. -- "in D, the semantics of a module-level symbol never depends on its relative ordering with others." HAHAHAHAHAHAHA! Oh, that's a good one. Glad to see you have a sense of humour. :D -- What is freqs.keys if not an array? (You call array on it, indication that it puts it in "array format", but don't explain what would happen if you don't do that.) -- startsWith and tolower have inconsistent capitalisation. Just sayin', is all. :) -- Following the style guide, shouldn't "postprocess" be "postProcess". Everyone's free to use whatever style they like, but since this is the "official" book, I just wonder if it should follow the guide. -- I realise it's a simple example, but wouldn't double.inf or, better yet, double.nan, be a more appropriate initialiser? double.inf is the absolute largest value you could possibly get (imagine the input contains an exceedingly large value that overflows to inf; the output is no longer accurate.) double.nan is even better because unless the input is malformed, you can't get it. Of course, then you need to be a little trickier in how you write your test; if (!(x >= min)) { min = x; } should do it. Then again, this requires you to explain wtf is going on... :P -- You don't indicate what enforce does. Closing thoughts: I like it. It's easy to read and well-written.
Aug 03 2009
next sibling parent reply Sam Hu <samhudotsamhu gmail.com> writes:
Sorry for my stepping in,but as a beginner in D ,I think maybe you( all of you
experts) have interest to hear what he think after he read the book:This is
really really great!Thank you so much for your great job!

Here a couple of questions regarding first chapter:
1.foreach (line; stdin.byLine) {
  Did not mention how to read data from file  *hamlet.txt* to the analyse.If I
want to run the test case,I don't know how.
2. foreach (word; splitter(strip(line))) {
     2.1 what's the purpose of splitter(strip(line)) ,I can guess a bit but not
sure;
  2.2 In the first place you used split,after that you use splitter;
3.string[] words = array(freqs.keys);
  what's array? I can not find it from phobos,was I missing something?If
yes,please forgive me.
4.sort!((a, b) { return freqs[a] > freqs[b]; })(words);
 cann't get compiled under dmd 2.031.
5.abstract class IncrementalStat : Stat {...}
  Why need this extra abstract class which derived from interface Stat?For
class Max,Min and AVG,does't it  work fine just implementing the Stat?For a
beginner,it confused me a lot.I think it would be much better to explain more
here. 

At the very begining,I am typing while reading to test all the impressive
examples,but very quicky I found I am lost starting at the point of my
qestion#1-4.So finally I gave up to test the example,just read.This is my
experience.

Thank you again and best regards,
Sam
Aug 04 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sam Hu wrote:
 Sorry for my stepping in,but as a beginner in D ,I think maybe you( all of you
experts) have interest to hear what he think after he read the book:This is
really really great!Thank you so much for your great job!

Thanks, Sam. I saved your comments and will modify the book accordingly. To get you going:
 Here a couple of questions regarding first chapter:
 1.foreach (line; stdin.byLine) {
   Did not mention how to read data from file  *hamlet.txt* to the analyse.If I
want to run the test case,I don't know how.

You'd need to input it in the command line with "<", e.g. progname < hamlet.txt.
 2. foreach (word; splitter(strip(line))) {
      2.1 what's the purpose of splitter(strip(line)) ,I can guess a bit but
not sure;
   2.2 In the first place you used split,after that you use splitter;

split() splits a string by whitespace in one operation. splitter() does the same, but lazily - one at a time, as you go through the foreach loop. The advantage of the latter is that it does not require temporary storage.
 3.string[] words = array(freqs.keys);
   what's array? I can not find it from phobos,was I missing something?If
yes,please forgive me.

It's in std.array (added fairly recently).
 4.sort!((a, b) { return freqs[a] > freqs[b]; })(words);
  cann't get compiled under dmd 2.031.

Walter!!! This has worked on and off like forever. One day I'll break into Walter's house and etch that code onto his LCD monitor.
 5.abstract class IncrementalStat : Stat {...}
   Why need this extra abstract class which derived from interface Stat?For
class Max,Min and AVG,does't it  work fine just implementing the Stat?For a
beginner,it confused me a lot.I think it would be much better to explain more
here. 

Will do.
 At the very begining,I am typing while reading to test all the impressive
examples,but very quicky I found I am lost starting at the point of my
qestion#1-4.So finally I gave up to test the example,just read.This is my
experience.
 
 Thank you again and best regards,
 Sam

Thanks, Sam. Andrei
Aug 04 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:
 
 Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/


 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

Dump of thoughts as I read it:

Awesome! Recorded. Hey I thought you gave up on D ;o). Thanks mate, Andrei
Aug 03 2009
prev sibling next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
"The compiler allows omitting type declarations only when types can be
unambiguously inferred from context."

That's not exactly true, is it? A small non-negative integer literal could
be an integer of any width or signedness. Yet 'int' is arbitrarily chosen
for some reason. There are also multiple floating point types.

My points:
* The line I quoted is incorrect. Int/float literals are not unambiguous.
* D literals can have a suffix specifying the exact type. Perhaps that's
worth mentioning.

I find your style of writing a bit too informal, though easy to read.

-- 
Michiel Helvensteijn
Aug 04 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michiel Helvensteijn wrote:
 "The compiler allows omitting type declarations only when types can be
 unambiguously inferred from context."
 
 That's not exactly true, is it? A small non-negative integer literal could
 be an integer of any width or signedness. Yet 'int' is arbitrarily chosen
 for some reason. There are also multiple floating point types.
 
 My points:
 * The line I quoted is incorrect. Int/float literals are not unambiguous.
 * D literals can have a suffix specifying the exact type. Perhaps that's
 worth mentioning.

Thanks for your comments, I added them to my todo list.
 I find your style of writing a bit too informal, though easy to read.

I swear I was trying to keep wit down. (I mean if I'm left to my own devices... "The Case for D".) One very real problem I'm now experiencing is that I need to literally write a doctoral thesis at day and a book at night. It's often difficult to handle the swing between the required styles. On the upside, heck, I think the dissertation will turn out to be one of the more readable ones :o). Andrei
Aug 04 2009
prev sibling next sibling parent reply Jos van Uden <jvu nospam.nl> writes:
Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 
 
 
 (Don't tell anyone, but I plan to rewrite it.)
 
 Andrei

This doesn't compile: string[] words = split(strip(line)); it has to be string[] words = split(strip(line.idup)); I like the way you write, it's amusing. And most of the time, you explain things well. But many of the code examples you provide don't compile or don't give correct results (I also had this problem with the Dr. Dobbs article). That makes me wonder if you actually test them or just write them off the top of your head? Jos
Aug 09 2009
next sibling parent Jos van Uden <jvu nospam.nl> writes:
Jos van Uden wrote:
 Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 


 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

This doesn't compile: string[] words = split(strip(line)); it has to be string[] words = split(strip(line.idup)); I like the way you write, it's amusing. And most of the time, you explain things well. But many of the code examples you provide don't compile or don't give correct results (I also had this problem with the Dr. Dobbs article). That makes me wonder if you actually test them or just write them off the top of your head?

Right. It's explained later in the chapter. I hadn't gotten that far yet, got stuck trying to compile code that wouldn't. I guess I'm not supposed to do that. Jos
Aug 09 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jos van Uden wrote:
 Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 


 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

This doesn't compile: string[] words = split(strip(line)); it has to be string[] words = split(strip(line.idup)); I like the way you write, it's amusing. And most of the time, you explain things well. But many of the code examples you provide don't compile or don't give correct results (I also had this problem with the Dr. Dobbs article). That makes me wonder if you actually test them or just write them off the top of your head?

Apologies for the low quality of code samples. I've recently wrote a script that extracts all snippets from the book, compiles them and runs them automatically, and possibly compare output against the expected output. Currently not all snippets can compile. Walter and I are working on that. I'll add the necessary warning in the next TDPL draft. Thanks for letting me know about the strip problem. Andrei
Aug 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Sun, Aug 9, 2009 at 9:34 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jos van Uden wrote:
 Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/

 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

string[] words = split(strip(line)); it has to be string[] words = split(strip(line.idup)); I like the way you write, it's amusing. And most of the time, you explain things well. But many of the code examples you provide don't compile or don't give correct results (I also had this problem with the Dr. Dobbs article). That makes me wonder if you actually test them or just write them off the top of your head?

that extracts all snippets from the book, compiles them and runs them automatically, and possibly compare output against the expected output. Currently not all snippets can compile. Walter and I are working on that. I'll add the necessary warning in the next TDPL draft. Thanks for letting me know about the strip problem.

http://d.puremagic.com/issues/show_bug.cgi?id=3132 It's also arguable that all functions in std.string should take const(char)[]. Or, you know, const(T)[], since D supports encodings other than UTF-8, despite what std.string leads you to believe.

Yah, I think they should all be parameterized so they can work with various character widths and even encodings. Andrei
Aug 09 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 It's also arguable that all functions in std.string should take
 const(char)[]. Or, you know, const(T)[], since D supports encodings
 other than UTF-8, despite what std.string leads you to believe.

Yah, I think they should all be parameterized so they can work with various character widths and even encodings.

But shouldn't they work with *ranges* in general, a string being only a specific case? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 09 2009
next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
Michel Fortin wrote:

 On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:
 
 It's also arguable that all functions in std.string should take
 const(char)[]. Or, you know, const(T)[], since D supports encodings
 other than UTF-8, despite what std.string leads you to believe.

Yah, I think they should all be parameterized so they can work with various character widths and even encodings.

But shouldn't they work with *ranges* in general, a string being only a specific case?

I can give at least one example of this, I wrote some java code a while back and wanted t use string functions like findSubstring (wahtever its called) but my data was an array of bytes, as i could not convert the bytes to a string (possibly unknown encoding) i could not use the string functions even if they work on any type of values. If the string functions would work like subrange in this example i could use any range of values as a string (if i'm not missunderstanding it a string in teoretical computer siences is just a sequence of symbols). The same can be said of any string algorithm that does not specifically handle encodings.
Aug 09 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Johan Granberg wrote:
 Michel Fortin wrote:
 
 On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 It's also arguable that all functions in std.string should take
 const(char)[]. Or, you know, const(T)[], since D supports encodings
 other than UTF-8, despite what std.string leads you to believe.

various character widths and even encodings.

specific case?

I can give at least one example of this, I wrote some java code a while back and wanted t use string functions like findSubstring (wahtever its called) but my data was an array of bytes, as i could not convert the bytes to a string (possibly unknown encoding) i could not use the string functions even if they work on any type of values. If the string functions would work like subrange in this example i could use any range of values as a string (if i'm not missunderstanding it a string in teoretical computer siences is just a sequence of symbols). The same can be said of any string algorithm that does not specifically handle encodings.

Yes, perfect. And even those that do handle encodings could abstract things away by e.g. acknowledging that in certain modes of iteration one unit of interest is one ore more units of encoding. Andrei
Aug 09 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 It's also arguable that all functions in std.string should take
 const(char)[]. Or, you know, const(T)[], since D supports encodings
 other than UTF-8, despite what std.string leads you to believe.

Yah, I think they should all be parameterized so they can work with various character widths and even encodings.

But shouldn't they work with *ranges* in general, a string being only a specific case?

That's true as well! In my dreams, me and the famous actress... oh wait, wrong dream. In my dreams, I eliminate std.string and put all of its algorithms, properly generalized, in std.algorithm, to work on more than just arrays, and more than just characters. Andrei
Aug 09 2009
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-08-09 14:10:10 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 But shouldn't they work with *ranges* in general, a string being only a 
 specific case?

That's true as well! In my dreams, me and the famous actress... oh wait, wrong dream. In my dreams, I eliminate std.string and put all of its algorithms, properly generalized, in std.algorithm, to work on more than just arrays, and more than just characters.

And what is preventing the dream from comming true, I mean, the one about string functions? Is there someone who doesn't want this? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2009-08-09 14:10:10 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 But shouldn't they work with *ranges* in general, a string being only 
 a specific case?

That's true as well! In my dreams, me and the famous actress... oh wait, wrong dream. In my dreams, I eliminate std.string and put all of its algorithms, properly generalized, in std.algorithm, to work on more than just arrays, and more than just characters.

And what is preventing the dream from comming true, I mean, the one about string functions? Is there someone who doesn't want this?

1. Time. 2. It would break a lot of code that uses strings (I know, not a very strong argument.) Time is the main issue. Andrei
Aug 09 2009
parent Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 09 Aug 2009 16:10:38 -0500, Andrei Alexandrescu wrote:

 Michel Fortin wrote:
 On 2009-08-09 14:10:10 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 But shouldn't they work with *ranges* in general, a string being only 
 a specific case?

That's true as well! In my dreams, me and the famous actress... oh wait, wrong dream. In my dreams, I eliminate std.string and put all of its algorithms, properly generalized, in std.algorithm, to work on more than just arrays, and more than just characters.

And what is preventing the dream from comming true, I mean, the one about string functions? Is there someone who doesn't want this?

1. Time. 2. It would break a lot of code that uses strings (I know, not a very strong argument.) Time is the main issue.

std.string could stay as a compatibility wrapper around std.algorithm. Though this puts even more stress on the "Time" concern.
Aug 10 2009
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:
 Michel Fortin wrote:
 On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 It's also arguable that all functions in std.string should take
 const(char)[]. Or, you know, const(T)[], since D supports encodings
 other than UTF-8, despite what std.string leads you to believe.

Yah, I think they should all be parameterized so they can work with various character widths and even encodings.

But shouldn't they work with *ranges* in general, a string being only a specific case?

That's true as well! In my dreams, me and the famous actress... oh wait, wrong dream. In my dreams, I eliminate std.string and put all of its algorithms, properly generalized, in std.algorithm, to work on more than just arrays, and more than just characters. Andrei

How do you define 'tolower' on non-characters?
Aug 09 2009
next sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Daniel Keep Wrote:

 
 
 Andrei Alexandrescu wrote:
 Michel Fortin wrote:
 On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 It's also arguable that all functions in std.string should take
 const(char)[]. Or, you know, const(T)[], since D supports encodings
 other than UTF-8, despite what std.string leads you to believe.

Yah, I think they should all be parameterized so they can work with various character widths and even encodings.

But shouldn't they work with *ranges* in general, a string being only a specific case?

That's true as well! In my dreams, me and the famous actress... oh wait, wrong dream. In my dreams, I eliminate std.string and put all of its algorithms, properly generalized, in std.algorithm, to work on more than just arrays, and more than just characters. Andrei

How do you define 'tolower' on non-characters?

You don't, character-specific functions can test for the element type to be a character type, be it an array or a range. If you want to use tolower with a non-character array, you have to cast it to a string type.
Aug 09 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:
 
 Andrei Alexandrescu wrote:
 Michel Fortin wrote:
 On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 It's also arguable that all functions in std.string should take
 const(char)[]. Or, you know, const(T)[], since D supports encodings
 other than UTF-8, despite what std.string leads you to believe.

various character widths and even encodings.

a specific case?

wrong dream. In my dreams, I eliminate std.string and put all of its algorithms, properly generalized, in std.algorithm, to work on more than just arrays, and more than just characters. Andrei

How do you define 'tolower' on non-characters?

That and others would remain specific for characters. I do help to be able to abstract functions such as e.g. strip(). Andrei
Aug 09 2009
parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Daniel Keep wrote:
 Andrei Alexandrescu wrote:
 Michel Fortin wrote:
 On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 It's also arguable that all functions in std.string should take
 const(char)[]. Or, you know, const(T)[], since D supports encodings
 other than UTF-8, despite what std.string leads you to believe.

various character widths and even encodings.

a specific case?

wrong dream. In my dreams, I eliminate std.string and put all of its algorithms, properly generalized, in std.algorithm, to work on more than just arrays, and more than just characters. Andrei

How do you define 'tolower' on non-characters?

That and others would remain specific for characters. I do help to be able to abstract functions such as e.g. strip(). Andrei

How would you generalize the string functions into ordinary array functions while still taking into account the different character types? For example... dchar needle = 'f'; char[] haystack = "abcdefg"; auto index = haystack.indexOf(needle); That code is roughly equivalent to this code for generalized arrays, which seems reasonable enough... float needle = 2.0; double[] haystack = [ 1.0, 2.0, 3.0 ]; auto index = haystack.indexOf(needle); ...since "float" is implicitly castable to "double". But the string example has weird monkey-business going on under the covers, since dchar is wider than char, and therefore a single dchar element might consume multiple slots within the char[] array. Are there any analogous examples of that behavior with other types, where you'd search for a single element striding multiple indexes within an array of narrower values? --benji
Aug 10 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:
 Andrei Alexandrescu wrote:
 Daniel Keep wrote:
 Andrei Alexandrescu wrote:
 Michel Fortin wrote:
 On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 It's also arguable that all functions in std.string should take
 const(char)[]. Or, you know, const(T)[], since D supports encodings
 other than UTF-8, despite what std.string leads you to believe.

various character widths and even encodings.

a specific case?

wait, wrong dream. In my dreams, I eliminate std.string and put all of its algorithms, properly generalized, in std.algorithm, to work on more than just arrays, and more than just characters. Andrei

How do you define 'tolower' on non-characters?

That and others would remain specific for characters. I do help to be able to abstract functions such as e.g. strip(). Andrei

How would you generalize the string functions into ordinary array functions while still taking into account the different character types? For example... dchar needle = 'f'; char[] haystack = "abcdefg"; auto index = haystack.indexOf(needle); That code is roughly equivalent to this code for generalized arrays, which seems reasonable enough... float needle = 2.0; double[] haystack = [ 1.0, 2.0, 3.0 ]; auto index = haystack.indexOf(needle); ...since "float" is implicitly castable to "double". But the string example has weird monkey-business going on under the covers, since dchar is wider than char, and therefore a single dchar element might consume multiple slots within the char[] array. Are there any analogous examples of that behavior with other types, where you'd search for a single element striding multiple indexes within an array of narrower values? --benji

Great question. I plan to add a range ByCharacter and a function byCharacter that spans a string one dchar at a time. Actually I have the implementation already, haven't checked it in yet. That's a bidirectional range. In that approach, if you write: char[] haystack = "abcdefg"; auto pos = find(haystack, needle); the search is done with the usual array semantics, but if you say: char[] haystack = "abcdefg"; auto pos = find(byCharacter(haystack), needle); then a dchar-at-a-time search is performed. This idea is raw, so improvements are welcome. Andrei
Aug 10 2009
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Daniel Keep wrote:
 How do you define 'tolower' on non-characters?

How do you define it for characters? I -> ı or I -> i? 'tolower' is a complicated, locale-dependent operation, not at all analogous to finding a substring. It belongs in a different part of the library or in a different library altogether. -- Rainer Deyke - rainerd eldwood.com
Aug 09 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Aug 9, 2009 at 9:34 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jos van Uden wrote:
 Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/

 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

This doesn't compile: string[] words = split(strip(line)); it has to be string[] words = split(strip(line.idup)); I like the way you write, it's amusing. And most of the time, you explain things well. But many of the code examples you provide don't compile or don't give correct results (I also had this problem with the Dr. Dobbs article). That makes me wonder if you actually test them or just write them off the top of your head?

Apologies for the low quality of code samples. I've recently wrote a script that extracts all snippets from the book, compiles them and runs them automatically, and possibly compare output against the expected output. Currently not all snippets can compile. Walter and I are working on that. I'll add the necessary warning in the next TDPL draft. Thanks for letting me know about the strip problem.

http://d.puremagic.com/issues/show_bug.cgi?id=3132 It's also arguable that all functions in std.string should take const(char)[]. Or, you know, const(T)[], since D supports encodings other than UTF-8, despite what std.string leads you to believe.
Aug 09 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 03 Aug 2009 18:00:59 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/

 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

Wow, my head's spinning :) That's a lot of data/concepts in one chapter. Have you considered how this chapter will be for a newbie programmer? Not a programmer that comes from C or Java or Python or whatever, but someone who's starting with a blank slate? I noticed you gloss over a lot of details. For example: "The operators and their precedence are much like the ones you'd find in D's sibling languages: '+', '-', '*', '/', and '%' for basic arithmetic, '==', '!=', '<', '>', '<=', '>=' for comparisons, fun(argument1, argument2) for function calls, and so on." A new-to-programming person is going to be baffled by some of that, such as % for basic arithmethic, and == and != for comparisons. I understand this is an overview, but you may want to mention that the chapter is assuming you know a programming language already (preferrably a C-like one). Or am I misunderstanding the target audience? I'd say chapter 1 should be simple enough to be understood by everyone, not just experienced programmers. It's a good overview of the language, but reads much more like a comparison with C++. It's more like a review article than an introduction to a new language. I'd call this chapter a preface and indicate its target audience, so newbies can skip right to the learning part of the book. I'm viewing this book as an equivalent to "the C programming Language" by K&R. In chapter 1, they gloss over some of the details, but not nearly as many as you have, and the advanced concepts are to a minimum. And there is not a significant time spent explaining how it relates to predecessor languages. *disclaimer: I'm not an expert on teaching or writing books. Just my 2 cents. -Steve
Aug 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Mon, 03 Aug 2009 18:00:59 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 


 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

Wow, my head's spinning :) That's a lot of data/concepts in one chapter. Have you considered how this chapter will be for a newbie programmer?

Like K&R, TDPL is intended for people who already know how to program in another language. Knowledge of a specific language is not recommended or required. The preface will make that clear. Some reviewers are still concerned that I discuss topics a bit too advanced in the first chapter. I was suggested to adapt The Case for D instead of this first chapter.
 *disclaimer: I'm not an expert on teaching or writing books.

Well you are an expert on reading books and that's what matters here. Andrei
Aug 10 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Andrei Alexandrescu Wrote:

 Steven Schveighoffer wrote:
 On Mon, 03 Aug 2009 18:00:59 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 


 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

Wow, my head's spinning :) That's a lot of data/concepts in one chapter. Have you considered how this chapter will be for a newbie programmer?

Like K&R, TDPL is intended for people who already know how to program in another language. Knowledge of a specific language is not recommended or required. The preface will make that clear. Some reviewers are still concerned that I discuss topics a bit too advanced in the first chapter. I was suggested to adapt The Case for D instead of this first chapter.
 *disclaimer: I'm not an expert on teaching or writing books.

Well you are an expert on reading books and that's what matters here. Andrei

I agree that your preview, while being really insightful into D, is gonna make the head of beginners explode. For example, you dive rather headfirst into variables, using immutable and auto before even talking about variable types. I for one believe the market for such a book is mostly beginner to intermediate programmers. I only needed the language reference on the digitalmars website to learn about the syntax and semantics of D, and reading the code in the runtime and phobos gave more than enough examples to get comfortable using the language.
Aug 10 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Jeremie Pelletier wrote:
 Andrei Alexandrescu Wrote:
 
 Steven Schveighoffer wrote:
 On Mon, 03 Aug 2009 18:00:59 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_progra
ming_language_tdpl/ 


 (Don't tell anyone, but I plan to rewrite it.)

 Andrei

That's a lot of data/concepts in one chapter. Have you considered how this chapter will be for a newbie programmer?

another language. Knowledge of a specific language is not recommended or required. The preface will make that clear. Some reviewers are still concerned that I discuss topics a bit too advanced in the first chapter. I was suggested to adapt The Case for D instead of this first chapter.
 *disclaimer: I'm not an expert on teaching or writing books.

Andrei

I agree that your preview, while being really insightful into D, is gonna make the head of beginners explode. For example, you dive rather headfirst into variables, using immutable and auto before even talking about variable types. I for one believe the market for such a book is mostly beginner to intermediate programmers. I only needed the language reference on the digitalmars website to learn about the syntax and semantics of D, and reading the code in the runtime and phobos gave more than enough examples to get comfortable using the language.

I think it's a hard problem: how do you write a book that's accessible to beginners without alienating experienced programmers? I'm personally of the mindset that beginners should most definitely not be attempting to learn D as their first language. Languages like D, C, C++ are horribly unsuitable because they force you to understand how the machine works before you can learn to program; except that they force you to learn to program in order to understand how the machine works. I've seen too many *university students* (and we're talking second and third year students) struggling with both because they don't quite understand how the machine works and don't quite understand how C works; the two work together to sabotage their understanding. I think something like Python or even, yes, BASIC is more appropriate because it reduces the size of the problem down to "how do I correctly sequence the actions I want the computer to perform, and how do I express those actions?" I personally don't think TDPL should worry too much about absolute beginners; they'll be better served by a different type of book for a different type of language. That, and they'll take one look at templates and run screaming. I still have trouble explaining the difference between compile-time arguments and run-time arguments to experienced programmers, let alone novices!
Aug 11 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
language_fan wrote:
 Tue, 11 Aug 2009 19:04:50 +1000, Daniel Keep thusly wrote:
 
 I'm personally of the mindset that beginners should most definitely not
 be attempting to learn D as their first language.  Languages like D, C,
 C++ are horribly unsuitable because they force you to understand how the
 machine works before you can learn to program; except that they force
 you to learn to program in order to understand how the machine works.

One way to teach languages with both high and low level concepts is to start bottom-up. Surely the high level concepts are usually built from atomic low level artifacts. This would even be a good design method for the whole language. It's much easier to reason about the language if the core is kept simple. It's also a practical way to organize your thoughts by separating the semantics from the syntax and seeing its composite nature.

It sounds good in theory, but it doesn't seem to hold up in practice.
Aug 11 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
language_fan wrote:
 Wed, 12 Aug 2009 00:06:03 +1000, Daniel Keep thusly wrote:
 
 It sounds good in theory, but it doesn't seem to hold up in practice.

Why? Has there been any non-successful attemps in this direction? Many constructs of D for which semantics can be defined with a collection of simpler constructs come to mind, e.g. foreach.

I used lowering to explain the likes of foreach and scope(xyz), with what I'd call qualified success. It doesn't simplify things as much as one would think it does. Andrei
Aug 11 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Tue, 11 Aug 2009 19:04:50 +1000, Daniel Keep thusly wrote:

 I'm personally of the mindset that beginners should most definitely not
 be attempting to learn D as their first language.  Languages like D, C,
 C++ are horribly unsuitable because they force you to understand how the
 machine works before you can learn to program; except that they force
 you to learn to program in order to understand how the machine works.

One way to teach languages with both high and low level concepts is to start bottom-up. Surely the high level concepts are usually built from atomic low level artifacts. This would even be a good design method for the whole language. It's much easier to reason about the language if the core is kept simple. It's also a practical way to organize your thoughts by separating the semantics from the syntax and seeing its composite nature.
Aug 11 2009
prev sibling parent language_fan <foo bar.com.invalid> writes:
Wed, 12 Aug 2009 00:06:03 +1000, Daniel Keep thusly wrote:

 It sounds good in theory, but it doesn't seem to hold up in practice.

Why? Has there been any non-successful attemps in this direction? Many constructs of D for which semantics can be defined with a collection of simpler constructs come to mind, e.g. foreach.
Aug 11 2009