www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - documentation and papers about const/invariant

reply Dee Girl <deegirl noreply.com> writes:
There is a little documentation about const invariant on the web site. I read
it. And also I read ACCU-functional. Is there more documentation? Like
conference paper or manual. Does Tango book document const? Thank you, Dee Girl
May 18 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Dee Girl wrote:
 There is a little documentation about const invariant on the web site. I read
it. And also I read ACCU-functional. Is there more documentation? Like
conference paper or manual. Does Tango book document const? Thank you, Dee Girl
At the time of writing, the design of const/invariant didn't seem finalized so we left it alone. And as far as I know, there are no papers or manuals on the subject. Nor documentation of the thought process behind the design. Sean
May 18 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Sean Kelly wrote:
 Dee Girl wrote:
 There is a little documentation about const invariant on the web site. 
 I read it. And also I read ACCU-functional. Is there more 
 documentation? Like conference paper or manual. Does Tango book 
 document const? Thank you, Dee Girl
At the time of writing, the design of const/invariant didn't seem finalized so we left it alone. And as far as I know, there are no papers or manuals on the subject. Nor documentation of the thought process behind the design.
There's http://www.digitalmars.com/d/2.0/const.html
May 18 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Robert Fraser wrote:
 Sean Kelly wrote:
 Dee Girl wrote:
 There is a little documentation about const invariant on the web 
 site. I read it. And also I read ACCU-functional. Is there more 
 documentation? Like conference paper or manual. Does Tango book 
 document const? Thank you, Dee Girl
At the time of writing, the design of const/invariant didn't seem finalized so we left it alone. And as far as I know, there are no papers or manuals on the subject. Nor documentation of the thought process behind the design.
There's http://www.digitalmars.com/d/2.0/const.html
It sounded like Dee Girl was asking for a formal paper or proposal. Sean
May 18 2008
parent reply Dee Girl <deegirl noreply.com> writes:
Sean Kelly Wrote:

 Robert Fraser wrote:
 Sean Kelly wrote:
 Dee Girl wrote:
 There is a little documentation about const invariant on the web 
 site. I read it. And also I read ACCU-functional. Is there more 
 documentation? Like conference paper or manual. Does Tango book 
 document const? Thank you, Dee Girl
At the time of writing, the design of const/invariant didn't seem finalized so we left it alone. And as far as I know, there are no papers or manuals on the subject. Nor documentation of the thought process behind the design.
There's http://www.digitalmars.com/d/2.0/const.html
It sounded like Dee Girl was asking for a formal paper or proposal.
Thank you both. Yes I was asking for something more. I think I understand how const/invariant works by doing test and reading Andrei ACCU slides and news group. The way const and invariant works is amazing. The most powerful I seen (better than javari!). But I hope I do not offend anyone if I say this. The article Here A Const, There A Const (http://www.digitalmars.com/d/2.0/const.html) I think is very very badly written. It is even better if the article is removed! It seems to me it has < 0 value. I now explain why I think is really bad article. Again please not be offended. It is only opinion. First it starts by 9 requirements from const. But the requirements are wrong! They do not explain why both invariant and const are good. Only explain (badly) how invariant is good. ACCU slides explain clear how const unifies invariant and mutable data. Const is super type of both. Slides explain also how const makes possible for imperative world to talk with functional world. It is genius! But the 9 requirements do not explain well. To me it looked like written by somebody who does not understand much. A beginner. But Walter wrote compiler so he understands everything! Maybe he did not have the time to think. I am sorry I say this. I clearly have bad English. But I can read. And to me it is clear the article does not present const/invariant well. Next part is even worse. How Does C++ Const Stack Up? is the title. Makes me mad! I read about C++ const. Things I knew. Fine. But then when the part ends what do I see? Scroll bar is at 80%. Most article discuss C++! I can not believe this. This is article written with attitude bitter and sad about C++. Does article want to explain D const or bash C++ const? Why fight C++? If you have nice new suit do you wear old suit under new suit to show how much nice new suit is??? Only wear new suit and let people appreciate. The only thing the section say is Walter hates C++ and wants to prove how C++ is bad. He is like 17 years old boy angry on ex girlfriend ^_^ What is good is only to show that D is good. Because it is good! It is work of genius. const/invariant are very powerful and will help threads and big programs. Next part Constness In D is a bit better. But I can not believe. Again an example from C++!!! Shows how C++ is "bad" again. I feel I want to say Walter please relax. And the article ends to early because all energy is gone on bash C++. I am very sorry I had to say. I think it is best if article is thrown away. It has hate and bitter. And explains little and also incomplete and incorrect. One article that only explains how D works is perfect. Maybe Andrei writes from ACCU slides a article. He writes happy not bitter. Sorry, Dee Girl
May 19 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Dee Girl escribió:
 Next part is even worse. How Does C++ Const Stack Up? is the title. Makes me
mad! I read about C++ const. Things I knew. Fine. But then when the part ends
what do I see? Scroll bar is at 80%. Most article discuss C++! I can not
believe this. This is article written with attitude bitter and sad about C++.
Does article want to explain D const or bash C++ const? Why fight C++?
I must agree here. Not only about const, but the page always seems to explain D by comparing it to C by saying "In C you used to do this, but in D you can do it better like this". I know D is mostly targeted at people with C++ knowledge. *mostly*. It would be nice if D was presented as a new, clean language, with complete explanations and some minor sections comparing it to other languages (and not always C++). It would say, after some good explanation, "If you are familiar with C++, this concept maps to...". That way, people that don't know C++ won't get scared if they see D, or feel the need to learn C++ before D. Imagine you enter the Java page and you read "Well... in C++ you have pointers, in Java you don't. Java only keeps the classes, but with this syntax. etc." No! Java is a completely new language, with another perspective in mind. And I think the same about D. People might also think "Bah, a new effort to write an improved C++". Instead, they should think "This language is great, I can do a lot of things, even all of those I could do with C++, and much more easly!". Same as Dee Girl, no offense intended.
May 20 2008
next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 20 May 2008 07:56:28 -0300, Ary Borenszweig wrote:

 Dee Girl escribió:
 Next part is even worse. How Does C++ Const Stack Up? is the title.
 Makes me mad! I read about C++ const. Things I knew. Fine. But then
 when the part ends what do I see? Scroll bar is at 80%. Most article
 discuss C++! I can not believe this. This is article written with
 attitude bitter and sad about C++. Does article want to explain D const
 or bash C++ const? Why fight C++?
I must agree here. Not only about const, but the page always seems to explain D by comparing it to C by saying "In C you used to do this, but in D you can do it better like this". I know D is mostly targeted at people with C++ knowledge. *mostly*. It would be nice if D was presented as a new, clean language, with complete explanations and some minor sections comparing it to other languages (and not always C++). It would say, after some good explanation, "If you are familiar with C++, this concept maps to...". That way, people that don't know C++ won't get scared if they see D, or feel the need to learn C++ before D. Imagine you enter the Java page and you read "Well... in C++ you have pointers, in Java you don't. Java only keeps the classes, but with this syntax. etc." No! Java is a completely new language, with another perspective in mind. And I think the same about D. People might also think "Bah, a new effort to write an improved C++". Instead, they should think "This language is great, I can do a lot of things, even all of those I could do with C++, and much more easly!". Same as Dee Girl, no offense intended.
Walter has said several times that he sucks at explaining things, his best method is to compare it with another language. I'm sure he would not be opposed to having someone write up replacement articles for things. And even if he was they could go onto the wiki4d.
May 20 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jesse Phillips (jessekphillips gmail.com)'s article
 Walter has said several times that he sucks at explaining things, his
 best method is to compare it with another language.
There's a rule in advertising where comparisons may only be made to the top product in any particular category. I suppose the idea is that doing so improves competition by preventing the top product from saying how bad all the others are. However, notice how such advertisements rarely mention the competing product by name, but instead generally say "the leading brand." This is because comparisons with another product implicitly establish that other product as better than the one being advertised. Otherwise, why bother with a comparison? When talking about something like a programming language, any mention of other languages should be limited to drawing similarities as a way to leverage the reader's knowledge when discussing difficult concepts. This is a fairly simple rule to follow, and in my experience it helps to retain the focus of an explanation. Sean
May 20 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Ary Borenszweig (ary esperanto.org.ar)'s article
 Dee Girl escribió:
 Next part is even worse. How Does C++ Const Stack Up? is the title. Makes me
mad! I read about C++
const. Things I knew. Fine. But then when the part ends what do I see? Scroll bar is at 80%. Most article discuss C++! I can not believe this. This is article written with attitude bitter and sad about C++. Does article want to explain D const or bash C++ const? Why fight C++?
 I must agree here. Not only about const, but the page always seems to
 explain D by comparing it to C by saying "In C you used to do this, but
 in D you can do it better like this".
There are a few pages like this. The wordcount/performance page, for example. I've never really liked them. It's one thing to explain how D features are different from the features in other languages to avoid confusion, but another to talk about the problems in other languages and how D improves on them. It makes D seem like the Democratic Party of the programming world.
 I know D is mostly targeted at people with C++ knowledge. *mostly*. It
 would be nice if D was presented as a new, clean language, with complete
 explanations and some minor sections comparing it to other languages
 (and not always C++). It would say, after some good explanation, "If you
 are familiar with C++, this concept maps to...". That way, people that
 don't know C++ won't get scared if they see D, or feel the need to learn
 C++ before D.
This is why I don't like some of the decisions in D 2.0. Choosing 'enum', for example, to represent manifest constants. It takes a necessary hack from C (declaring constants as enum values because it's either that or #define and #define stinks) and formalizes it as the Right Way to declare manifest constants. Personally, I think that anonymous enums shouldn't be allowed at all--formalizing the approach is a disaster. I guess what I'm saying is that I simply don't accept the argument that D should support C syntax, even bad C syntax, simply in hopes that it will help gain acceptance from the C community. Support for C-style function pointer declarations is another one that should go.
 Imagine you enter the Java page and you read "Well... in C++ you have
 pointers, in Java you don't. Java only keeps the classes, but with this
 syntax. etc." No! Java is a completely new language, with another
 perspective in mind. And I think the same about D.
 People might also think "Bah, a new effort to write an improved C++".
 Instead, they should think "This language is great, I can do a lot of
 things, even all of those I could do with C++, and much more easly!".
 Same as Dee Girl, no offense intended.
"Me too." Sean
May 20 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Sean Kelly wrote:
 == Quote from Ary Borenszweig (ary esperanto.org.ar)'s article
 I know D is mostly targeted at people with C++ knowledge. *mostly*. It
 would be nice if D was presented as a new, clean language, with complete
 explanations and some minor sections comparing it to other languages
 (and not always C++). It would say, after some good explanation, "If you
 are familiar with C++, this concept maps to...". That way, people that
 don't know C++ won't get scared if they see D, or feel the need to learn
 C++ before D.
This is why I don't like some of the decisions in D 2.0. Choosing 'enum', for example, to represent manifest constants. It takes a necessary hack from C (declaring constants as enum values because it's either that or #define and #define stinks) and formalizes it as the Right Way to declare manifest constants. Personally, I think that anonymous enums shouldn't be allowed at all--formalizing the approach is a disaster. I guess what I'm saying is that I simply don't accept the argument that D should support C syntax, even bad C syntax, simply in hopes that it will help gain acceptance from the C community. Support for C-style function pointer declarations is another one that should go.
Exactly. Walter's reason is that makes it easier for porting C/C++ applications to D. Isn't it much easier to make a bridge to those languages instead of expecting the user to port a whole application from C/C++ to D? Also, even if syntax is kept the same, D's semantics are already different (so keep the semantic, then keep C/C++?), so I don't see the benefit of conserving old, obscure syntax. For example Java allows you to write "int foo[];" instead of "int[] foo;", just to make C/C++ programmers feel a little more comfortable. And still, I haven't known a Java programmer that declares arrays that way, and probably when you teach Java to someone that knows C/C++ you'd say "See? The type is in one place, the name is in the other, much clearer!" :-)
May 20 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Ary Borenszweig (ary esperanto.org.ar)'s article
 For example Java allows you to write "int foo[];" instead of "int[]
 foo;", just to make C/C++ programmers feel a little more comfortable.
 And still, I haven't known a Java programmer that declares arrays that
 way, and probably when you teach Java to someone that knows C/C++ you'd
 say "See? The type is in one place, the name is in the other, much
 clearer!" :-)
D supports that declaration style too. But the only D code I've ever seen that uses it is Walter's. Sean
May 20 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

 This is why I don't like some of the decisions in D 2.0.  Choosing 'enum',
 for example, to represent manifest constants.  It takes a necessary hack
 from C (declaring constants as enum values because it's either that or
 #define and #define stinks) and formalizes it as the Right Way to declare
 manifest constants.  Personally, I think that anonymous enums shouldn't
 be allowed at all--formalizing the approach is a disaster.  I guess what
 I'm saying is that I simply don't accept the argument that D should
 support C syntax, even bad C syntax, simply in hopes that it will help
 gain acceptance from the C community.
Step 7 of the 12 step program for converting C++ to D is "global replace 'typedef' with 'alias'". It would not be hard to add a step 13: "global replace 'enum' with 'manifest'" or 'constant' or some other word that makes more sense than enum. So I really don't buy any argument that says "enum" has to stay "enum" for the benefit of C++ folks. For whatever reason, back in the day Walter realized that it was no longer appropriate to call D's expanded typedef a typedef and so he gave it a sensible name that matched its expanded role much better. I'm not sure what's changed, but for some reason today he seems to have the attitude of "eh, a word is a word. What's it matter what we call it?". I have to agree with the pigs in Orwell's Animal farm on this one: "all words are equal, but some words are more equal than others." --bb
May 20 2008
parent Dee Girl <deegirl noreply.com> writes:
Bill Baxter Wrote:

 Sean Kelly wrote:
 
 This is why I don't like some of the decisions in D 2.0.  Choosing 'enum',
 for example, to represent manifest constants.  It takes a necessary hack
 from C (declaring constants as enum values because it's either that or
 #define and #define stinks) and formalizes it as the Right Way to declare
 manifest constants.  Personally, I think that anonymous enums shouldn't
 be allowed at all--formalizing the approach is a disaster.  I guess what
 I'm saying is that I simply don't accept the argument that D should
 support C syntax, even bad C syntax, simply in hopes that it will help
 gain acceptance from the C community.
Step 7 of the 12 step program for converting C++ to D is "global replace 'typedef' with 'alias'". It would not be hard to add a step 13: "global replace 'enum' with 'manifest'" or 'constant' or some other word that makes more sense than enum. So I really don't buy any argument that says "enum" has to stay "enum" for the benefit of C++ folks. For whatever reason, back in the day Walter realized that it was no longer appropriate to call D's expanded typedef a typedef and so he gave it a sensible name that matched its expanded role much better. I'm not sure what's changed, but for some reason today he seems to have the attitude of "eh, a word is a word. What's it matter what we call it?". I have to agree with the pigs in Orwell's Animal farm on this one: "all words are equal, but some words are more equal than others."
Indeed words are important. Especially when language (English) understanding is poor ^_^ But I think enum is fine for new comer. Enumerate some constants in a file, just say enum a = 1, b = "hello", c = 3.14. To me it was always like enum was limited. Why did all have to be integers and why did all have to be a new type? Often you care for the value not type. Why did all enum value be part of a distinct type? I like it there is less restriction. About documentation. Maybe somebody here could write article about D const/invariant and put online. People here know very many things. Thank you, Dee Girl
May 20 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Dee Girl wrote:
 Sean Kelly Wrote:
 
 Robert Fraser wrote:
 Sean Kelly wrote:
 Dee Girl wrote:
 There is a little documentation about const invariant on the web 
 site. I read it. And also I read ACCU-functional. Is there more 
 documentation? Like conference paper or manual. Does Tango book 
 document const? Thank you, Dee Girl
At the time of writing, the design of const/invariant didn't seem finalized so we left it alone. And as far as I know, there are no papers or manuals on the subject. Nor documentation of the thought process behind the design.
There's http://www.digitalmars.com/d/2.0/const.html
It sounded like Dee Girl was asking for a formal paper or proposal.
Thank you both. Yes I was asking for something more. I think I understand how const/invariant works by doing test and reading Andrei ACCU slides and news group. The way const and invariant works is amazing. The most powerful I seen (better than javari!). But I hope I do not offend anyone if I say this. The article Here A Const, There A Const (http://www.digitalmars.com/d/2.0/const.html) I think is very very badly written. It is even better if the article is removed! It seems to me it has < 0 value.
You understood it "by doing tests"...? You did read http://www.digitalmars.com/d/2.0/const3.html , right? Although it doesn't explain the const design/rationale process, like Sean mentioned, I think it does a fair job of explaining the current const semantics. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 13 2008