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