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