www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Use of first person in a book

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I'd decided to not use the first person at all in TDPL, but now I find 
myself a bit constrained by that decision. I personally think a small 
amount of meta-references and asides prevents boredom and brings a more 
personal note to the communication, but such devices should be used very 
sparingly and with care.

So I thought I'd ask a candid question in here. How do you feel about 
moderate use of the first person in a technical book? Do you find it 
comfortable, neutral, or cringeworthy?


Andrei
Oct 07 2009
next sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Andrei Alexandrescu wrote:
 I'd decided to not use the first person at all in TDPL, but now I find 
 myself a bit constrained by that decision. I personally think a small 
 amount of meta-references and asides prevents boredom and brings a more 
 personal note to the communication, but such devices should be used very 
 sparingly and with care.
 
 So I thought I'd ask a candid question in here. How do you feel about 
 moderate use of the first person in a technical book? Do you find it 
 comfortable, neutral, or cringeworthy?
 
 
 Andrei
I wouldn't cringe on the first person, so long as its not overused. Not using it definitely helps to set a neutral tone to the book, but a few uses of the first person here and there never hurt either. For example, when describing something its best to avoid first person, but when you give a real world example its perfectly fine to use it since it shows you have personal experience with the example. Just go with what you feel comfortable using, it usually shows when people go out of their way to try and please their audience instead of being themselves :)
Oct 07 2009
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 I'd decided to not use the first person at all in TDPL, but now I find
 myself a bit constrained by that decision. I personally think a small
 amount of meta-references and asides prevents boredom and brings a more
 personal note to the communication, but such devices should be used very
 sparingly and with care.
 So I thought I'd ask a candid question in here. How do you feel about
 moderate use of the first person in a technical book? Do you find it
 comfortable, neutral, or cringeworthy?
For anecdotes and the like, it's totally appropriate to use the first person. I think the most important thing is finding a comfortable, conversational tone, however that works out in actual diction. If that means bending the rules at times, so be it.
Oct 07 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Oct 8, 2009 at 12:04 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 I'd decided to not use the first person at all in TDPL, but now I find
 myself a bit constrained by that decision. I personally think a small amount
 of meta-references and asides prevents boredom and brings a more personal
 note to the communication, but such devices should be used very sparingly
 and with care.

 So I thought I'd ask a candid question in here. How do you feel about
 moderate use of the first person in a technical book? Do you find it
 comfortable, neutral, or cringeworthy?
I totally prefer reading something where I feel like the author is having a conversation with me, so go ahead - use it!
Oct 07 2009
parent "Saaa" <empty needmail.com> writes:
Jarrett Billingsley wrote
 On Thu, Oct 8, 2009 at 12:04 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 I'd decided to not use the first person at all in TDPL, but now I find
 myself a bit constrained by that decision. I personally think a small 
 amount
 of meta-references and asides prevents boredom and brings a more personal
 note to the communication, but such devices should be used very sparingly
 and with care.

 So I thought I'd ask a candid question in here. How do you feel about
 moderate use of the first person in a technical book? Do you find it
 comfortable, neutral, or cringeworthy?
I totally prefer reading something where I feel like the author is having a conversation with me, so go ahead - use it!
Same here.
Oct 08 2009
prev sibling next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:
 So I thought I'd ask a candid question in here. How do you feel about
 moderate use of the first person in a technical book? Do you find it
 comfortable, neutral, or cringeworthy?
Occasionally a technical author finds that a personal anecdote or opinion is useful for illustrating a concept. The author then has these choices: 1. Leave it out. 2. Treat it as a universal fact. 3. Anonymize it. 4. Talk about himself in the third person. 5. Use first person. The first three options are clearly bad because information is lost. I prefer option 5 over option 4, but both are acceptable to me. -- Rainer Deyke - rainerd eldwood.com
Oct 07 2009
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:

 So I thought I'd ask a candid question in here. How do you feel about
 moderate use of the first person in a technical book? Do you find it
 comfortable, neutral, or cringeworthy?
 
 
 Andrei
Comfortable, as long as you're not writing a Head First book. Avoiding first person too much sometimes leads to awkward and dull texts. The programming library has enough of these.
Oct 07 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
Lutger wrote:
 Andrei Alexandrescu wrote:
 
 So I thought I'd ask a candid question in here. How do you feel about
 moderate use of the first person in a technical book? Do you find it
 comfortable, neutral, or cringeworthy?


 Andrei
Comfortable, as long as you're not writing a Head First book. Avoiding first person too much sometimes leads to awkward and dull texts. The programming library has enough of these.
Yeah I also got into the habit of writing neutral comments in my code, I used to use the first person a lot and a joke here and there, sometimes cursing at microsoft for backward api designs. At what point do we lose it and become serious in code comments?
Oct 08 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycios.com> writes:
Andrei Alexandrescu:

 How do you feel about 
 moderate use of the first person in a technical book? Do you find it 
 comfortable, neutral, or cringeworthy?
I think it makes the book more like the product of a person, so I like it. I hate reading 10 research papers where most of them are written by a single person and all of them use "we can see" or "it can be seen". The first person author has become a ghost. Improving a research paper, or science, doesn't imply removing anything human. Using first person isn't synonym of bad science. Bye, bearophile
Oct 08 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
bearophile wrote:
 Andrei Alexandrescu:
 
 How do you feel about 
 moderate use of the first person in a technical book? Do you find it 
 comfortable, neutral, or cringeworthy?
I think it makes the book more like the product of a person, so I like it. I hate reading 10 research papers where most of them are written by a single person and all of them use "we can see" or "it can be seen". The first person author has become a ghost. Improving a research paper, or science, doesn't imply removing anything human. Using first person isn't synonym of bad science. Bye, bearophile
I totally agree with you here bearophile, even in high school for certain forms of texts they told us to never use the first person, this went on all the way up to college and we never were told why its bad. I really hate that teaching method of "do this, don't ask why." Maybe because using the first person sounds closer to faith than fact. But such enforcements are closer to what religion would do than science, so its really confusing in the end. What the first person does to me is make it easier to make links with authors since it makes it much easier to convey emotion, the third person just sounds like a robot making statements. I know there isn't much room for emotions in programming books as opposed to the general roman, but there is still a lot of passion to convey, programming IS an art after all! I guess it just goes in the ever growing bag of rules we all blindly apply and never understand why. For one, I couldn't imagine this newsgroup if the first-person was banned from use :)
Oct 08 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Oct 8, 2009 at 10:50 AM, Jeremie Pelletier <jeremiep gmail.com> wrote:

 What the first person does to me is make it easier to make links with
 authors since it makes it much easier to convey emotion, the third person
 just sounds like a robot making statements. I know there isn't much room for
 emotions in programming books as opposed to the general roman, but there is
 still a lot of passion to convey, programming IS an art after all!
I think why's Poignant Guide to Ruby seriously bucks THAT trend ;) Of course why just up and deleted everything a month or two ago, so getting your hands on it isn't quite as easy as it once was..
Oct 08 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Thu, Oct 8, 2009 at 10:50 AM, Jeremie Pelletier <jeremiep gmail.com> wrote:
 
 What the first person does to me is make it easier to make links with
 authors since it makes it much easier to convey emotion, the third person
 just sounds like a robot making statements. I know there isn't much room for
 emotions in programming books as opposed to the general roman, but there is
 still a lot of passion to convey, programming IS an art after all!
I think why's Poignant Guide to Ruby seriously bucks THAT trend ;) Of course why just up and deleted everything a month or two ago, so getting your hands on it isn't quite as easy as it once was..
(For those not in the know: if you have trouble parsing the above sentences, please note that "why" is actually used as a proper noun. It's the self-chosen nickname of a former Ruby big wig.) I think I need to give a read to that book, although I've heard it's rather controversial due to the gratuitous sexual references. Andrei
Oct 08 2009
next sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Andrei Alexandrescu wrote:
 Jarrett Billingsley wrote:
 On Thu, Oct 8, 2009 at 10:50 AM, Jeremie Pelletier 
 <jeremiep gmail.com> wrote:

 What the first person does to me is make it easier to make links with
 authors since it makes it much easier to convey emotion, the third 
 person
 just sounds like a robot making statements. I know there isn't much 
 room for
 emotions in programming books as opposed to the general roman, but 
 there is
 still a lot of passion to convey, programming IS an art after all!
I think why's Poignant Guide to Ruby seriously bucks THAT trend ;) Of course why just up and deleted everything a month or two ago, so getting your hands on it isn't quite as easy as it once was..
(For those not in the know: if you have trouble parsing the above sentences, please note that "why" is actually used as a proper noun. It's the self-chosen nickname of a former Ruby big wig.) I think I need to give a read to that book, although I've heard it's rather controversial due to the gratuitous sexual references. Andrei
Controversy is sometimes good for its free publicity. Besides if people get offended by what they read, its their own fault, not the author's.
Oct 08 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Oct 8, 2009 at 12:37 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Oct 8, 2009 at 10:50 AM, Jeremie Pelletier <jeremiep gmail.com>
 wrote:

 What the first person does to me is make it easier to make links with
 authors since it makes it much easier to convey emotion, the third person
 just sounds like a robot making statements. I know there isn't much room
 for
 emotions in programming books as opposed to the general roman, but there
 is
 still a lot of passion to convey, programming IS an art after all!
I think why's Poignant Guide to Ruby seriously bucks THAT trend ;) Of course why just up and deleted everything a month or two ago, so getting your hands on it isn't quite as easy as it once was..
(For those not in the know: if you have trouble parsing the above sentences, please note that "why" is actually used as a proper noun. It's the self-chosen nickname of a former Ruby big wig.) I think I need to give a read to that book, although I've heard it's rather controversial due to the gratuitous sexual references.
Sexual references? I don't know if it was ever finished - I only managed to get hold of it after he disappeared, and it was only the first.. 5 or 6 chapters - but I didn't encounter any sexual references. At least I don't remember any. I was in no short supply of incongruous whimsical humor though :)
Oct 08 2009
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Jeremie Pelletier wrote:

 bearophile wrote:
 Andrei Alexandrescu:
 
 How do you feel about
 moderate use of the first person in a technical book? Do you find it
 comfortable, neutral, or cringeworthy?
I think it makes the book more like the product of a person, so I like it. I hate reading 10 research papers where most of them are written by a single person and all of them use "we can see" or "it can be seen". The first person author has become a ghost. Improving a research paper, or science, doesn't imply removing anything human. Using first person isn't synonym of bad science. Bye, bearophile
I totally agree with you here bearophile, even in high school for certain forms of texts they told us to never use the first person, this went on all the way up to college and we never were told why its bad. I really hate that teaching method of "do this, don't ask why." Maybe because using the first person sounds closer to faith than fact. But such enforcements are closer to what religion would do than science, so its really confusing in the end.
It is the old school image of science as objectivity, where this means that there is no subject: the author should be interchangeable for any competent scientist because texts are produced by methods, not authors. These days such a view is often regarded as a form of faith, and indeed some philosophers see this idea of science as a late incarnation of theism.
 What the first person does to me is make it easier to make links with
 authors since it makes it much easier to convey emotion, the third
 person just sounds like a robot making statements. I know there isn't
 much room for emotions in programming books as opposed to the general
 roman, but there is still a lot of passion to convey, programming IS an
 art after all!
 
 I guess it just goes in the ever growing bag of rules we all blindly
 apply and never understand why. For one, I couldn't imagine this
 newsgroup if the first-person was banned from use :)
The texts I find most inspirational are mostly witty or lively in one way or another, even if they are very technical. I believe it is because the author is passionate about the subject and cannot help but convey the pleasure they take in it.
Oct 08 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Oct 8, 2009 at 4:30 PM, Lutger <lutger.blijdestijn gmail.com> wrote:

 I guess it just goes in the ever growing bag of rules we all blindly
 apply and never understand why. For one, I couldn't imagine this
 newsgroup if the first-person was banned from use :)
The texts I find most inspirational are mostly witty or lively in one way or another, even if they are very technical. I believe it is because the author is passionate about the subject and cannot help but convey the pleasure they take in it.
Precisely. For the very same reason, those same people make excellent lecturers and professors.
Oct 08 2009
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Lutger wrote:
 Jeremie Pelletier wrote:
 
 bearophile wrote:
 Andrei Alexandrescu:

 How do you feel about
 moderate use of the first person in a technical book? Do you find it
 comfortable, neutral, or cringeworthy?
I think it makes the book more like the product of a person, so I like it. I hate reading 10 research papers where most of them are written by a single person and all of them use "we can see" or "it can be seen". The first person author has become a ghost. Improving a research paper, or science, doesn't imply removing anything human. Using first person isn't synonym of bad science. Bye, bearophile
I totally agree with you here bearophile, even in high school for certain forms of texts they told us to never use the first person, this went on all the way up to college and we never were told why its bad. I really hate that teaching method of "do this, don't ask why." Maybe because using the first person sounds closer to faith than fact. But such enforcements are closer to what religion would do than science, so its really confusing in the end.
It is the old school image of science as objectivity, where this means that there is no subject: the author should be interchangeable for any competent scientist because texts are produced by methods, not authors. These days such a view is often regarded as a form of faith, and indeed some philosophers see this idea of science as a late incarnation of theism.
Interesting. As I read this thread I conjectured that this rule was to help newbie authors avoid pitfalls that are easier to hit if they use first person. I'm at a loss for examples. And even if this were so, I'd much rather my educators had just trained me how to better avoid the pitfalls. Perhaps excessive use of first person makes an article/book read more like a story. Perhaps that's not really a bad thing. It amuses me to see this thread where so many professionals and well-educated peers are chiming in and rejecting this dogma. I never would have expected it to be so unanimous.
Oct 08 2009
parent "Nick Sabalausky" <a a.a> writes:
"Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message 
news:hambm5$uk7$1 digitalmars.com...
 Interesting.

 As I read this thread I conjectured that this rule was to help newbie
 authors avoid pitfalls that are easier to hit if they use first person.
   I'm at a loss for examples.  And even if this were so, I'd much
 rather my educators had just trained me how to better avoid the pitfalls.

 Perhaps excessive use of first person makes an article/book read more
 like a story.  Perhaps that's not really a bad thing.

 It amuses me to see this thread where so many professionals and
 well-educated peers are chiming in and rejecting this dogma.  I never
 would have expected it to be so unanimous.
I suspect it may largely be because all the fundamentalism-over-pragmatism types are over at the Java, Smalltalk and Haskell scenes. ;)
Oct 08 2009
prev sibling next sibling parent Ali Cehreli <acehreli yahoo.com> writes:
I use first person when I make side notes like

- "I've chosen to do it this way, because ..."

- "I will deviate from my decision of not using any feature that is not yet
explained ..."

- "Because of a bug in Phobos, I had to use the .dup property with the format
strings in the following samples. I will remove the .dups when that bug gets
fixed."*

Ali

* That bug: http://d.puremagic.com/issues/show_bug.cgi?id=3363
Oct 08 2009
prev sibling next sibling parent reply JMNorris <nospam nospam.com> writes:
I once had a student in a college course ask me if he was permited to
use the first person in a term paper.  Ugh.  I heard a rumor that the
Education  Dept. at my school would automatically give an F for the use
of "I".  Education Departments are generally the academically weakest in
any university.  "I" is better than the royal "we", and "the author" is
downright stilted.  Note that the royal "we" is still first person, just
not singular. 

I regard the first person singular as a problem akin to (but less
serious than) that of passive voice:  it's nice to minimize it, but
there is no reason to be a teetotaler about it. 

IIRC, K&R did not used "I", "we", or "the authors".  K&R were geniuses
(even if they indent 8 instead of 4 spaces).  There is a reason they are
so rarely matched in technical writing:  genius is a rare commodity. 

JMNorris
Oct 08 2009
next sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
JMNorris wrote:
 genius is a rare commodity. 
I grew up believing that everyone has genius in them waiting to awaken, most of us just stop searching for it. I still believe it to this day. Jeremie
Oct 08 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
JMNorris wrote:
 IIRC, K&R did not used "I", "we", or "the authors".  K&R were geniuses
 (even if they indent 8 instead of 4 spaces).  There is a reason they are
 so rarely matched in technical writing:  genius is a rare commodity. 
While K&R's book is genius, I'd be hesitant to say it is because they didn't use "I". Feynman uses "I" and "we" a lot in his technical books and he's a genius.
Oct 08 2009
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
JMNorris wrote:
 I once had a student in a college course ask me if he was permited to
 use the first person in a term paper.  Ugh.  I heard a rumor that the
 Education  Dept. at my school would automatically give an F for the use
 of "I".  Education Departments are generally the academically weakest in
 any university.  "I" is better than the royal "we", and "the author" is
 downright stilted.  Note that the royal "we" is still first person, just
 not singular. 
I think that, in most cases, the author is using "we" to mean "you and I", i.e. the author and the reader. I like that -- it makes me feel like the author is saying "come on, walk with me while I explain this". I would most definitely cringe if I ever read a research paper in my own field, theoretical physics, that was written in first person singular. Author: "After performing the above transformation, I can now write the Lagrangian density as ..." Me: "Hey, wait a minute! YOU write the Lagrangian like that? What about me, can't I do that too? Are we talking mathematics here, or are we discussing your personal preference in Lagrangians?" For experimental papers I'd find it more acceptable, as they to a larger extent describe the author's personal experience, which is not necessarily reproducible by others. On the other hand, papers in experimental sciences tend to have dozens of authors and co-authors anyway, so the plural "we" is still the appropriate thing to use. ^^ For educational books like Andrei's I like the first person singular style, as long as it's not overused. -Lars
Oct 09 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Thanks to all who answered! I wish there was such consensus in other 
matters as well :o).

Allow me to put forth an excerpt from TDPL without any particular 
reason: http://erdani.com/tdpl/excerpt.pdf


Andrei
Oct 09 2009
next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Thanks to all who answered! I wish there was such consensus in other 
 matters as well :o).
 
 Allow me to put forth an excerpt from TDPL without any particular 
 reason: http://erdani.com/tdpl/excerpt.pdf
 
 
 Andrei
 
Nice! Humourous typo: Near the last page "online assembler" should be "inline assembler". Thought it's true that online asm is forbidden too...
Oct 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Thanks to all who answered! I wish there was such consensus in other 
 matters as well :o).

 Allow me to put forth an excerpt from TDPL without any particular 
 reason: http://erdani.com/tdpl/excerpt.pdf


 Andrei
Nice! Humourous typo: Near the last page "online assembler" should be "inline assembler". Thought it's true that online asm is forbidden too...
Ha ha, now that's some involuntary humor. Thanks, Don! Also thanks for the patches that make the code in the book work :o). Andrei
Oct 09 2009
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Fri, Oct 09, 2009 at 11:33:35AM -0500, Andrei Alexandrescu wrote:
Humourous typo: Near the last page "online assembler" should be "inline 
assembler". Thought it's true that online asm is forbidden too...
Ha ha, now that's some involuntary humor. Thanks, Don! Also thanks for the patches that make the code in the book work :o).
Off topic, but one day a few years back, I did a quick hello world CGI program in assembly just for laughs: http://arsdnet.net/cgi-bin/a.out You'd be amazed at how many web people were freaked out by the very idea! -- Adam D. Ruppe http://arsdnet.net
Oct 09 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.159.1255130283.20261.digitalmars-d puremagic.com...
 On Fri, Oct 09, 2009 at 11:33:35AM -0500, Andrei Alexandrescu wrote:
Humourous typo: Near the last page "online assembler" should be "inline
assembler". Thought it's true that online asm is forbidden too...
Ha ha, now that's some involuntary humor. Thanks, Don! Also thanks for the patches that make the code in the book work :o).
Off topic, but one day a few years back, I did a quick hello world CGI program in assembly just for laughs: http://arsdnet.net/cgi-bin/a.out
That's awesome :) Speaking of things being implemented in unlikely langauges, ever see the high-precision PI computator written in MS batch? http://thedailywtf.com/Articles/Stupid-Coding-Tricks-A-Batch-of-Pi.aspx
 You'd be amazed at how many web people were freaked out by the very idea!
Considering most of the "web developers" I've had the misfortune to work with, you'd be amazed just how unamazed I am at those reactions ;)
Oct 09 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
Nick Sabalausky wrote:
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:mailman.159.1255130283.20261.digitalmars-d puremagic.com...
 On Fri, Oct 09, 2009 at 11:33:35AM -0500, Andrei Alexandrescu wrote:
 Humourous typo: Near the last page "online assembler" should be "inline
 assembler". Thought it's true that online asm is forbidden too...
Ha ha, now that's some involuntary humor. Thanks, Don! Also thanks for the patches that make the code in the book work :o).
Off topic, but one day a few years back, I did a quick hello world CGI program in assembly just for laughs: http://arsdnet.net/cgi-bin/a.out
That's awesome :)
It really is, the code is really elegant too!
 Speaking of things being implemented in unlikely langauges, ever see the 
 high-precision PI computator written in MS batch?
 http://thedailywtf.com/Articles/Stupid-Coding-Tricks-A-Batch-of-Pi.aspx
I love the name of the site, it just screams funny.
 You'd be amazed at how many web people were freaked out by the very idea!
Considering most of the "web developers" I've had the misfortune to work with, you'd be amazed just how unamazed I am at those reactions ;)
Same here, the worst code and "developers" I've seen were at jobs I had, from people straight out of computer science. I've seen code so backwards it made me want to bash my head on the nearest wall to ease the pain :)
Oct 09 2009
prev sibling next sibling parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrei Alexandrescu wrote:
 Thanks to all who answered! I wish there was such consensus in other
 matters as well :o).
 
 Allow me to put forth an excerpt from TDPL without any particular
 reason: http://erdani.com/tdpl/excerpt.pdf
 
 
 Andrei
 
"There are many random number generators out there, among which the fast and well-studied linear congruential generators." ^ You are missing an "are" Personally I'd append something like: "Therefore we wish to test the parameters to our generator" to the paragraph starting "But there is a rub." Also: The penultimate paragraph about interpretation process being slow seems rather redundant. It's just an implementation detail and dmd compiles huge libraries 1000x faster than c++ anyway. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKz4vrT9LetA9XoXwRAlrkAJ9QYiIv8XZ2H+lRuUSnyZV1HKDp6QCfdXig SVeeO0pY47V2vdWtbuZopmg= =ytCp -----END PGP SIGNATURE-----
Oct 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Thanks!


I plan to add more text at the end of the chapter that discusses the 
opportunities of CTFE. Walter revealed to me that CTFE, particularly now 
after it's been improved by leaps and bounds by Don and by Walter 
himself, could obviate a lot of the traditional metaprogramming 
techniques developed for C++.

One question that bugs me is, where do you draw the line? Say there's a 
metaprogramming problem at hand. How to decide on solving it with CTFE 
vs. solving it with templates? It would be great to have a simple 
guideline that puts in contrast the pluses and minuses of the two 
approaches.

It is quite possible that templates get relegated to parameterized 
functions and types, whereas all heavy lifting in metaprogramming should 
be carried with CTFE.


Andrei

div0 wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Andrei Alexandrescu wrote:
 Thanks to all who answered! I wish there was such consensus in other
 matters as well :o).

 Allow me to put forth an excerpt from TDPL without any particular
 reason: http://erdani.com/tdpl/excerpt.pdf


 Andrei
"There are many random number generators out there, among which the fast and well-studied linear congruential generators." ^ You are missing an "are" Personally I'd append something like: "Therefore we wish to test the parameters to our generator" to the paragraph starting "But there is a rub." Also: The penultimate paragraph about interpretation process being slow seems rather redundant. It's just an implementation detail and dmd compiles huge libraries 1000x faster than c++ anyway. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKz4vrT9LetA9XoXwRAlrkAJ9QYiIv8XZ2H+lRuUSnyZV1HKDp6QCfdXig SVeeO0pY47V2vdWtbuZopmg= =ytCp -----END PGP SIGNATURE-----
Oct 09 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Oct 9, 2009 at 3:49 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Thanks!


 I plan to add more text at the end of the chapter that discusses the
 opportunities of CTFE. Walter revealed to me that CTFE, particularly now
 after it's been improved by leaps and bounds by Don and by Walter himself,
 could obviate a lot of the traditional metaprogramming techniques developed
 for C++.

 One question that bugs me is, where do you draw the line? Say there's a
 metaprogramming problem at hand. How to decide on solving it with CTFE vs.
 solving it with templates? It would be great to have a simple guideline that
 puts in contrast the pluses and minuses of the two approaches.

 It is quite possible that templates get relegated to parameterized functions
 and types, whereas all heavy lifting in metaprogramming should be carried
 with CTFE.
The second someone suggests parsing D code with CTFE, I'm out of here. I mean I'm leaving the community. Period.
Oct 09 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Jarrett Billingsley wrote:

 The second someone suggests parsing D code with CTFE, I'm out of here.
 I mean I'm leaving the community. Period.
Here, for you: http://www.addletters.com/pictures/bart-simpson-generator/bart-simpson- generator.php?line=I+will+not+parse+D+code+with+CTFE!
Oct 09 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Oct 9, 2009 at 4:28 PM, Lutger <lutger.blijdestijn gmail.com> wrote:
 Jarrett Billingsley wrote:

 The second someone suggests parsing D code with CTFE, I'm out of here.
 I mean I'm leaving the community. Period.
Here, for you: http://www.addletters.com/pictures/bart-simpson-generator/bart-simpson- generator.php?line=I+will+not+parse+D+code+with+CTFE!
Loled!
Oct 09 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hao44m$2g5e$1 digitalmars.com...
 It is quite possible that templates get relegated to parameterized 
 functions and types, whereas all heavy lifting in metaprogramming should 
 be carried with CTFE.
that they are is that it allows them to cross DLL boundaries (or...it was something along those lines, I forget exactly what.) If what you describe about D's templates does occur, then maybe we would be able to give them the
Oct 09 2009
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:
 
 One question that bugs me is, where do you draw the line? Say there's a 
 metaprogramming problem at hand. How to decide on solving it with CTFE 
 vs. solving it with templates? It would be great to have a simple 
 guideline that puts in contrast the pluses and minuses of the two 
 approaches.
 
 It is quite possible that templates get relegated to parameterized 
 functions and types, whereas all heavy lifting in metaprogramming should 
 be carried with CTFE.
That would certainly be my preferred division. Templates can be used as a replacement for interfaces when the overhead can't be tolerated. D's ranges make heavy use of this. Templates can avoid virtual function calls and keep object size small. Having abused this a bit too much, I'd love to be able to template modules... import whatever!(int) : foo, bar, baz;
Oct 09 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Oct 9, 2009 at 3:49 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Thanks!


 I plan to add more text at the end of the chapter that discusses the
 opportunities of CTFE. Walter revealed to me that CTFE, particularly now
 after it's been improved by leaps and bounds by Don and by Walter himself,
 could obviate a lot of the traditional metaprogramming techniques developed
 for C++.

 One question that bugs me is, where do you draw the line? Say there's a
 metaprogramming problem at hand. How to decide on solving it with CTFE vs.
 solving it with templates? It would be great to have a simple guideline that
 puts in contrast the pluses and minuses of the two approaches.

 It is quite possible that templates get relegated to parameterized functions
 and types, whereas all heavy lifting in metaprogramming should be carried
 with CTFE.
God, I wish we had a real forum with table capabilities. I can't even rely on monospaced fonts.. Where templates win at metaprogramming: Templates have pattern-matching capabilities for picking apart types. CTFE is forced to reimplement part of the D lexer/parser to do so (and combined with buggy/incompletely specified .stringof, you can't really depend on your parsing to work right). With templates, you write "real code", whereas with CTFE you have to quote everything. D2's token strings improve this somewhat but D1 users are stuck in escaping hell. Not that you care, since you don't believe D1 even exists anymore, but whatever. Quoting things is still irritating. Templates have a definite advantage when it comes to alias parameters and the instantiation mechanism. CTFE mixins have to worry about exactly when and where some piece of code is mixed-in, or else you could be evaluating it somewhere where a given symbol isn't defined. Oops, you mixed in your code in a different module than the one it was accessed from, suddenly all the imports are different and you don't have access to a bunch of functions. With templates, it .. just works. You can give a template a symbol from some module that it normally wouldn't have access to and it's perfectly happy. CTFE that deals with this gets very tedious very quickly. Templates are much more transparent. Mixin statements/expressions always look something like a hack. Greppable? Sure. But many times I don't *want* greppable, I want *clean*. Meta-metaprogramming. You can't easily write a CTFE map() function. You *can* write a simple Map template. Reduce!(Cat, Map!(SomeList, SomeTemplate)) is just.. it brings tears to my eyes. It's so beautiful. Where CTFE wins at metaprogramming: Liiiiiiiiiiists. If you have a list of something, it's far easier to deal with in an imperative CTFE function than in an awkwardly recursive template. Edge cases (first, last items) are also easier to deal with imperatively. DSLs, and more generally, parsing. Doing DSL parsing with templates is possible but not fun. You end up with a ton of templates. Not that I'm advocating parsing lots of things with CTFE either.. you already know how I feel about that. Verbosity. Templates require you to add a lot of silly cruft to do even really simple things. "template SomeListProcessingTemplate(T...) { static if(T.length == 0) alias Tuple!() SomeListProcessingTemplate; else { pragma(msg, T[0].stringof); alias Tuple!(T[0], SomeListProcessingTemplate!(T[1 .. $])) SomeListProcessingTemplate; }" Notice the template name is repeated three times within the template.. all the cruft starts to make it difficult to see what's actually going on. CTFE functions are generally shorter and easier to follow, if for no other reason than D is mostly an imperative language and that's what its syntax optimizes for. Those things being said, please, PLEASE consider __ident. Many times I'd like to do something with templates because I'd be able to avoid the CTFE mess with symbol visibility, but I can't because I need to dynamically generate one stinking identifier from a string. Soooo many of my CTFE metaprogramming functions could be replaced by simple templates if I only had __ident. You remember the "finalize" template thing I wrote once? How it was about 150 lines of hard-to-follow, terribly hackish CTFE .stringof parsing and bullshit when it could have been reduced to about 8 lines with __ident? Really. It comes up a LOT. Consider it. But one other thing that I want to bring up is that I really, really hope that this newfound love for CTFE doesn't shift the mindset towards "why bother adding features to the language when you could simulate it with CTFE?" For some things, that's fine. But I don't want to look at D code in 6 or 7 years, see half the source encased in q{}, and see the other half composed almost entirely of mixin(). That's just awful.
Oct 09 2009
next sibling parent reply Don <nospam nospam.com> writes:
Jarrett Billingsley wrote:
 On Fri, Oct 9, 2009 at 3:49 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Thanks!


 I plan to add more text at the end of the chapter that discusses the
 opportunities of CTFE. Walter revealed to me that CTFE, particularly now
 after it's been improved by leaps and bounds by Don and by Walter himself,
 could obviate a lot of the traditional metaprogramming techniques developed
 for C++.

 One question that bugs me is, where do you draw the line? Say there's a
 metaprogramming problem at hand. How to decide on solving it with CTFE vs.
 solving it with templates? It would be great to have a simple guideline that
 puts in contrast the pluses and minuses of the two approaches.

 It is quite possible that templates get relegated to parameterized functions
 and types, whereas all heavy lifting in metaprogramming should be carried
 with CTFE.
God, I wish we had a real forum with table capabilities. I can't even rely on monospaced fonts.. Where templates win at metaprogramming: Templates have pattern-matching capabilities for picking apart types. CTFE is forced to reimplement part of the D lexer/parser to do so (and combined with buggy/incompletely specified .stringof, you can't really depend on your parsing to work right).
CTFE doesn't mean "string mixins using CTFE". It just means CTFE. (BTW you can do string mixins with templates only, no CTFE, if you are completely insane).
Oct 10 2009
next sibling parent reply language_fan <foo bar.com.invalid> writes:
Sat, 10 Oct 2009 10:26:11 +0200, Don thusly wrote:

 CTFE doesn't mean "string mixins using CTFE". It just means CTFE. (BTW
 you can do string mixins with templates only, no CTFE, if you are
 completely insane).
CTFE without mixins is rather limited form of metaprogramming. You can basically only initialize some static non-code data, and not much more. String mixins with templates was the only way to go before CTFE became possible -- those were the times!
Oct 10 2009
next sibling parent Don <nospam nospam.com> writes:
language_fan wrote:
 Sat, 10 Oct 2009 10:26:11 +0200, Don thusly wrote:
 
 CTFE doesn't mean "string mixins using CTFE". It just means CTFE. (BTW
 you can do string mixins with templates only, no CTFE, if you are
 completely insane).
CTFE without mixins is rather limited form of metaprogramming. You can basically only initialize some static non-code data, and not much more.
That's a lot, though. For example, you can perform the compilation step for a regexp, and determine whether it needs to be implemented with backtracking, or not. CTFE is perfect for parsing DSLs.
 String mixins with templates was the only way to go before CTFE became 
 possible -- those were the times!
They were very short times <g>. String mixins were introduced in DMDD1.005, (5 Feb 2007) and CTFE came in 1.006, ten days later. But that was indeed a very fun time for D. I did a lot of early metaprogramming work with template value parameters, before string mixins. It was quite ugly, and painful to write. D metaprogramming techniques have gradually got less hacky over time.
Oct 12 2009
prev sibling parent BCS <none anon.com> writes:
Hello language_fan,

 Sat, 10 Oct 2009 10:26:11 +0200, Don thusly wrote:
 
 CTFE doesn't mean "string mixins using CTFE". It just means CTFE.
 (BTW you can do string mixins with templates only, no CTFE, if you
 are completely insane).
 
CTFE without mixins is rather limited form of metaprogramming. You can basically only initialize some static non-code data, and not much more. String mixins with templates was the only way to go before CTFE became possible -- those were the times!
What does yacc do? Build a switch statement via cut-n-paste, define a few constants, define a few types via cut-n-paste, and initialize some static data. Oh and there's no such thing as non-code data, if you are crazy enough: const byte[] it = buildPositionIndependentCodeAsString(Data); int i = (cast(int function(int))it.ptr)(42);
Oct 12 2009
prev sibling parent BCS <none anon.com> writes:
Hello Don,

 CTFE doesn't mean "string mixins using CTFE".
 It just means CTFE. (BTW you can do string mixins with templates only,
 no CTFE, if you are completely insane).
I'm guilty of proving this by building a *parser* that runs at compile time without using CTFE.
Oct 12 2009
prev sibling parent language_fan <foo bar.com.invalid> writes:
Fri, 09 Oct 2009 16:49:19 -0400, Jarrett Billingsley thusly wrote:

 Where CTFE wins at metaprogramming:
 
 Liiiiiiiiiiists. If you have a list of something, it's far easier to
 deal with in an imperative CTFE function than in an awkwardly recursive
 template. Edge cases (first, last items) are also easier to deal with
 imperatively.
Of course the "lists" become more efficient and easier to use inside CTFE functions since D does not even have built-in lists but arrays. Calling Head!(foo) and Head!(Reverse!(foo)) is not that hard in template code, but D just does not have a standard template utility function library.
 DSLs, and more generally, parsing. Doing DSL parsing with templates is
 possible but not fun. You end up with a ton of templates. Not that I'm
 advocating parsing lots of things with CTFE either.. you already know
 how I feel about that.
You liek it?
Oct 10 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Thanks!
 I plan to add more text at the end of the chapter that discusses the
 opportunities of CTFE. Walter revealed to me that CTFE, particularly now
 after it's been improved by leaps and bounds by Don and by Walter
 himself, could obviate a lot of the traditional metaprogramming
 techniques developed for C++.
 One question that bugs me is, where do you draw the line? Say there's a
 metaprogramming problem at hand. How to decide on solving it with CTFE
 vs. solving it with templates? It would be great to have a simple
 guideline that puts in contrast the pluses and minuses of the two
 approaches.
CTFE is great for working with values while template metaprogramming is great for working with types. String mixins make CTFE good at working with types as well, but I wouldn't consider them a novice-level feature.
Oct 09 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Oct 9, 2009 at 4:57 PM, Sean Kelly <sean invisibleduck.org> wrote:
 =3D=3D Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s a=
rticle
 Thanks!
 I plan to add more text at the end of the chapter that discusses the
 opportunities of CTFE. Walter revealed to me that CTFE, particularly now
 after it's been improved by leaps and bounds by Don and by Walter
 himself, could obviate a lot of the traditional metaprogramming
 techniques developed for C++.
 One question that bugs me is, where do you draw the line? Say there's a
 metaprogramming problem at hand. How to decide on solving it with CTFE
 vs. solving it with templates? It would be great to have a simple
 guideline that puts in contrast the pluses and minuses of the two
 approaches.
CTFE is great for working with values while template metaprogramming is great for working with types. =A0String mixins make CTFE good at working with types as well, but I wouldn't consider them a novice-level feature.
Throw templates in there. Boom! Goodbye, CTFE. (.stringof and templates do not get along.)
Oct 09 2009
parent reply Don <nospam nospam.com> writes:
Jarrett Billingsley wrote:
 On Fri, Oct 9, 2009 at 4:57 PM, Sean Kelly <sean invisibleduck.org> wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Thanks!
 I plan to add more text at the end of the chapter that discusses the
 opportunities of CTFE. Walter revealed to me that CTFE, particularly now
 after it's been improved by leaps and bounds by Don and by Walter
 himself, could obviate a lot of the traditional metaprogramming
 techniques developed for C++.
 One question that bugs me is, where do you draw the line? Say there's a
 metaprogramming problem at hand. How to decide on solving it with CTFE
 vs. solving it with templates? It would be great to have a simple
 guideline that puts in contrast the pluses and minuses of the two
 approaches.
CTFE is great for working with values while template metaprogramming is great for working with types. String mixins make CTFE good at working with types as well, but I wouldn't consider them a novice-level feature.
Throw templates in there. Boom! Goodbye, CTFE. (.stringof and templates do not get along.)
That's just a bug. The more fundamental problem is that you can't instantiate a template from inside CTFE. IE, you can cross from the "compile-time world" to the "runtime world" only once -- you can never get back.
Oct 10 2009
parent reply language_fan <foo bar.com.invalid> writes:
Sat, 10 Oct 2009 10:30:31 +0200, Don thusly wrote:

 The more fundamental problem is that you can't
 instantiate a template from inside CTFE. IE, you can cross from the
 "compile-time world" to the "runtime world" only once -- you can never
 get back.
That's not exactly true. Also both templates and CTFE are compile time features. You can compute a value with CTFE in the "value world" and lift the result to the "type world" with a template. The range of a template used as a metafunction is {types, values} and their mixture. CTFE functions only return values. Understanding the concept of 'lambda cube' will help you here.
Oct 10 2009
parent reply Don <nospam nospam.com> writes:
language_fan wrote:
 Sat, 10 Oct 2009 10:30:31 +0200, Don thusly wrote:
 
 The more fundamental problem is that you can't
 instantiate a template from inside CTFE. IE, you can cross from the
 "compile-time world" to the "runtime world" only once -- you can never
 get back.
That's not exactly true. Also both templates and CTFE are compile time features. You can compute a value with CTFE in the "value world" and lift the result to the "type world" with a template.
Yes, but the problem is that variables inside a CTFE function, even though they are known at compile-time, are not permitted to be used as template value parameters. For example: template A(int X) { enum int A = B(X)+1; } // OK, template can call CTFE int B(int X) { return A!(X) + 1; } // Not OK, CTFE cannot call template.
Oct 12 2009
parent reply language_fan <foo bar.com.invalid> writes:
Mon, 12 Oct 2009 12:07:19 +0200, Don thusly wrote:

 language_fan wrote:
 Sat, 10 Oct 2009 10:30:31 +0200, Don thusly wrote:
 
 The more fundamental problem is that you can't instantiate a template
 from inside CTFE. IE, you can cross from the "compile-time world" to
 the "runtime world" only once -- you can never get back.
That's not exactly true. Also both templates and CTFE are compile time features. You can compute a value with CTFE in the "value world" and lift the result to the "type world" with a template.
Yes, but the problem is that variables inside a CTFE function, even though they are known at compile-time, are not permitted to be used as template value parameters. For example: template A(int X) { enum int A = B(X)+1; } // OK, template can call CTFE int B(int X) { return A!(X) + 1; } // Not OK, CTFE cannot call template.
As far as I can tell there is no reason why you cannot call templates from a CTFE code. Your code above has two problems: a) it never terminates b) due to some lookup problem the compiler gets confused, this has nothing to do with CTFE not being able to call templates - for instance this works:
 template A(int X) { enum int A = 2+1; }
 
 int B(int X) { return A!(X) + 1; }
Oct 12 2009
parent reply Don <nospam nospam.com> writes:
language_fan wrote:
 Mon, 12 Oct 2009 12:07:19 +0200, Don thusly wrote:
 
 language_fan wrote:
 Sat, 10 Oct 2009 10:30:31 +0200, Don thusly wrote:

 The more fundamental problem is that you can't instantiate a template
 from inside CTFE. IE, you can cross from the "compile-time world" to
 the "runtime world" only once -- you can never get back.
That's not exactly true. Also both templates and CTFE are compile time features. You can compute a value with CTFE in the "value world" and lift the result to the "type world" with a template.
Yes, but the problem is that variables inside a CTFE function, even though they are known at compile-time, are not permitted to be used as template value parameters. For example: template A(int X) { enum int A = B(X)+1; } // OK, template can call CTFE int B(int X) { return A!(X) + 1; } // Not OK, CTFE cannot call template.
As far as I can tell there is no reason why you cannot call templates from a CTFE code. Your code above has two problems: a) it never terminates
It wasn't meant to be a compilable example. b) due to some lookup problem the compiler gets confused, this
 has nothing to do with CTFE not being able to call templates - for 
 instance this works:
 
 template A(int X) { enum int A = 2+1; }

 int B(int X) { return A!(X) + 1; }
You're seeing a few bugs there. In the template X isn't a constant, it's an alias (that is NOT in the spec, bug 2962). If you try adding a "static assert(X!=2)", you'll find it's not a constant. It will let you write: enum int A = X + 1; but that's bug 2414. The rule is, any CTFE function must also be evaluatable at run-time. Templates cannot be instantiated at run-time. Therefore templates cannot be instantiated in CTFE.
Oct 12 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 12 Oct 2009 16:01:59 +0400, Don <nospam nospam.com> wrote:

 language_fan wrote:
 Mon, 12 Oct 2009 12:07:19 +0200, Don thusly wrote:

 language_fan wrote:
 Sat, 10 Oct 2009 10:30:31 +0200, Don thusly wrote:

 The more fundamental problem is that you can't instantiate a template
 from inside CTFE. IE, you can cross from the "compile-time world" to
 the "runtime world" only once -- you can never get back.
That's not exactly true. Also both templates and CTFE are compile time features. You can compute a value with CTFE in the "value world" and lift the result to the "type world" with a template.
Yes, but the problem is that variables inside a CTFE function, even though they are known at compile-time, are not permitted to be used as template value parameters. For example: template A(int X) { enum int A = B(X)+1; } // OK, template can call CTFE int B(int X) { return A!(X) + 1; } // Not OK, CTFE cannot call template.
As far as I can tell there is no reason why you cannot call templates from a CTFE code. Your code above has two problems: a) it never terminates
It wasn't meant to be a compilable example. b) due to some lookup problem the compiler gets confused, this
 has nothing to do with CTFE not being able to call templates - for  
 instance this works:

 template A(int X) { enum int A = 2+1; }

 int B(int X) { return A!(X) + 1; }
You're seeing a few bugs there. In the template X isn't a constant, it's an alias (that is NOT in the spec, bug 2962). If you try adding a "static assert(X!=2)", you'll find it's not a constant. It will let you write: enum int A = X + 1; but that's bug 2414. The rule is, any CTFE function must also be evaluatable at run-time. Templates cannot be instantiated at run-time. Therefore templates cannot be instantiated in CTFE.
I believe you mean "Templates that depend on arguments passed to a function cannot be instantiated". It doesn't mean you can't used templates in CTFE at all.
Oct 12 2009
prev sibling parent language_fan <foo bar.com.invalid> writes:
Mon, 12 Oct 2009 14:01:59 +0200, Don thusly wrote:

 language_fan wrote:
 As far as I can tell there is no reason why you cannot call templates
 from a CTFE code. Your code above has two problems: a) it never
 terminates
It wasn't meant to be a compilable example. b) due to some lookup problem the compiler gets confused, this
 has nothing to do with CTFE not being able to call templates - for
 instance this works:
 
 template A(int X) { enum int A = 2+1; }

 int B(int X) { return A!(X) + 1; }
You're seeing a few bugs there. In the template X isn't a constant, it's an alias (that is NOT in the spec, bug 2962). If you try adding a "static assert(X!=2)", you'll find it's not a constant. It will let you write: enum int A = X + 1; but that's bug 2414. The rule is, any CTFE function must also be evaluatable at run-time. Templates cannot be instantiated at run-time. Therefore templates cannot be instantiated in CTFE.
Ah, I see what you meant now. Indeed, there are some open issues wrt how these things should work. Basically your original example could be compilable, even when there is a dependency on a runtime variable, if a proper macro system was available. The compiler could just copy'n'paste the template body to the point where it is being instantiated. This all happens in the static part of the function declaration. I have no idea how to fix the template system -- I'm not too happy with the idea of extending parametric polymorphism this much. A distinct AST level macro system would make more sense.
Oct 12 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:

 CTFE is great for working with values while template metaprogramming is
 great for working with types.  String mixins make CTFE good at working
 with types as well, but I wouldn't consider them a novice-level feature.
If a "type" type is added to the language (and few other minor changes), then CTFE can be used with types too. Bye, bearophile
Oct 09 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
bearophile wrote:
 Sean Kelly:
 
 CTFE is great for working with values while template metaprogramming is
 great for working with types.  String mixins make CTFE good at working
 with types as well, but I wouldn't consider them a novice-level feature.
If a "type" type is added to the language (and few other minor changes), then CTFE can be used with types too. Bye, bearophile
I would rather have TypeInfo usable at compile time than a "type" type.
Oct 09 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jeremie Pelletier:
 
 I would rather have TypeInfo usable at compile time than a "type" type.
That's useful, but it's not enough. So you may want both. Sometimes all you want to pass to a function is a type, to replace some of the use cases of templates. Time ago I have shown some usage examples here. To me it seems that where they can be used they give a little more natural means to do some things (but templates can't be fully replaced). Bye, bearophile
Oct 09 2009
parent language_fan <foo bar.com.invalid> writes:
Sat, 10 Oct 2009 01:21:32 -0400, bearophile thusly wrote:

 Jeremie Pelletier:
  
 I would rather have TypeInfo usable at compile time than a "type" type.
That's useful, but it's not enough. So you may want both. Sometimes all you want to pass to a function is a type, to replace some of the use cases of templates. Time ago I have shown some usage examples here. To me it seems that where they can be used they give a little more natural means to do some things (but templates can't be fully replaced).
Actually the TypeInfo structure can have more or less the same semantics as a distinct 'type' type. Your idea is good, but you need to beef up the specs before the proposal gets any useful. What you need is some kind of facility to query information about the type, and possible other information to generate new types.
Oct 10 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-10-09 15:49:42 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Thanks!
 
 
 I plan to add more text at the end of the chapter that discusses the 
 opportunities of CTFE. Walter revealed to me that CTFE, particularly 
 now after it's been improved by leaps and bounds by Don and by Walter 
 himself, could obviate a lot of the traditional metaprogramming 
 techniques developed for C++.
 
 One question that bugs me is, where do you draw the line? Say there's a 
 metaprogramming problem at hand. How to decide on solving it with CTFE 
 vs. solving it with templates? It would be great to have a simple 
 guideline that puts in contrast the pluses and minuses of the two 
 approaches.
 
 It is quite possible that templates get relegated to parameterized 
 functions and types, whereas all heavy lifting in metaprogramming 
 should be carried with CTFE.
My idea on templates is that they're good when you have type parameters, or to create types based on constant parameters. - - - But an interesting thing I realized in the last few months is this: all you can do with a template you can also do at runtime provided sufficient runtime reflection capabilities. Even creating types! Details follow. If you have runtime reflection, it ensues that you have a data structure (most likely a class) capable of representing each type. From that point on, you just have to build other instances of this type-defining data structure at runtime, and all the code using the reflection APIs will be able to use that type. Such code (relying on runtime reflection) would also be slower, but as the D copiler proves with CTFE, what you know at compile time can be used to optimize things. And from that point of view, you can see templates as an compiled, optimized version of runtime reflection and type creation capabilities. Don't read this as a request to change D; it's just an observation I wanted to share in your questioning about the purpose of templates. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 09 2009
next sibling parent reply language_fan <foo bar.com.invalid> writes:
Fri, 09 Oct 2009 20:20:02 -0400, Michel Fortin thusly wrote:

 But an interesting thing I realized in the last few months is this: all
 you can do with a template you can also do at runtime provided
 sufficient runtime reflection capabilities. Even creating types!
This is a well known fact..
 And from that point of view, you can see templates as an compiled,
 optimized version of runtime reflection and type creation capabilities.
Runtime reflection can be really expensive computationally, but it becomes useful when you need mobile code.
Oct 10 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-10-10 16:56:33 -0400, language_fan <foo bar.com.invalid> said:

 And from that point of view, you can see templates as an compiled,
 optimized version of runtime reflection and type creation capabilities.
Runtime reflection can be really expensive computationally, but it becomes useful when you need mobile code.
What I was getting at is that given good enough runtime reflection, templates could depend on runtime parameters, and those templates could be instanciated at runtime. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 10 2009
prev sibling parent reply BCS <none anon.com> writes:
Hello Michel,

 On 2009-10-09 15:49:42 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:
 
 Thanks!
 
 I plan to add more text at the end of the chapter that discusses the
 opportunities of CTFE. Walter revealed to me that CTFE, particularly
 now after it's been improved by leaps and bounds by Don and by Walter
 himself, could obviate a lot of the traditional metaprogramming
 techniques developed for C++.
 
 One question that bugs me is, where do you draw the line? Say there's
 a metaprogramming problem at hand. How to decide on solving it with
 CTFE vs. solving it with templates? It would be great to have a
 simple guideline that puts in contrast the pluses and minuses of the
 two approaches.
 
 It is quite possible that templates get relegated to parameterized
 functions and types, whereas all heavy lifting in metaprogramming
 should be carried with CTFE.
 
My idea on templates is that they're good when you have type parameters, or to create types based on constant parameters. - - - But an interesting thing I realized in the last few months is this: all you can do with a template you can also do at runtime provided sufficient runtime reflection capabilities. Even creating types! Details follow.
I'd like to forward the thought that runtime reflection and type creation is NOT a replacement for the same at compile time just as the compile time version is not a replacement for the run time version. Just to pick two differences: errors are forced to runtime and runtime types can't be inlined.
Oct 12 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 12/10/2009 18:45, BCS wrote:
 Hello Michel,

 On 2009-10-09 15:49:42 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 Thanks!

 I plan to add more text at the end of the chapter that discusses the
 opportunities of CTFE. Walter revealed to me that CTFE, particularly
 now after it's been improved by leaps and bounds by Don and by Walter
 himself, could obviate a lot of the traditional metaprogramming
 techniques developed for C++.

 One question that bugs me is, where do you draw the line? Say there's
 a metaprogramming problem at hand. How to decide on solving it with
 CTFE vs. solving it with templates? It would be great to have a
 simple guideline that puts in contrast the pluses and minuses of the
 two approaches.

 It is quite possible that templates get relegated to parameterized
 functions and types, whereas all heavy lifting in metaprogramming
 should be carried with CTFE.
My idea on templates is that they're good when you have type parameters, or to create types based on constant parameters. - - - But an interesting thing I realized in the last few months is this: all you can do with a template you can also do at runtime provided sufficient runtime reflection capabilities. Even creating types! Details follow.
I'd like to forward the thought that runtime reflection and type creation is NOT a replacement for the same at compile time just as the compile time version is not a replacement for the run time version. Just to pick two differences: errors are forced to runtime and runtime types can't be inlined.
you can have compile-time errors with (static) asserts and you can inline runtime types by way of a smart JITer/VM and run-time profiling. programs with long lifetimes like servers perform better in Java than in C++ because the VM optimizes the code at run-time. it's analogous to DBs: you can write the implementation for your query yourself in c++ OR use a DB engine such as Oracle that collects statistics and optimizes your SQL query at run-time. I think we had a discussion about this before. The only difference between compile-time and run-time is just that, the stage at which the code is optimized/run. compile time allows for ahead-of-time optimization (good for short lived programs and when you have ahead-of-time knowledge for performing the optimizations) while run-time allows for just-in-time optimization (more flexible for when you don't have ahead-of-time knowledge)
Oct 12 2009
parent Don <nospam nospam.com> writes:
Yigal Chripun wrote:
 On 12/10/2009 18:45, BCS wrote:
 Hello Michel,

 On 2009-10-09 15:49:42 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 Thanks!

 I plan to add more text at the end of the chapter that discusses the
 opportunities of CTFE. Walter revealed to me that CTFE, particularly
 now after it's been improved by leaps and bounds by Don and by Walter
 himself, could obviate a lot of the traditional metaprogramming
 techniques developed for C++.

 One question that bugs me is, where do you draw the line? Say there's
 a metaprogramming problem at hand. How to decide on solving it with
 CTFE vs. solving it with templates? It would be great to have a
 simple guideline that puts in contrast the pluses and minuses of the
 two approaches.

 It is quite possible that templates get relegated to parameterized
 functions and types, whereas all heavy lifting in metaprogramming
 should be carried with CTFE.
My idea on templates is that they're good when you have type parameters, or to create types based on constant parameters. - - - But an interesting thing I realized in the last few months is this: all you can do with a template you can also do at runtime provided sufficient runtime reflection capabilities. Even creating types! Details follow.
I'd like to forward the thought that runtime reflection and type creation is NOT a replacement for the same at compile time just as the compile time version is not a replacement for the run time version. Just to pick two differences: errors are forced to runtime and runtime types can't be inlined.
you can have compile-time errors with (static) asserts and you can inline runtime types by way of a smart JITer/VM and run-time profiling.
CTFE will get exceptions. Shin already put a patch in Bugzilla to do it in a few special case; it's not included yet, since the intention is for CTFE to support classes, and hence should support general exceptions. OTOH, I think BCS was contrasting detecting errors during development (at compile-time) instead of during deployment (at run-time).
Oct 13 2009
prev sibling parent reply "Phil Deets" <pjdeets2 gmail.com> writes:
On Fri, 09 Oct 2009 03:11:01 -0500, Andrei Alexandrescu  =

<SeeWebsiteForEmail erdani.org> wrote:

 Thanks to all who answered! I wish there was such consensus in other  =
 matters as well :o).

 Allow me to put forth an excerpt from TDPL without any particular  =
 reason: http://erdani.com/tdpl/excerpt.pdf


 Andrei
Nice, but I noticed two mistakes on page 140. * "n divides p_k" =3D> "p_k divides n" * In the paragraph starting with "Why does the iteration", the statement= = "If iter is greater than sqrt(n) then we can be sure iter can=E2=80=99t = be a = divisor of n" is wrong since iter could equal n (try 6 or 2 as input). T= he = function still works since you return accum * n. -- = Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 12 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Phil Deets wrote:
 On Fri, 09 Oct 2009 03:11:01 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Thanks to all who answered! I wish there was such consensus in other 
 matters as well :o).

 Allow me to put forth an excerpt from TDPL without any particular 
 reason: http://erdani.com/tdpl/excerpt.pdf


 Andrei
Nice, but I noticed two mistakes on page 140. * "n divides p_k" => "p_k divides n" * In the paragraph starting with "Why does the iteration", the statement "If iter is greater than sqrt(n) then we can be sure iter can’t be a divisor of n" is wrong since iter could equal n (try 6 or 2 as input). The function still works since you return accum * n.
Fixed. Thanks! Andrei
Oct 12 2009