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

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

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 Jeremie Pelletier <jeremiep gmail.com> writes:
Andrei Alexandrescu Wrote:


 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


And I always thought it was double-extended 80-bit. The IEEE standard actually
specifies >= 79 bits and Intel implements it as 80bits.

Well you learn something new everyday!
Aug 04 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Jeremie Pelletier:

And I always thought it was double-extended 80-bit. The IEEE standard actually
specifies >= 79 bits and Intel implements it as 80bits.<


But it seems there are weird differences across operating systems regarding how
much memory is allocated to represent such numbers, like 10, 12, 16 bytes on
Windows, Linux, Mac (this comes from something Walter said when he has adapted
DMD to the other OSs). Do you know why they have chosen different solutions
regarding something so basic? (I don't even want to talk about the stupid
endianess of CPUs).

Bye,
bearophile
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 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 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
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


 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.


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.


 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.


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.


 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?


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.


 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?


 
 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.


 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?


 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 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


 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.


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 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
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 reply 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
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 parent Ali Cehreli <acehreli yahoo.com> writes:
language_fan Wrote:


 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.


I agree. I am writing an online D tutorial that targets the novice programmer,
where the concepts are built from the bottom up.

I didn't think that starting with 0s and 1s was too technical for anybody:
there is electricity or not... Anyone can grasp that concept, especially when
0s and 1s are at least heard by everybody.

I think giving an explanation of 0s and 1s at the lowest level and exposing
them to the novice breaks the barriers and welcomes them to the programmers'
land; as opposed to "we will tell you that later." That would grasp the
reader... (Disclaimer too: Not tested on anyone.)

Then I explain that such an entity (bit) could only represent concepts with two
states like "heads or tails"; so the CPU provides types that can represent
more; which are still not sufficient to represent higher level concepts like "a
playing card" or "a laser gun in a computer game". Enter the programming
language...

It took me a few paragraphs to build this bottom up picture. I occasionally
still refer to the CPU when teaching a seemingly unrelated topic.

I am following the method of introducing concepts one by one with examples,
problems, and solutions. It looks great in the sandbox... ;)

Ali
Aug 16 2009