www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unofficial wish list status.(Jul 2008)

reply 4tuu4k002 sneakemail.com writes:
Hi

This is the monthly status for the unofficial d wish list: 
http://all-technology.com/eigenpolls/dwishlist/

Right now the wish list looks like this:

178  Stack tracing (#26)
176  Reflection API (#6)
122  vectorization (#10)
100  Multiple return values (tuples (#28)
89  Multiple opCast per class (#24)
79  Debug check for null reference (#52)
76  Short syntax for new (#18)
75  Native AMD64 codegen (#36)
70  unit test after compilation (#1)
69  !in (#44)
67  extra compiler values (#19)
62  Return-type overloading (#49)
54  Explicit out/inout (#38)
52  Unit test isolation  (#2)
50  Foreach on first/on last (#42)
47  Posix threads support native (#3)
45  Array masking (#11)
43  Array pushback/popback (#51)
42  better syntax for cast (#23)
39  Explicit type initializers (#35)
38  Consistent struct/class sizeof (#40)
38  Variadic arguments re-passing (#102)
35  associative arrays by index (#16)
35  L-Value return (#73)
34  unit test & code separation (#7)
33  black box unit testing (#8)
33  coherent assoc. array syntax (#20)
32  Non-Static isExpression (#37)
31  Explicit module `friendship` (#43)
31  auto-member objects (#45)
31  Named keyword arguments (#87)
30  Pass value params byref (#34)
29  Conditional syncronized (#30)
29  struct constructor (#97)
28  Explicit property keyword (#83)
27  Unit test measurements (#9)
26  Renaming ctor/dtor (#17)
24  Inline enum declaration (#76)
23  User-defined sync function (#31)
21  proper cast operators (#21)
21  Iterators and Generators (#58)
21  if, while, true, false, int (#86)
21  Small Exectables (#88)
20  Pascal like sets (#61)
18  Built-in variant type (#56)
18  Precise names for floats (#62)
18  interface to C++ (#71)
15  D library contest (#59)
15  No Postfix Array Declarations (#85)
15  range type (#106)
15  Full lexical closures (#140)
13  Call log (#47)
13  Meta Information (#69)
13  modules must not rely on files (#84)
13  copy operator (#95)
12  conv() and opConv (#66)
12  Multi-Dimensional Allocation (#109)
11  inout variable and return (#60)
11  imag and comp FP types. (#63)
11  Finite sets (#72)
11  opCast overloading (#81)
11  Real C bitfields (#145)
10  Improve module architecture (#64)
10  garbage collection switch  (#96)
9  Against class instance sizeof (#48)
9  inline expansion (#67)
9  function inheritance (#92)
9  In flight exception detection (#101)
8  Relational class/array algebra (#65)
7  Parallel Scavenging GC (#80)
7  void Class.Method() {} syntax (#146)
7  in for arrays (#160)
7  Get rid of const (#165)
7  throws keyword (#173)
6  date/time/datetime literal (#105)
5  Statically check for == null (#98)
5  static foreach(scope/unscope) (#152)
4  Declaration in function calls (#74)
4  array in template arguments (#91)
4  support struct&array in switch (#99)
4  named tuple (#103)
4  Explicit out/inout/lazy (#110)
4  First-class continuations (#141)
4  Implicit New (#143)
4  Efficient array opCatAssign (#148)
4  in for arrays (#161)
4  suffix identifiers. (#168)
3  System.Windows.Forms (#93)
3  Reallocation Keyword (#108)
3  function call over network (#111)
3  Better UTF32 Support (#113)
3  Property shortcut (#144)
3  tuple literal and append-op (#151)
3  {Cleaner Operator Overloading} (#166)
3  Remove const (#171)
3  Remove const (#172)
2  Manage .resources files (#70)
2  Multistep return (#75)
2  constant operater overloading (#100)
2  solve interdepend static this (#107)
2  Quick For Syntax (#142)
2  variable template(short syntax (#149)
2  template literal (#150)
2  Custom Attributes (#159)
2  Keyword Pow Operator (#162)
2  Custom Syntax (#163)
2  C++ Member Pointers (#167)
2  Property declarator (#174)
1  consistant new (#77)
1  temp alias param specialize (#112)
1  remove initializers (#147)
1  __traits (#153)
1  ext property for  basic types (#154)
1  temporary variable (#155)
1  invariant function (#156)
1  Dynamic Conditional (#157)
1  constant member functions (#158)
1  templated constructors (#164)
1  New Switch Case Design (#170)
0  Better Array Function Template (#169)
Jun 30 2008
next sibling parent reply bearophile <bearophileHUGS lycos.co> writes:
4tuu4k002 sneakemail.com:
 This is the monthly status for the unofficial d wish list: 

It's curious to see that many or most of the top desired things don't seem among the list of the next things planned as improvements/changes for the D/DMD. I don't know what this means. Are people asking for unimportant things? Are the D designers smarter? Are the two groups ignoring each other? When I think about such matters I remember a quote, usually attributed to Henry Ford: "If I'd asked people what they wanted, they would have said a faster horse." So maybe D programmers want faster horses, while D developers are inventing/providing cars :-) I don't know. Bye, bearophile
Jun 30 2008
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Well, I don't think stack tracing is something that's going to be 
replaced by functional programming... could be, I guess.  Never say never.

-[Unknown]


bearophile wrote:
 4tuu4k002 sneakemail.com:
 This is the monthly status for the unofficial d wish list: 

It's curious to see that many or most of the top desired things don't seem among the list of the next things planned as improvements/changes for the D/DMD. I don't know what this means. Are people asking for unimportant things? Are the D designers smarter? Are the two groups ignoring each other? When I think about such matters I remember a quote, usually attributed to Henry Ford: "If I'd asked people what they wanted, they would have said a faster horse." So maybe D programmers want faster horses, while D developers are inventing/providing cars :-) I don't know. Bye, bearophile

Jun 30 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from bearophile (bearophileHUGS lycos.co)'s article
 4tuu4k002 sneakemail.com:
 This is the monthly status for the unofficial d wish list:

It's curious to see that many or most of the top desired things don't seem among the list of the next things

unimportant things? Are the D designers smarter? Are the two groups ignoring each other? For better or worse, I don't personally feel that the D designers listen to the D community at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's just that my goals with D simply diverged beginning with 2.0.
 When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what

 So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.

It's an interesting question, and one I've been mulling over for a few years now. My understanding is that C++ was created as a very community-driven effort right from the start while D was designed based very much on what Walter thought would be good in a language. As a result, C++ ended up bogged down with a lot of legacy C baggage that the community insisted was necessary for them to adopt C++, while D could change tracks on the designer's whim and no one could say otherwise. Generally, I think the D approach works far better so long as the designer's goals match the interests of the community, but it's a pretty risky path to follow since the designer is basically betting the farm on the hope that the community will agree with his vision. In the past I've been pretty free with my opinions about language features and I do this because I don't want to feel that I didn't try to make myself heard if I ever give up on D. At least then I can feel that I did my best to communicate to the designers what's important to me as a user of the language. Sean
Jun 30 2008
next sibling parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:

 == Quote from bearophile (bearophileHUGS lycos.co)'s article
 4tuu4k002 sneakemail.com:
 This is the monthly status for the unofficial d wish list:

It's curious to see that many or most of the top desired things don't seem among the list of the next things

unimportant things? Are the D designers smarter? Are the two groups ignoring each other? For better or worse, I don't personally feel that the D designers listen to the D community at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's just that my goals with D simply diverged beginning with 2.0.

wut the heck is ur problem sean, u were the only sane guy left at tango. now u r coming with badmouthing n shit. recently u were like "walter is trying 2 lure people to d2. if that happens, i'm out." where the fuck did that conspiracy theory come from. walter never did anything to put his integrity into question. now wuts with this walter doesn't listen shit. whining baby. i'm sayin': walter does listen and does do great shit, the only problem is that most of us don't know what we're talking about and can't remember what we want from 1 moment 2 the next. look at that list. it's a pile of shit with the most prefuckingposterous requests in the fucking history of fucking programming languages. look at vectorization. who the fuck came with that sick idea. hell, std.algorithm does that shit better and nicer and didn't need language changes. the list is a joke. it's not even maintained, d has had tuples for months now. somehow we want progress, n new shit n all but no we want it in d1 backward compatible and with only two extra pieces of shit that vary from 1 person 2 the next and from 1 minute 2 the next. shit. if walter were 2 implement all the shitty "features" in the motherfucking list the language would become a fucking pile of dung the size of fucking china. what the fuck. walter is cranking great shit like it's goin' outta style and we throw a fit because we didn't think of it first. we only thought of shitty misfeatures like short syntax for new. now what was that mofo's problem. shit.
 When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what

 So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.

It's an interesting question, and one I've been mulling over for a few years now. My understanding is that C++ was created as a very community-driven effort right from the start while D was designed based very much on what Walter thought would be good in a language. As a result, C++ ended up bogged down with a lot of legacy C baggage that the community insisted was necessary for them to adopt C++, while D could change tracks on the designer's whim and no one could say otherwise. Generally, I think the D approach works far better so long as the designer's goals match the interests of the community, but it's a pretty risky path to follow since the designer is basically betting the farm on the hope that the community will agree with his vision. In the past I've been pretty free with my opinions about language features and I do this because I don't want to feel that I didn't try to make myself heard if I ever give up on D. At least then I can feel that I did my best to communicate to the designers what's important to me as a user of the language.

u r wrong. bjarne has had control of language long time b4 it became successful. it's his vision 4 better or worse. u r looking at the success years of c++ when committees and crap came all over. don't panic when d will be successful with muggles there will be a committee over it like a cheap suit. so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r interested more in bitchin' than in making real suggestions. now seriously. speak up. what is it that u as a member of the community wanna say and walter doesn't listen.
Jun 30 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from superdan (super dan.org)'s article
 Sean Kelly Wrote:
 == Quote from bearophile (bearophileHUGS lycos.co)'s article
 4tuu4k002 sneakemail.com:
 This is the monthly status for the unofficial d wish list:

It's curious to see that many or most of the top desired things don't seem among the list of the next things

unimportant things? Are the D designers smarter? Are the two groups ignoring each other? For better or worse, I don't personally feel that the D designers listen to the D community at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's just that my goals with D simply diverged beginning with 2.0.


theory come from. walter never did anything to put his integrity into question. I was bothered by the fact that some issues that many people consider bugs in D 1.0 are only being fixed in D 2.0, and I ignored my better judgement and shot my mouth off. It was a mistake.
 now wuts with this walter doesn't listen shit. whining baby. i'm sayin':
walter does listen and does do great shit, the

the next. No offense, but um... speak for yourself. There are quite a few people here who are very talented and whose comments are not only consistent, but very well considered and quite well reasoned. But Walter has said himself that he has difficulty working with people in other than a face to face setting and it shows. Back when Andrei was still posting here someone asked what one should do to have a proposal considered or at least garner a response and the process was laid out very clearly. Since then, quite a few people have followed that process exactly and I can't remember any of the proposals getting a comment from either Walter or Andrei. If a tree falls in the forest and there's no one around to hear it, does it make a sound? And if a proposal is posted and it doesn't get a single response, has anyone read it? I know it's difficult to keep up with the posts in this NG and impossible to actually act on all of them, but even a "thanks" goes an incredibly long way in terms of making people feel like their comments matter.
look at that list. it's a pile of shit with the most prefuckingposterous
requests in the fucking history of fucking

better and nicer and didn't need language changes. std.algorithm does vectorization? I had no idea. Don's BLADE (?) package does though and it's totally awesome and also didn't require language changes, so the point is still valid.
 When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what

 So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.

It's an interesting question, and one I've been mulling over for a few years now. My understanding is that C++ was created as a very community-driven effort right from the start while D was designed based very much on what Walter thought would be good in a language. As a result, C++ ended up bogged down with a lot of legacy C baggage that the community insisted was necessary for them to adopt C++, while D could change tracks on the designer's whim and no one could say otherwise. Generally, I think the D approach works far better so long as the designer's goals match the interests of the community, but it's a pretty risky path to follow since the designer is basically betting the farm on the hope that the community will agree with his vision. In the past I've been pretty free with my opinions about language features and I do this because I don't want to feel that I didn't try to make myself heard if I ever give up on D. At least then I can feel that I did my best to communicate to the designers what's important to me as a user of the language.


muggles there will be a committee over it like a cheap suit. I suggest reading "The Design and Evolution of C++" if you haven't already. It's pretty clear that Bjarne validated much of C++ by asking influential C users about its features.
 so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real

listen. I've tried D2. I've read the spec as well. I simply don't like it. As for my suggestions, feel free to use the search feature in the digitalmars.com website, because many are here in this forum or D.announce. But you do have a point in that I have become quite weary of the D drama in general. I simply don't have the enthusiasm I used to, and that's entirely my own fault. This has been the longest I've ever worked on a personal programming project (at a guess, 4-5 years on Tango/Ares?) and I feel I've accomplished what I set out to do here, and that should be enough. I'll be better in the future about posting when I've had a bad day. My apologies. Sean
Jun 30 2008
next sibling parent reply Don <nospam nospam.com.au> writes:
Sean Kelly wrote:
 so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real

listen. I've tried D2. I've read the spec as well. I simply don't like it.

By D2, I imagine you just mean "the const system"? (Most of the other things in D2 seem to have been very popular; if D2- without-const was released, I reckon most of the community would start using it). It seems to me that the view of the community is "We though we wanted const. But now that we've seen what const involves, we don't want it.". At the very least, it's a public relations disaster from the point of view of the language designers. They are assuming that with more time and education, the legitimate complaints about first const system will be forgotten, and the const system will be embraced by the community. But there is a very big risk here -- what if it is NOT eventually accepted? What if the community concensus remains that const is just too complicated, without enough benefit? And the language designers remain steadfastly devoted to const? That's a catastrophic scenario, and unfortunately not unlikely. The fact that someone as senior in the community as yourself is expressing profound dissatisfaction indicates that the risk is very real.
Jul 01 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Don wrote:
 Sean Kelly wrote:
 so wut is that stuff u want in d. u haven't even tried d2 so it loox 
 like u r interested more in bitchin' than in making real

the community wanna say and walter doesn't listen. I've tried D2. I've read the spec as well. I simply don't like it.

By D2, I imagine you just mean "the const system"? (Most of the other things in D2 seem to have been very popular; if D2- without-const was released, I reckon most of the community would start using it). It seems to me that the view of the community is "We though we wanted const. But now that we've seen what const involves, we don't want it.".

I think there was a lot of hope on the part of the community that a const system designed from scratch with 20/20 hind-sight could avoid some of the practical problems with the C++ const system. But it seems the answer to that was "no". The system we've got now seems to solve some *theoretical* problems with the C++ const system at the cost of making practical usage slightly more cumbersome. But I don't hope for a more usable const any more. I'd just like to see a reduction in the number of flavors of D code. If we all moved to D2, I think we could pretty much just ignore invariant until it actually has some practical benefit. What's left of D2 const is pretty much like what many are used to with C++. Yeh, so you have to write some methods multiple times for different constnesses, etc... you get used to it. I think I could get used to D2 const anyway.
 At the very least, it's a public relations disaster from the point of
 view of the language designers. They are assuming that with more time
 and education, the legitimate complaints about first const system will
 be forgotten, and the const system will be embraced by the community.
 But there is a very big risk here -- what if it is NOT eventually
 accepted? What if the community concensus remains that const is just too
 complicated, without enough benefit? And the language designers remain
 steadfastly devoted to const? That's a catastrophic scenario, and
 unfortunately not unlikely.

 The fact that someone as senior in the community as yourself is
 expressing profound dissatisfaction indicates that the risk is very real.

It would be sad to see the D2 const swerve shake off all the old D supporters off the D train. But on the other hand, new folks do seem to keep popping up who would rather use D2 than D1. --bb
Jul 01 2008
next sibling parent reply "Me Here" <p9e883002 sneakemail.com> writes:
Bill Baxter wrote:

 Don wrote:
 Sean Kelly wrote:
 so wut is that stuff u want in d. u haven't even tried d2 so it loox
 like u r interested more in bitchin' than in making real

the community wanna say and walter doesn't listen. I've tried D2. I've read the spec as well. I simply don't like it.

By D2, I imagine you just mean "the const system"? (Most of the other things in D2 seem to have been very popular; if D2- without-const was released, I reckon most of the community would start using it). It seems to me that the view of the community is "We though we wanted const. But now that we've seen what const involves, we don't want it.".

I think there was a lot of hope on the part of the community that a const system designed from scratch with 20/20 hind-sight could avoid some of the practical problems with the C++ const system. But it seems the answer to that was "no". The system we've got now seems to solve some theoretical problems with the C++ const system at the cost of making practical usage slightly more cumbersome. But I don't hope for a more usable const any more. I'd just like to see a reduction in the number of flavors of D code. If we all moved to D2, I think we could pretty much just ignore invariant until it actually has some practical benefit. What's left of D2 const is pretty much like what many are used to with C++. Yeh, so you have to write some methods multiple times for different constnesses, etc... you get used to it. I think I could get used to D2 const anyway.
 At the very least, it's a public relations disaster from the point of
 view of the language designers. They are assuming that with more time
 and education, the legitimate complaints about first const system will
 be forgotten, and the const system will be embraced by the community.
 But there is a very big risk here -- what if it is NOT eventually
 accepted? What if the community concensus remains that const is just too
 complicated, without enough benefit? And the language designers remain
 steadfastly devoted to const? That's a catastrophic scenario, and
 unfortunately not unlikely.
 
 The fact that someone as senior in the community as yourself is
 expressing profound dissatisfaction indicates that the risk is very real.

It would be sad to see the D2 const swerve shake off all the old D supporters off the D train. But on the other hand, new folks do seem to keep popping up who would rather use D2 than D1. --bb

The problem with D2, is that it is optimising (prematurly) for the lazy, at the expense of the dilligent. The functional utopia of transparent threading through purity only succeeds in dealing with the most trivial forms of shared access--and grossly inefficiently at that. Side-effects are par for the course in software. Whether its printing/reading to/from the screen; or reading or writing from/to a file, or port or socket or DB. These things cannot be avoided in any *useful program*, and "purity" goes out the window as soon as you do any one of them. Once you accept that fact, and realise that shared access to memory is the least of the thread users problems, all the hyperbole about purity and referential transparency goes right out the window. Besides which, all that (unnecessary and unavoidable) replication of data goes entirely against the grain of the original D ethos, and completely inhibits efficient algorithms for dealing with thread-shared data.. For example: The most efficient way to use multiple cores or processors to manipulate large arrays, is to run multiple, indentical threads *each processesing its own, unique partition of the gross data. D2's ponchant for replicating whole data structures every time you look at the thing, completely inhibots this, tried, tested and proven technique for making use of shared data and threading. By way of proof. If you have a vanilla, threaded, Perl installed, run this: #! perl -slw use strict; use Tim e:HiRes qw[ sleep ]; use threads; use threads::shared; $|++; sub thread{ my( $ref, $pos ) = _; while( sleep 0.1 ) { substr( $$ref, $pos, 1 ) =~ tr[A-Z][B-ZA]; } my $s :shared = join( '', 'A' .. 'Z' ) x 3; my threads = map{ threads->create( \&thread, \$s, $_ ) } 0 .. 77; sleep 1; printf "\r$s\t" while sleep 0.05; For those that do not have Perl, what those that do will see, it the inline-scrolling (html marque-style) line of text with three copies of the alphabet rotating left. Now, that's trivial I here you all cry, but get this. Each character on that line is being manipualted by a different thread. Try replicating that using D2 (or Haskell which seems to be the inspiration for the current trend in D2 direction). Now imagine all the concurrent processing problems that can be efficiently dealt with using the "add & multiply" concurrent processing techniqur. From image processing--whether jpgs, x-ray, radar, mri or crt scans; weather prediction; finite element analysis for construction, automotive, boat design, etc. etc. etc; audio and video compression; cryptographical analysis; neuclear weapon analysis; space flight calculation; Genome analysis; weapons trajectories; .... The list is endless. In each of these fields, partitioning a single large dataset and running separate, indentical threads on each section is fundemental to efficient processing of these algorithms. and replicating entire datastructures each time any single element of them is mutated is grossly, insanely, *stupidly* inefficient. Total madness. Rather than getting 80-90% time-based gains from each extra processor, you ruduce that to 35-40%, with the rest spent thrashing the memory allocator/GC to death *needlessly replicating mutated data*! Walter: Please, please, please. Take a break. A holiday (far away from Andrie) and apply your own, rational, non-hyped thought processes to this problem. (Stay off the purity cool-aid for a few days). Do a little research into the types of problems and algorithms that truely lend themselves to being multi-threaded and analyse the effects of all that damn, unwanted and uncontrollable replication. Web servers and other IO-bound processes are *not* the target of multithreading. Take a close look at the sort of algorithms that the IBM/SONY/etc. Cube processor is targetted at. (It's the core behind the latest greatest teraflops super-computers), and there is a really good reason for that. Running simple, compact, highly localised algorithms on vast quantities of simlar data is the bread and butter of efficient concurrency. All that replication to achieve "transparent referential integrity" doesn't mean a damn thing for this type of algorithm. It simply slows everything to a crawl. If these super computer kept destroying there local L1 & L2 caches by replicating data every time it mutated, those teraflops systems would be "total flop" sysems. For dogs sakes. get a grip, smell the coffee, kick the purity habit and send Andrie packing back to the "design by commitee" that produces STL.. With respect, but concrete, contrary knowledge, b. --
Jul 01 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Me Here Wrote:
 Web servers and other IO-bound processes are *not* the target of
 multithreading.

How do functional programming styles apply better to I/O-bound systems? I couldn't imagine writing a query processor using monads for all I/O. Functional programming works well for a subset of applications which require concurrency. The question is: is this subset large enough to justify designing a language's concurrency support around this paradigm? Is it large enough to justify forcing additional language constructs (const) for applications that don't use this paradigm to handle their concurrency? For non-concurrent applications? Of course, there are other arguments for a const system (static checking of interfaces, etc.) But what other major new statically-typed languages (besides D) have such a system? Java mostly threw it out (there's final fields & what not). C-pound threw out even more of it. I ahve the same feelings towards const-as-interface as I do towards checked exceptions: sounds great on paper, but ends up wasting the developer's time. (apologies for the web interface; work)
Jul 01 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Brad Roberts Wrote:
 Functional or not isn't a whole program decision (at least within D and 
 it's future as it seems to be unfolding).  Within most, if not all, 
 applications, there are reasonable subsets that are, or could be, 
 functional style.  Many are already, without language support to help 
 enforce the style or take advantage of the benefits.

The "benefits" of automatic parallelization can only be seen on a macro scale. For trivial functions, even if there's an array scan involved, it will most likely be more overhead than good. Most imperative systems will need to be redesigned if they want to take advantage of these things... not that that's a bad thing. But once again, the question is: do the benefits outweigh the costs?
 Everyone has their opinion, and aren't we glad for that privilege.  The 
 nice part is that const is optional.  There's only a very few places where 
 that leaks out, the obvious example being the phobos definition of 
 'string' and that's avoidable.  The current implementation of phobos is 
 far from perfect (don't start that thread, please) in it's use of const, 
 but that's part of being an alpha version.  As it evolves, applications 
 and libraries should be able to choose to ignore const completely.  Any 
 part of phobos or the compiler that gets in the way of NOT using const, 
 should be examined quite carefully.

That's true... if you're one developer working on an application. But that's not true if you're writing a library -- some of people won't use your library if it doesn't support const. But, yes, in the end it's just a matter of opinion on what the right language design is.
Jul 01 2008
prev sibling parent reply "Me Here" <p9e883002 sneakemail.com> writes:
Robert Fraser wrote:

 Me Here Wrote:
 Web servers and other IO-bound processes are not the target of
 multithreading.

How do functional programming styles apply better to I/O-bound systems? I couldn't imagine writing a query processor using monads for all I/O.

No. You missed my (badly worded) point. I perhaps should have said: Of course, webservers and other IO-bound processes... I was referring back to my earlier point that "Side-effects are par for the course in software.". And the fact that many, maybe even a majority of strong applications for threading aren't IO-bound, which makes it /seem/ as if functional techniques lend themselves to the transparent threading of compute-bound processing. But, as I then pointed out, the problem with the way D2 handles the mutation of arrays (strings and others), is that it flies in the face of those bread&butter concurrency algorithms that manipulate large datasets (images and the like) with add&multiply algorithms, by setting multiple threads to operate on different segments of the same datastructure. These would be completely hamstrung by the unnecessary and uncontrolled replication. The best way to handle concurrent access to shared resources, is to avoid concurrent access. For IO and other external shared resources, you serialise access to them through queuing or message passing to a single thread that acts on the behalf of others. For memory, you avoid concurrent access by partitioning the dataset. Ie, you pass each thread a constrained alias to just that part of the dataset you wish it to operate upon. Each thread can then operate upon its partition at full speed, without locking, and without restrictions upon the operations it can perform. Replicating entire arrays everytime something mutates an element within it, is a complete nonsense. It basically throws away the very advantage of having shared memory in the first place. And shared memory is the very reason detre of threading. I love functional techniques. Perl's map, grep, reduce and kin are one of its greatest assets, but using purity to attempt to simplify threading fails dismally. It creates work and impacts performance for *everyone not using threads*, and those using them whenever they *don't need the protection*, in order to "simplify" things for those that are using threads and know they would otherwise need to take precautions. It's like drawing solid white lines across major roads before every side turning and on-ramp, to force the main flow to check if someone wants to turn on to the major road, so that those turning onto the major road don't have to check if anything is coming. The priorities are backwards. This isn't a rail against functional techniques or languages. Its an informed reality check to weight the many costs against the few benefits, and to consider the rarity of the occasions when those few benefits will actually occur. I'll say it again. D was my great white hope for compiled language performance and integrity checking, rational semantics and threading. But this issue, and to some degree, the whole templating thing, seem to have side-tracked the development process and the original clean vision of D and (IMO) are leading it off in directions that are utopic in vision, but imprqactical in reality. b. --
Jul 02 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Me Here wrote:
 For memory, you avoid concurrent access by partitioning the dataset. Ie, you
 pass each thread a constrained alias to just that part of the dataset you wish
 it to operate upon. Each thread can then operate upon its partition at full
 speed, without locking, and without restrictions upon the operations it can
 perform. Replicating entire arrays everytime something mutates an element
 within it, is a complete nonsense. It basically throws away the very advantage
 of having shared memory in the first place. And shared memory is the very
 reason detre of threading.

There's nothing about D 2.0 which would prevent you from doing this. D 2.0 is still a systems programming language which will let you do whatever you want with your data.
Jul 02 2008
parent reply "Me Here" <p9e883002 sneakemail.com> writes:
Walter Bright wrote:

 Me Here wrote:

 element within it, is a complete nonsense. It basically throws away the
 very advantage of having shared memory in the first place. And shared
 memory is the very reason detre of threading.

There's nothing about D 2.0 which would prevent you from doing this. D 2.0 is still a systems programming language which will let you do whatever you want with your data.

So, in D2, if a pass an slices of an array to several threads and they mutate those slices, when the threads end, the main thread can see (and further manipulate) the results of their work by simply iterating the original array? b. --
Jul 02 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Me,

 Walter Bright wrote:
 
 Me Here wrote:
 

 element within it, is a complete nonsense. It basically throws away
 the very advantage of having shared memory in the first place. And
 shared memory is the very reason detre of threading.
 

D 2.0 is still a systems programming language which will let you do whatever you want with your data.

mutate those slices, when the threads end, the main thread can see (and further manipulate) the results of their work by simply iterating the original array? b.

unless, the threads extend the slice. :(
Jul 02 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Me Here wrote:
 Walter Bright wrote:
 There's nothing about D 2.0 which would prevent you from doing this. D 2.0 is
 still a systems programming language which will let you do whatever you want
 with your data.

So, in D2, if a pass an slices of an array to several threads and they mutate those slices, when the threads end, the main thread can see (and further manipulate) the results of their work by simply iterating the original array?

Yes, but the onus will be on you (the programmer) to prevent data races and do proper synchronization. You have to be very wary of cache effects when writing data in one thread and expecting to see it in another.
Jul 02 2008
parent "Me Here" <p9e883002 sneakemail.com> writes:
Walter Bright wrote:

 Yes, but the onus will be on you (the programmer) to prevent data races and
 do proper synchronization.   

In the scenario described, the main thread initialises the array of data. Then, non-overlapping slices of that are portioned out to N worker threads. Only one thread ever modifies any given segment. When the worker threads are complete, the 'results' are left in the original array available in its entirety only to the main thread.
You have to be very wary of cache effects when
 writing data in one thread and expecting to see it in another.

Are you saying that there is some combination of OS and/or hardware L1/L2 caching that would allow one thread to read a memory location (previously) modified by another thread, and see 'old data'? Cos if you are, its a deeply serious bug that if its not already very well documented by the OS writer or hardware manufacturers, then here's your chance to get slashdotted (and diggited and redited etc. all concurrently) as the discoveerer of a fatel processor flaw. b. --
Jul 03 2008
prev sibling next sibling parent Ralf Schneider <ralfs72 googlemail.com> writes:
 Walter: Please, please, please. Take a break. A holiday (far away from Andrie)
 and apply your own, rational, non-hyped thought processes to this problem.
 (Stay off the purity cool-aid for a few days). Do a little research into the
 types of problems and algorithms that truely lend themselves to being
 multi-threaded and analyse the effects of all that damn, unwanted and
 uncontrollable replication.

... And take a break from http://www.reddit.com/r/programming/ Reddit does NOT reflect the current research status nor does it reflect the opinion of the majarority of programmers and it offers no outlook into the future! Reddit is a self supporting system of some LISP / Functional Programming Zealots. People there are going Bonkers if someone posts a pong clone in Haskell/Lisp/RoR or what ever.
Jul 01 2008
prev sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Tue, 1 Jul 2008, Robert Fraser wrote:

 Me Here Wrote:
 Web servers and other IO-bound processes are *not* the target of
 multithreading.

How do functional programming styles apply better to I/O-bound systems? I couldn't imagine writing a query processor using monads for all I/O. Functional programming works well for a subset of applications which require concurrency. The question is: is this subset large enough to justify designing a language's concurrency support around this paradigm? Is it large enough to justify forcing additional language constructs (const) for applications that don't use this paradigm to handle their concurrency? For non-concurrent applications?

Functional or not isn't a whole program decision (at least within D and it's future as it seems to be unfolding). Within most, if not all, applications, there are reasonable subsets that are, or could be, functional style. Many are already, without language support to help enforce the style or take advantage of the benefits.
 Of course, there are other arguments for a const system (static checking 
 of interfaces, etc.) But what other major new statically-typed languages 
 (besides D) have such a system? Java mostly threw it out (there's final 
 fields & what not). C-pound threw out even more of it. I have the same 
 feelings towards const-as-interface as I do towards checked exceptions: 
 sounds great on paper, but ends up wasting the developer's time.
 
 (apologies for the web interface;   work)

Everyone has their opinion, and aren't we glad for that privilege. The nice part is that const is optional. There's only a very few places where that leaks out, the obvious example being the phobos definition of 'string' and that's avoidable. The current implementation of phobos is far from perfect (don't start that thread, please) in it's use of const, but that's part of being an alpha version. As it evolves, applications and libraries should be able to choose to ignore const completely. Any part of phobos or the compiler that gets in the way of NOT using const, should be examined quite carefully. Personally, if/when I end up using D for anything serious, I will be using const, as I like the guarantees that it allows me to have. I _do_ like contracts and languages such as Java annoy me every time I'm forced to work with it in part due to the lack of them. Later, Brad
Jul 01 2008
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:g4cp3p$rkc$1 digitalmars.com...

 It would be sad to see the D2 const swerve shake off all the old D 
 supporters off the D train.  But on the other hand, new folks do seem to 
 keep popping up who would rather use D2 than D1.

I kind of wonder if half of them are simply tricked by the DM site into thinking that D2 is actually out and usable. It tends to guide you to D2.
Jul 01 2008
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote
 What's left of D2 const is pretty much like what many are used to with 
 C++.  Yeh, so you have to write some methods multiple times for different 
 constnesses, etc... you get used to it.

Slightly OT, the "scoped const" proposal I made a while back would help solve this: http://d.puremagic.com/issues/show_bug.cgi?id=1961 The main complaint from Andrei and Walter seems to be that any new features or solutions that involve const will make it "too complicated." If you want to know my response to that, read my latest comment: http://d.puremagic.com/issues/show_bug.cgi?id=1961#c11 IMHO, I think Walter and Andrei hide behind the "can't do that because it will make people like const less" defense much too often, especially when it is a purely political defense (one that cannot ever be disproven unless the proposal in question is implemented). -Steve
Jul 01 2008
prev sibling parent superdan <super dan.org> writes:
Bill Baxter Wrote:

 Don wrote:
 Sean Kelly wrote:
 so wut is that stuff u want in d. u haven't even tried d2 so it loox 
 like u r interested more in bitchin' than in making real

the community wanna say and walter doesn't listen. I've tried D2. I've read the spec as well. I simply don't like it.

By D2, I imagine you just mean "the const system"? (Most of the other things in D2 seem to have been very popular; if D2- without-const was released, I reckon most of the community would start using it). It seems to me that the view of the community is "We though we wanted const. But now that we've seen what const involves, we don't want it.".

I think there was a lot of hope on the part of the community that a const system designed from scratch with 20/20 hind-sight could avoid some of the practical problems with the C++ const system. But it seems the answer to that was "no". The system we've got now seems to solve some *theoretical* problems with the C++ const system at the cost of making practical usage slightly more cumbersome. But I don't hope for a more usable const any more. I'd just like to see a reduction in the number of flavors of D code. If we all moved to D2, I think we could pretty much just ignore invariant until it actually has some practical benefit. What's left of D2 const is pretty much like what many are used to with C++. Yeh, so you have to write some methods multiple times for different constnesses, etc... you get used to it. I think I could get used to D2 const anyway.

good point. i'm thinkin' it is useful today actually for the sakes of string alone. string is a blessed godsend. without string sure as fuck there's no hope to write ten fucking lines of scripting code or 100 lines of serious code 4 that matter. d1 strings are fucked. and the more app grows the more fucked they are coz nobody in hell knows who aliased them just to fuck with them later.
  > At the very least, it's a public relations disaster from the point of
  > view of the language designers. They are assuming that with more time
  > and education, the legitimate complaints about first const system will
  > be forgotten, and the const system will be embraced by the community.
  > But there is a very big risk here -- what if it is NOT eventually
  > accepted? What if the community concensus remains that const is just too
  > complicated, without enough benefit? And the language designers remain
  > steadfastly devoted to const? That's a catastrophic scenario, and
  > unfortunately not unlikely.
  >
  > The fact that someone as senior in the community as yourself is
  > expressing profound dissatisfaction indicates that the risk is very real.
 
 It would be sad to see the D2 const swerve shake off all the old D 
 supporters off the D train.  But on the other hand, new folks do seem to 
 keep popping up who would rather use D2 than D1.

i lurked here on & off 4 quite a while since the d1 days (who the fuck made me unlurk? shit) but i used d2 as soon as it appeared. but then i use os betas and shit. d1 is cute but due for retirement. nobody will switch 2 d1 from 1other real language. there's just not enough shit in d1 to compel. but d2 really fucks all other language's girlfriends. has tons of amazing shit already and is ready 2 bag threads. now when that happens every1 will want to use d2 or copy it.
Jul 01 2008
prev sibling next sibling parent reply superdan <super dan.org> writes:
Don Wrote:

 Sean Kelly wrote:
 so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real

listen. I've tried D2. I've read the spec as well. I simply don't like it.

By D2, I imagine you just mean "the const system"? (Most of the other things in D2 seem to have been very popular; if D2- without-const was released, I reckon most of the community would start using it). It seems to me that the view of the community is "We though we wanted const. But now that we've seen what const involves, we don't want it.". At the very least, it's a public relations disaster from the point of view of the language designers. They are assuming that with more time and education, the legitimate complaints about first const system will be forgotten, and the const system will be embraced by the community. But there is a very big risk here -- what if it is NOT eventually accepted? What if the community concensus remains that const is just too complicated, without enough benefit? And the language designers remain steadfastly devoted to const? That's a catastrophic scenario, and unfortunately not unlikely. The fact that someone as senior in the community as yourself is expressing profound dissatisfaction indicates that the risk is very real.

here's 1 problem as i c it. is d catering 2 current community exclusively? dun think so. then u want to attract other ppl from the outside world. 2 those the history of const means shit. they want a good system. c++ refugees will sure want 1. java refugees will see it as an advantage. p.s. also thanks don 4 all great work u've done 4 d.
Jul 01 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
superdan wrote:
 Don Wrote:
 
 Sean Kelly wrote:
 so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real

listen. I've tried D2. I've read the spec as well. I simply don't like it.

(Most of the other things in D2 seem to have been very popular; if D2- without-const was released, I reckon most of the community would start using it). It seems to me that the view of the community is "We though we wanted const. But now that we've seen what const involves, we don't want it.". At the very least, it's a public relations disaster from the point of view of the language designers. They are assuming that with more time and education, the legitimate complaints about first const system will be forgotten, and the const system will be embraced by the community. But there is a very big risk here -- what if it is NOT eventually accepted? What if the community concensus remains that const is just too complicated, without enough benefit? And the language designers remain steadfastly devoted to const? That's a catastrophic scenario, and unfortunately not unlikely. The fact that someone as senior in the community as yourself is expressing profound dissatisfaction indicates that the risk is very real.

here's 1 problem as i c it. is d catering 2 current community exclusively? dun think so. then u want to attract other ppl from the outside world. 2 those the history of const means shit. they want a good system. c++ refugees will sure want 1. java refugees will see it as an advantage. p.s. also thanks don 4 all great work u've done 4 d.

If I had a Euro for each time you used bad language, I'd be at least a few hundred Euros richer. This is not a forum for 10 year olds discussing their zits. If I can use a fucking spell-checker, so can you. remember, readers of this NG are from all over the world, and it would be the proper and polite thing to do to at least use proper English to make it easier for them to understand what you said. Besides, if you want to be taken seriously, using that kind of language does not help your cause. Grow up, this is not ICQ. --Yigal
Jul 01 2008
parent reply superdan <super dan.org> writes:
Yigal Chripun Wrote:

 superdan wrote:
 Don Wrote:
 
 Sean Kelly wrote:
 so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real

listen. I've tried D2. I've read the spec as well. I simply don't like it.

(Most of the other things in D2 seem to have been very popular; if D2- without-const was released, I reckon most of the community would start using it). It seems to me that the view of the community is "We though we wanted const. But now that we've seen what const involves, we don't want it.". At the very least, it's a public relations disaster from the point of view of the language designers. They are assuming that with more time and education, the legitimate complaints about first const system will be forgotten, and the const system will be embraced by the community. But there is a very big risk here -- what if it is NOT eventually accepted? What if the community concensus remains that const is just too complicated, without enough benefit? And the language designers remain steadfastly devoted to const? That's a catastrophic scenario, and unfortunately not unlikely. The fact that someone as senior in the community as yourself is expressing profound dissatisfaction indicates that the risk is very real.

here's 1 problem as i c it. is d catering 2 current community exclusively? dun think so. then u want to attract other ppl from the outside world. 2 those the history of const means shit. they want a good system. c++ refugees will sure want 1. java refugees will see it as an advantage. p.s. also thanks don 4 all great work u've done 4 d.

If I had a Euro for each time you used bad language, I'd be at least a few hundred Euros richer.

and if i had 1 zimbabwe hyperinflated dollar for every time dee girl handed ur sorry ass on a silver plate, i'd be richer still. u r the second best example of what's bad in this group. u obviously have no idea what u r talking about. u misuse terms left & right. u can't understand the consequences of ur own rules and ideas (4 the lack of a better word). probably ur source of inspiration is fucking wikipedia. u can't tell an alias, delegate, and stack frame from as many holes in the ground. yet u keep on coming confident & cocky & shit and teach people shit around here. good think dee girl showed u clear & good what a fraud u r. go read some shit will ya. geez.
 This is not a forum for 10 year olds discussing their zits. If I can use
 a fucking spell-checker, so can you. remember, readers of this NG are
 from all over the world, and it would be the proper and polite thing to
 do to at least use proper English to make it easier for them to
 understand what you said.

relax. i do use a spell checker. just had to add a couple words.
 Besides, if you want to be taken seriously,
 using that kind of language does not help your cause. Grow up, this is
 not ICQ.

in all likelihood i'm older than u but anyhow, since when was age a discriminating factor. thought it's the shit u know or u don't, but since u don't know none, u go with the age thing. got it. u don't like me killfile me. won't change my id.
Jul 01 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to superdan,

The way you wright is hard to read. If you keep doing it people will just 
quit reading you. I tend to do thing by setting a filter to automatically 
mark people a read. Some people set the filter to delete. Regardless, if 
you keep it up, you might as well talk to a wall for all the good it will do.

It is barely worth my time to tell you this. It is not worth my time to further 
debate it.
Jul 01 2008
parent reply superdan <super dan.org> writes:
BCS Wrote:

 Reply to superdan,
 
 The way you wright is hard to read. If you keep doing it people will just 
 quit reading you. I tend to do thing by setting a filter to automatically 
 mark people a read. Some people set the filter to delete. Regardless, if 
 you keep it up, you might as well talk to a wall for all the good it will do.

u almost had me... pardon. you almost had me until i saw "wright". shit man. that fucks your entire argument right there. ok i can write without leet and shit but if something is fucked up its ass i will say it is fucked up its ass. and if u ever use wright instead of write i swear i will beat u with the heel of my shoe. okay?
Jul 01 2008
next sibling parent superdan <super dan.org> writes:
superdan Wrote:

 BCS Wrote:
 
 Reply to superdan,
 
 The way you wright is hard to read. If you keep doing it people will just 
 quit reading you. I tend to do thing by setting a filter to automatically 
 mark people a read. Some people set the filter to delete. Regardless, if 
 you keep it up, you might as well talk to a wall for all the good it will do.

u almost had me... pardon. you almost had me until i saw "wright". shit man. that fucks your entire argument right there. ok i can write without leet and shit but if something is fucked up its ass i will say it is fucked up its ass. and if u ever use wright instead of write i swear i will beat u with the heel of my shoe. okay?

i meant "you" not "u". shit. but at least i'm tryin'.
Jul 01 2008
prev sibling parent BCS <ao pathlink.com> writes:
good bye
Jul 01 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
superdan Wrote:
 in all likelihood i'm older than u but anyhow, since when was age a
discriminating factor. thought it's the shit u know or u don't, but since u
don't know none, u go with the age thing. got it.
 
 u don't like me killfile me. won't change my id.

He was trying to help you out by explaining that unless you're on an MMO or instant messenger, typing that way conveys certain assumptions. Your posts seem moderately intelligent in content, but it's difficult for many people here to take them seriously (i.e. as anything more than trolling) if you type that way. If your intent is to troll, then ignore/flame this post, but if your intent is to actually have a discussion consider reducing your use of swear words, using correct mechanics (i.e. punctuation and capitalization) and not using shortened forms of words. Otherwise, no one will see your posts as anything more than flamebait/junk, and the topics you wish to discuss will get lost. Also, if your intent is to troll, search the archives for "Ty Tower," he was (a little) better at it.
Jul 01 2008
parent superdan <super dan.org> writes:
Robert Fraser Wrote:

 superdan Wrote:
 in all likelihood i'm older than u but anyhow, since when was age a
discriminating factor. thought it's the shit u know or u don't, but since u
don't know none, u go with the age thing. got it.
 
 u don't like me killfile me. won't change my id.

He was trying to help you out by explaining that unless you're on an MMO or instant messenger, typing that way conveys certain assumptions. Your posts seem moderately intelligent in content, but it's difficult for many people here to take them seriously (i.e. as anything more than trolling) if you type that way. If your intent is to troll, then ignore/flame this post, but if your intent is to actually have a discussion consider reducing your use of swear words, using correct mechanics (i.e. punctuation and capitalization) and not using shortened forms of words. Otherwise, no one will see your posts as anything more than flamebait/junk, and the topics you wish to discuss will get lost.

ok will conform. what can i do? but if i can't fuckshit now and then i'm fucked. can't fuckshit at work. can't fuckshit at home. now i can't fuckshit on the internet? what's this world coming to? one more thing. could you please nicely with sugar on top explain what i did to that bcs fella? thought i was trying to be nice to him.
 Also, if your intent is to troll, search the archives for "Ty Tower," he was 
 (a little) better at it.

never got his train of logic, if it ever left the station. that dood is due for some serious detox.
Jul 01 2008
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Don wrote:
 Sean Kelly wrote:
 so wut is that stuff u want in d. u haven't even tried d2 so it loox 
 like u r interested more in bitchin' than in making real

the community wanna say and walter doesn't listen. I've tried D2. I've read the spec as well. I simply don't like it.

By D2, I imagine you just mean "the const system"?

No. Pretty much all of D2 actually, if I wanted to pick nits. But the const system is what I have the greatest distaste for from a functional perspective.
 (Most of the other things in D2 seem to have been very popular; if D2- 
 without-const was released, I reckon most of the community would start 
 using it).

I'd certainly be more open to giving it a shot, particularly since I could then use it with few if any modifications to my code.
 It seems to me that the view of the community is "We though we wanted 
 const. But now that we've seen what const involves, we don't want it.".

Personally, after spending some time with D I didn't miss const in the least. But perhaps more importantly, I trusted that if D ever got a const system it would be something that matched the simplicity and elegance of the rest of the language. Unfortunately, I don't feel that this is the case with the current design.
 At the very least, it's a public relations disaster from the point of 
 view of the language designers. They are assuming that with more time 
 and education, the legitimate complaints about first const system will 
 be forgotten, and the const system will be embraced by the community.
 But there is a very big risk here -- what if it is NOT eventually 
 accepted? What if the community concensus remains that const is just too 
 complicated, without enough benefit? And the language designers remain 
 steadfastly devoted to const? That's a catastrophic scenario, and 
 unfortunately not unlikely.

I honestly can't say whether I'll ever "come around" and decide I like D2, but so far this seems unlikely. But what does this mean in the long-term? None of the alternatives I've considered seem terribly appealing. Sean
Jul 20 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 What if the community concensus remains that const is just too 
 complicated, without enough benefit?

A simpler const system (such as what C++ has) has little benefit, and all the other const proposals were much more complex.
Jul 20 2008
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g6188e$smu$1 digitalmars.com...
 Don wrote:
 What if the community concensus remains that const is just too 
 complicated, without enough benefit?

A simpler const system (such as what C++ has) has little benefit, and all the other const proposals were much more complex.

I think what he's getting at here is that the community concensus might just be that const-correctness, at least C-style const-correctness (from which the D2 system is derived), is not good, not that we want a simpler system. Why bother, nothing's going to change.
Jul 21 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Don wrote:
 What if the community concensus remains that const is just too 
 complicated, without enough benefit?

A simpler const system (such as what C++ has) has little benefit, and all the other const proposals were much more complex.

I'm interested enough in the new const system to try it out, but my projects are dependent on Tango. I do have a few concerns about the const system, but nothing big enough to keep me from trying it. By far, my biggest complaint is that the const system makes only one of the following two methods compile. It forces programmers to settle for using global variables to bypass const restrictions. It also touches upon why the purity is required when doing multithreading. I can't fully embrace const until it stops encouraging global variables and the gap between purity and const is reduced/eliminated. ============= logFile log; class foo{ void bar() invariant{ log.write("Hello World"); } } ============= class Foo{ logFile log; void bar() invariant{ log.write("Hello World"); } } =============
Jul 21 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 By far, my biggest complaint is that the const system makes only one
 of the following two methods compile.  It forces programmers to
 settle for using global variables to bypass const restrictions.  It
 also touches upon why the purity is required when doing
 multithreading.  I can't fully embrace const until it stops
 encouraging global variables and the gap between purity and const is
 reduced/eliminated.
 
 =============

 log.write("Hello World"); } } ============= class Foo{ logFile log; 
 void bar() invariant{ log.write("Hello World"); } } =============

But the bar() function is not invariant, nor can it be pure if it writes things to global state. I am not sure why bar() needs to be pure, but it *cannot* be pure if it changes either global state or the state of one of its arguments.
Jul 21 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Jason House wrote:
 By far, my biggest complaint is that the const system makes only one
 of the following two methods compile.  It forces programmers to
 settle for using global variables to bypass const restrictions.  It
 also touches upon why the purity is required when doing
 multithreading.  I can't fully embrace const until it stops
 encouraging global variables and the gap between purity and const is
 reduced/eliminated.
 
 =============

 log.write("Hello World"); } } ============= class Foo{ logFile log; 
 void bar() invariant{ log.write("Hello World"); } } =============

But the bar() function is not invariant,

That depends on which version of bar you're talking about. The first bar conforms to the current D standard for invariance. Everything in class foo remains untouched in the first example, and so bar is invariant.
 nor can it be pure if it writes 
 things to global state. I am not sure why bar() needs to be pure, but it 
 *cannot* be pure if it changes either global state or the state of one 
 of its arguments.

That's exactly right. So what purpose is declaring bar as invariant serving? It's not supporting functional-style multithreading, but wasn't that the point for the const system? Since transitive const is already viral, it makes little sense to me that it shouldn't extend to static/global state. That removes the temptation of programmers to use static/global state to circumvent the const system. If that's problematic, then IMHO, something must be re-thought because it means people's use of D's const system will not support the functional-style multithreading because people are using it the wrong way.
Jul 22 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 Walter Bright Wrote:
 
 Jason House wrote:
 By far, my biggest complaint is that the const system makes only
 one of the following two methods compile.  It forces programmers
 to settle for using global variables to bypass const
 restrictions.  It also touches upon why the purity is required
 when doing multithreading.  I can't fully embrace const until it
 stops encouraging global variables and the gap between purity and
 const is reduced/eliminated.
 
 =============

 log.write("Hello World"); } } ============= class Foo{ logFile
 log; void bar() invariant{ log.write("Hello World"); } }
 =============


That depends on which version of bar you're talking about. The first bar conforms to the current D standard for invariance. Everything in class foo remains untouched in the first example, and so bar is invariant.

True, but it is not pure. Pure functions cannot change global state.
 nor can it be pure if it writes things to global state. I am not
 sure why bar() needs to be pure, but it *cannot* be pure if it
 changes either global state or the state of one of its arguments.

That's exactly right. So what purpose is declaring bar as invariant serving?

I don't know why it needed to be marked as invariant (I didn't write it <g>).
 It's not supporting functional-style multithreading, but
 wasn't that the point for the const system?

It is one of the points of the const system. But the idea is not to just declare things invariant and magically they will work in functional style. The idea is that if you want to make something functional, the language will provide support for it if only in the form of telling you when something will not work in functional style. That appears to be the case with bar() - it cannot work in functional style.
 Since transitive const
 is already viral, it makes little sense to me that it shouldn't
 extend to static/global state.  That removes the temptation of
 programmers to use static/global state to circumvent the const
 system.  If that's problematic, then IMHO, something must be
 re-thought because it means people's use of D's const system will not
 support the functional-style multithreading because people are using
 it the wrong way.

The missing ingredient here is what the 'pure' modifier for functions provides. That is the ability to diagnose attempts to alter global state from within a function that is not supposed to do that. Invariant does not imply pure. These concepts are not simple, but there is no way to support shared state in multithreaded programming without understanding those concepts. C++ the language has no concept of these things, and people get into endless trouble with it when misunderstanding things and screwing it up. The C++ language itself is of NO help at all. With D, the idea is to enable the language to help by moving things from convention to law. Completely ignoring the issues, like C++ does, is no solution.
Jul 22 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Jason House wrote:
 Walter Bright Wrote:

 Jason House wrote:
 By far, my biggest complaint is that the const system makes only
 one of the following two methods compile.  It forces programmers
 to settle for using global variables to bypass const
 restrictions.  It also touches upon why the purity is required
 when doing multithreading.  I can't fully embrace const until it
 stops encouraging global variables and the gap between purity and
 const is reduced/eliminated.

 =============

 log.write("Hello World"); } } ============= class Foo{ logFile
 log; void bar() invariant{ log.write("Hello World"); } }
 =============


That depends on which version of bar you're talking about. The first bar conforms to the current D standard for invariance. Everything in class foo remains untouched in the first example, and so bar is invariant.

True, but it is not pure. Pure functions cannot change global state.

The current definition of pure goes even farther than that. Because arguments to pure functions must be invariant (as far as I know), pure functions may not accept parameters that could be changed by another thread.
 These concepts are not simple, but there is no way to support shared 
 state in multithreaded programming without understanding those concepts. 
 C++ the language has no concept of these things, and people get into 
 endless trouble with it when misunderstanding things and screwing it up. 
 The C++ language itself is of NO help at all. With D, the idea is to 
 enable the language to help by moving things from convention to law. 
 Completely ignoring the issues, like C++ does, is no solution.

So will D have some way to require that references passed between threads must be either invariant or represent a transferral of ownership? I think that's the crux of the issue. Using invariance for non-shared data is typically more for simplifying error recovery than anything else. Sean
Jul 22 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Walter Bright wrote:
 True, but it is not pure. Pure functions cannot change global state.

The current definition of pure goes even farther than that. Because arguments to pure functions must be invariant (as far as I know), pure functions may not accept parameters that could be changed by another thread.

That's right. One way to think about it (*) is that for pure functions, if you take a bit copy of its arguments on the stack, save them, and some arbitrary time in the future call the function again with those same bits, you must get back exactly the same result.
 So will D have some way to require that references passed between 
 threads must be either invariant or represent a transferral of 
 ownership?  I think that's the crux of the issue.  Using invariance for 
 non-shared data is typically more for simplifying error recovery than 
 anything else.

Consider (*). Pure functions do not "own" data, as they cannot have state.
Jul 22 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Walter Bright wrote:
 True, but it is not pure. Pure functions cannot change global state.

The current definition of pure goes even farther than that. Because arguments to pure functions must be invariant (as far as I know), pure functions may not accept parameters that could be changed by another thread.

That's right. One way to think about it (*) is that for pure functions, if you take a bit copy of its arguments on the stack, save them, and some arbitrary time in the future call the function again with those same bits, you must get back exactly the same result.
 So will D have some way to require that references passed between 
 threads must be either invariant or represent a transferral of 
 ownership?  I think that's the crux of the issue.  Using invariance 
 for non-shared data is typically more for simplifying error recovery 
 than anything else.

Consider (*). Pure functions do not "own" data, as they cannot have state.

I personally feel that requiring that parameters be const is sufficient for memoizing results. Requiring invariance assumes a programming model that I simply don't endorse. But I'll grant that it's certainly the safer approach. Sean
Jul 22 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 I personally feel that requiring that parameters be const is sufficient 
 for memoizing results.  Requiring invariance assumes a programming model 
 that I simply don't endorse.  But I'll grant that it's certainly the 
 safer approach.

What such a an approach would rely on would be the *convention* that nobody would change the referenced const data from one invocation of the function to the next. This contradicts the whole premise, and is no better than C++.
Jul 22 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 I personally feel that requiring that parameters be const is 
 sufficient for memoizing results.  Requiring invariance assumes a 
 programming model that I simply don't endorse.  But I'll grant that 
 it's certainly the safer approach.

What such a an approach would rely on would be the *convention* that nobody would change the referenced const data from one invocation of the function to the next. This contradicts the whole premise, and is no better than C++.

Oops, you're right. I was thinking simply of the data changing while the function was executing. I suppose requiring invariance of parameters does make sense. Sean
Jul 22 2008
next sibling parent superdan <super dan.org> writes:
Sean Kelly Wrote:

 Walter Bright wrote:
 Sean Kelly wrote:
 I personally feel that requiring that parameters be const is 
 sufficient for memoizing results.  Requiring invariance assumes a 
 programming model that I simply don't endorse.  But I'll grant that 
 it's certainly the safer approach.

What such a an approach would rely on would be the *convention* that nobody would change the referenced const data from one invocation of the function to the next. This contradicts the whole premise, and is no better than C++.

Oops, you're right. I was thinking simply of the data changing while the function was executing. I suppose requiring invariance of parameters does make sense. Sean

that's one interesting about d's const system. looks like there's extra shit that you wouldn't need, but as soon as you take any out you're fucked. i'm not sure it's enough yet, from what i can tell invariant object construction is a grandmotherfuck. but sure there's no fat in the system right now. reminds me of the kon tiki expedition i saw when i was a kid. this guy thor heyerdahl reproduced an ancient expedition in a boat made of bamboo or something. he made it like in antiquity, but there was an extra rope at the front that he found unnecessary. so he was like, fuck that rope, don't put it in. sure as shit, in a few weeks' time the bamboo boat was bending and sinking exactly where the rope would have held it properly in place. for some reason that particular story stayed with me ever since. const is the rope that keeps invariant shit and mutable shit together. without const there'd be like two worlds separated by a ridge. that system would be fucked. without invariant the system would be like an eunuch: sees a lot of good stuff goin' on but can't do shit about it because it's powerless. (that's c++ by the way.) with const there's two worlds that can communicate.
Jul 22 2008
prev sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-07-23 02:40:55 +0200, Sean Kelly <sean invisibleduck.org> said:

 Walter Bright wrote:
 Sean Kelly wrote:
 I personally feel that requiring that parameters be const is sufficient 
 for memoizing results.  Requiring invariance assumes a programming 
 model that I simply don't endorse.  But I'll grant that it's certainly 
 the safer approach.

What such a an approach would rely on would be the *convention* that nobody would change the referenced const data from one invocation of the function to the next. This contradicts the whole premise, and is no better than C++.

Oops, you're right. I was thinking simply of the data changing while the function was executing. I suppose requiring invariance of parameters does make sense. Sean

I think that the const/invariant separation makes much sense, and the whole framework is sound: const: this constant *now* and should not be changed by you (but might be changed by others) invariant: this won't be changed by anybody (always constant), you can cache it, do whatever you want to it, expect it to remain the same also in the future From another post of Walter:
 4. Invariant data can be placed in hardware protected readonly memory, 
 such as ROM.

I thin the invariant should not necessarily allow that. Let's call invariantW the invariant that can be placed in readonly memory. I introduce a weaker form of invariant that I call invariantF. For invariant F the bits that a function can see are constant (as with invariantW), but the bits might not be actually there in the hardware from the beginning. This allows lazy evaluation, and single value dataflow variables. Lazy evaluation means that part of the structure is calculated "on demand" by a pure function, at the logical level the result of it is known from the beginning and constant, but the bits are not there yet, in case of race conditions the bits can be calculated twice, but the result would still be the same, so it is just an efficiency problem that does not change any result. In dataflow variables the result is calculated by someone else, and if you request it you wait until it is there. Also in this case the value should be unique, actually one might allow the result to be set more than once, but only if it is set to always the same value (or a compatible partial value). These two things add lot of power to functional programming, leaving all the nice properties of it intact. A function should not be able to know if the bits are already there, for it they are always already there, but from the efficiency point of view it can make a huge difference, the difference between streaming a file and loading it at once for example. Clearly invariantF is weaker than invariantW, and you loose some optimization possibilities, like putting everything in ROM, but the functional core gains a lot of power. I think that the two concepts are really close enough so that only one should be adopted (I don't want an almost_invariant keyword), and I think that D should really adopt invariantF concept because that way the functional core gets a lot more useful, I want to use pure lazy datastructures with a compiler that optimizes them. Fawzi
Jul 23 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Fawzi Mohamed wrote:
 On 2008-07-23 02:40:55 +0200, Sean Kelly <sean invisibleduck.org> said:
 
 Walter Bright wrote:
 Sean Kelly wrote:
 I personally feel that requiring that parameters be const is 
 sufficient for memoizing results.  Requiring invariance assumes a 
 programming model that I simply don't endorse.  But I'll grant that 
 it's certainly the safer approach.

What such a an approach would rely on would be the *convention* that nobody would change the referenced const data from one invocation of the function to the next. This contradicts the whole premise, and is no better than C++.

Oops, you're right. I was thinking simply of the data changing while the function was executing. I suppose requiring invariance of parameters does make sense.

I think that the const/invariant separation makes much sense, and the whole framework is sound: const: this constant *now* and should not be changed by you (but might be changed by others) invariant: this won't be changed by anybody (always constant), you can cache it, do whatever you want to it, expect it to remain the same also in the future

I think the theory is completely sound, I'm just not convinced it's worth the cost in terms of its impact on D programs.
  From another post of Walter:
 4. Invariant data can be placed in hardware protected readonly memory, 
 such as ROM.

I thin the invariant should not necessarily allow that.

I think the salient point is that invariant data /can/ be placed in ROM, not that it has to. In fact, only some invariant data can be placed in ROM--that data which is known at compile-time. const data in D 1.0 works this way. Sean
Jul 23 2008
parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-07-23 18:14:53 +0200, Sean Kelly <sean invisibleduck.org> said:

 Fawzi Mohamed wrote:
  From another post of Walter:
 4. Invariant data can be placed in hardware protected readonly memory, 
 such as ROM.

I thin the invariant should not necessarily allow that.

I think the salient point is that invariant data /can/ be placed in ROM, not that it has to. In fact, only some invariant data can be placed in ROM--that data which is known at compile-time. const data in D 1.0 works this way.

It depends on what the purpose of invariant is. If the purpose of invariant is to enable good support for functional style, and avoid concurrency problems then I think that an invariant that guarantees that 4 is never automatically enforced would be better (that or the infamous mutable/unpaintable keyword, or (but more difficult to do well at the first attempt, instead of letting this be a library implementable feature) language given thunks). The thing is that as there are lazy functions (and those are present in D) there are also lazy datastructures. Lazy datastructures can have pieces that are not yet computed, so they cannot be invariantW. A simple example is a linked list (it could be also a tree, or other structures), if it is lazy it can be produced "as needed" and if the root is not needed consumes little memory. These are powerful features of functional languages that would not be part of D functional core. Fawzi
Jul 23 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Jason House wrote:
 Walter Bright Wrote:
 
 Jason House wrote:
 By far, my biggest complaint is that the const system makes only
 one of the following two methods compile.  It forces programmers
 to settle for using global variables to bypass const
 restrictions.  It also touches upon why the purity is required
 when doing multithreading.  I can't fully embrace const until it
 stops encouraging global variables and the gap between purity and
 const is reduced/eliminated.
 
 =============

 log.write("Hello World"); } } ============= class Foo{ logFile
 log; void bar() invariant{ log.write("Hello World"); } }
 =============


That depends on which version of bar you're talking about. The first bar conforms to the current D standard for invariance. Everything in class foo remains untouched in the first example, and so bar is invariant.

True, but it is not pure. Pure functions cannot change global state.
 nor can it be pure if it writes things to global state. I am not
 sure why bar() needs to be pure, but it *cannot* be pure if it
 changes either global state or the state of one of its arguments.

That's exactly right. So what purpose is declaring bar as invariant serving?

I don't know why it needed to be marked as invariant (I didn't write it <g>).
 It's not supporting functional-style multithreading, but
 wasn't that the point for the const system?

It is one of the points of the const system. But the idea is not to just declare things invariant and magically they will work in functional style. The idea is that if you want to make something functional, the language will provide support for it if only in the form of telling you when something will not work in functional style. That appears to be the case with bar() - it cannot work in functional style.

Can you answer this more thoroughly? It's really important to this dialog. What *other* purposes does the const system serve besides opening the door to functional programming? I understand that the const system must remain simple to be usable.
 Since transitive const
 is already viral, it makes little sense to me that it shouldn't
 extend to static/global state.  That removes the temptation of
 programmers to use static/global state to circumvent the const
 system.  If that's problematic, then IMHO, something must be
 re-thought because it means people's use of D's const system will not
 support the functional-style multithreading because people are using
 it the wrong way.

The missing ingredient here is what the 'pure' modifier for functions provides. That is the ability to diagnose attempts to alter global state from within a function that is not supposed to do that. Invariant does not imply pure.

That's actually a very key part to my whole point. There is very little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference. I look at this from the following basic principles: 1. As functional programming / implicit multithreading requires pure functions 2. Pure functions require invariant state (object and global state) 3. Imperative programming requires mutable data 4. const (as defined in D) is required to bridge the gap between mutable state and invariant state In C++, we have const data requiring const functions, and in D we have const (invariant) data requiring const (invariant) functions. The different being that const (invariant) in D is transitive, yielding something that's closer to truly constant state. Unfortunately, what D provides isn't enough. Pure functions requires that any shared data is invariant. That means both transitive invariance like D currently has plus invariant global state. The net effect is that D currently contains two concepts - invariant functions and pure functions. Based on principles 1&2, I can't justify the extra complexity. What I keep wondering is why don't invariant functions operate like pure functions? Changing transitive const to include any global state accessed through a function seems quite natural to me. Additionally, const functions as currently written in D are not always const. The classic C++ example is a tree data structure where a programmer does this.parent.child.property = 1; An analgous D example would be global_root.child.property = 1; If the change I hope to see comes about, this loophole will be closed.
 These concepts are not simple, but there is no way to support shared 
 state in multithreaded programming without understanding those concepts. 
 C++ the language has no concept of these things, and people get into 
 endless trouble with it when misunderstanding things and screwing it up. 
 The C++ language itself is of NO help at all. With D, the idea is to 
 enable the language to help by moving things from convention to law. 
 Completely ignoring the issues, like C++ does, is no solution.

I believe that I understand, and hope my more verbose post above will help convince you of that. I believe (nievely?) that I have value to add if only I can convince you. I truly do think what I've outlined is a problem with the D const system.
Jul 22 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 Walter Bright Wrote:
 It is one of the points of the const system. But the idea is not to
 just declare things invariant and magically they will work in
 functional style. The idea is that if you want to make something
 functional, the language will provide support for it if only in the
 form of telling you when something will not work in functional
 style. That appears to be the case with bar() - it cannot work in
 functional style.

Can you answer this more thoroughly? It's really important to this dialog. What *other* purposes does the const system serve besides opening the door to functional programming? I understand that the const system must remain simple to be usable.

1. It makes function APIs self-documenting. 2. Invariance allows one to pass large data structures around by reference yet treat them as if one passed them by value. Strings are the canonical example of that. 3. Const allows one function to service both mutable and invariant arguments. 4. Invariant data can be placed in hardware protected readonly memory, such as ROM. 5. Invariant data does not have to be synchronized to be multithread accessible. 6. Invariant data improves the ability of automated tools to make inferences about what is happening. Optimization is an example of such.
 The missing ingredient here is what the 'pure' modifier for
 functions provides. That is the ability to diagnose attempts to
 alter global state from within a function that is not supposed to
 do that. Invariant does not imply pure.

That's actually a very key part to my whole point. There is very little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference.

See points 1..5.
 Pure functions requires that any shared data is invariant.

Yes, but invariant data does not require purity.
 The net effect is that D currently contains two
 concepts - invariant functions and pure functions.

Yes.
 Based on principles 1&2, I can't justify the extra complexity.

I can with points 1..5.
 I believe that I understand, and hope my more verbose post above will
 help convince you of that.  I believe (nievely?) that I have value to
 add if only I can convince you.  I truly do think what I've outlined
 is a problem with the D const system.

I hope this post will convince you otherwise. If not, I can try again <g>.
Jul 22 2008
next sibling parent superdan <super dan.org> writes:
Walter Bright Wrote:

 Jason House wrote:
 Walter Bright Wrote:
 It is one of the points of the const system. But the idea is not to
 just declare things invariant and magically they will work in
 functional style. The idea is that if you want to make something
 functional, the language will provide support for it if only in the
 form of telling you when something will not work in functional
 style. That appears to be the case with bar() - it cannot work in
 functional style.

Can you answer this more thoroughly? It's really important to this dialog. What *other* purposes does the const system serve besides opening the door to functional programming? I understand that the const system must remain simple to be usable.

1. It makes function APIs self-documenting. 2. Invariance allows one to pass large data structures around by reference yet treat them as if one passed them by value. Strings are the canonical example of that. 3. Const allows one function to service both mutable and invariant arguments. 4. Invariant data can be placed in hardware protected readonly memory, such as ROM. 5. Invariant data does not have to be synchronized to be multithread accessible. 6. Invariant data improves the ability of automated tools to make inferences about what is happening. Optimization is an example of such.

yeah. tell brad or andrei or whoever came up with that stuff that i'll buy them a beer for point 2, i'll wash their feet for 3, and i'll buy them dinner at ritz for 5. fuckin' a.
Jul 22 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Jason House wrote:
 What *other* purposes does the const system serve besides
 opening the door to functional programming?  I understand that the
 const system must remain simple to be usable.

1. It makes function APIs self-documenting. 2. Invariance allows one to pass large data structures around by reference yet treat them as if one passed them by value. Strings are the canonical example of that. 3. Const allows one function to service both mutable and invariant arguments. 4. Invariant data can be placed in hardware protected readonly memory, such as ROM. 5. Invariant data does not have to be synchronized to be multithread accessible. 6. Invariant data improves the ability of automated tools to make inferences about what is happening. Optimization is an example of such.

#5 is not true. Invariant functions require synchronization because they can manipulate global state. If #5 is restricted to direct data access without using properties or member functions, then I'd agree with it. Of course, that qualification eliminates most of the benefit from #5. #2 makes me think a bit... When would const objects be used to manipulate non-const data that isn't effected by transitive const? It seems to me that simple cases could work, but it quickly breaks down when trying to generalize. For example, I could write a log utility that writes messages to standard out. To write to any output, I'd need to store where to write log output to. Maybe I could circumvent the const system and create a global object that looks up where to write stuff. That'd let me pass around my logger as an invariant object but then it'd be making an extra function call every time something gets logged. That's a horrible design. Advanced compiler tricks may eliminate the overhead, but it doesn't mean it'd save headache for the programmer.
 Pure functions requires that any shared data is invariant.

Yes, but invariant data does not require purity.

I translate that as "I didn't implement it that way". Also, we need to distinguish between raw access to invariant data and use of (invariant) methods. See my discussion of your #5 above
 I hope this post will convince you otherwise. If not, I can try again <g>.

And I can try again too :)
Jul 23 2008
next sibling parent reply superdan <super dan.org> writes:
Jason House Wrote:

 Walter Bright Wrote:
 
 Jason House wrote:
 What *other* purposes does the const system serve besides
 opening the door to functional programming?  I understand that the
 const system must remain simple to be usable.

1. It makes function APIs self-documenting. 2. Invariance allows one to pass large data structures around by reference yet treat them as if one passed them by value. Strings are the canonical example of that. 3. Const allows one function to service both mutable and invariant arguments. 4. Invariant data can be placed in hardware protected readonly memory, such as ROM. 5. Invariant data does not have to be synchronized to be multithread accessible. 6. Invariant data improves the ability of automated tools to make inferences about what is happening. Optimization is an example of such.

#5 is not true. Invariant functions require synchronization because they can manipulate global state. If #5 is restricted to direct data access without using properties or member functions, then I'd agree with it. Of course, that qualification eliminates most of the benefit from #5. notice how walter says "data" and you say "function" and you'll pretty much have understood where the problem in your reasoning was.

of course #5 is true. looks like there was and still is a basic misunderstanding of data vs. function behavior with regard to immutability. don't confuse data with functions. invariant data -> can't modify it even with the sas. that means no synchronization on data necessary. invariant function -> applies to invariant object and may or may not require synchronization. but sure as shit invariant data does not need synchronization.
 #2 makes me think a bit...  When would const objects be used to manipulate
non-const data that isn't effected by transitive const?  It seems to me that
simple cases could work, but it quickly breaks down when trying to generalize.
 For example, I could write a log utility that writes messages to standard out.
 To write to any output, I'd need to store where to write log output to.  Maybe
I could circumvent the const system and create a global object that looks up
where to write stuff.  That'd let me pass around my logger as an invariant
object but then it'd be making an extra function call every time something gets
logged.  That's a horrible design.  Advanced compiler tricks may eliminate the
overhead, but it doesn't mean it'd save headache for the programmer.  

this is backwards. the logger object is not const. the shit it logs is const as the logger has no business changing it.
 Pure functions requires that any shared data is invariant.

Yes, but invariant data does not require purity.

I translate that as "I didn't implement it that way". Also, we need to distinguish between raw access to invariant data and use of (invariant) methods. See my discussion of your #5 above

which was wrong, and your translation doesn't make it any better.
Jul 23 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
superdan Wrote:

 Jason House Wrote:
 
 Walter Bright Wrote:
 5. Invariant data does not have to be synchronized to be multithread 
 accessible.

#5 is not true. Invariant functions require synchronization because they can manipulate global state. If #5 is restricted to direct data access without using properties or member functions, then I'd agree with it. Of course, that qualification eliminates most of the benefit from #5. notice how walter says "data" and you say "function" and you'll pretty much have understood where the problem in your reasoning was.

of course #5 is true. looks like there was and still is a basic misunderstanding of data vs. function behavior with regard to immutability. don't confuse data with functions. invariant data -> can't modify it even with the sas. that means no synchronization on data necessary. invariant function -> applies to invariant object and may or may not require synchronization. but sure as shit invariant data does not need synchronization.

All of my posts on this topic are about invariant functions rather than invariant data. Walter's response focused more on invariant data, and I'm intentionally trying to draw the distinction in what we're talking about. I want to shift the discussion away from discussing purely invariant data and instead discuss the functions to access the data. Proper object oriented programming requires using functions, so any proper analysis of a const system must include analyzing how functions are handled.
Jul 23 2008
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-07-23 17:30:48 +0200, Jason House <jason.james.house gmail.com> said:

 superdan Wrote:
 
 Jason House Wrote:
 
 Walter Bright Wrote:
 5. Invariant data does not have to be synchronized to be multithread
 accessible.

#5 is not true. Invariant functions require synchronization because they can manipulate global state. If #5 is restricted to direct data access without using properties or member functions, then I'd agree with it. Of course, that qualification eliminates most of the benefit from #5. notice how walter says "data" and you say "function" and you'll pretty much have understood where the problem in your reasoning was.

of course #5 is true. looks like there was and still is a basic misunderstanding of data vs. function behavior with regard to immutability. don't confuse data with functions. invariant data -> can't modify it even with the sas. that means no synchronization on data necessary. invariant function -> applies to invariant object and may or may not require synchronization. but sure as shit invariant data does not need synchronization.

All of my posts on this topic are about invariant functions rather than invariant data. Walter's response focused more on invariant data, and I'm intentionally trying to draw the distinction in what we're talking about. I want to shift the discussion away from discussing purely invariant data and instead discuss the functions to access the data. Proper object oriented programming requires using functions, so any proper analysis of a const system must include analyzing how functions are handled.

the functions connected to invariant data are pure functions, invariant functions are just functions with an invariant argument (this), see Steven's reply to you in the other thread.
Jul 23 2008
parent reply Don <nospam nospam.com.au> writes:
Fawzi Mohamed wrote:
 On 2008-07-23 17:30:48 +0200, Jason House <jason.james.house gmail.com> 
 said:
 
 superdan Wrote:

 Jason House Wrote:

 Walter Bright Wrote:
 5. Invariant data does not have to be synchronized to be multithread
 accessible.

#5 is not true. Invariant functions require synchronization because they can manipulate global state. If #5 is restricted to direct data access without using properties or member functions, then I'd agree with it. Of course, that qualification eliminates most of the benefit from #5. notice how walter says "data" and you say "function" and you'll pretty much have understood where the problem in your reasoning was.

of course #5 is true. looks like there was and still is a basic misunderstanding of data vs. function behavior with regard to immutability. don't confuse data with functions. invariant data -> can't modify it even with the sas. that means no synchronization on data necessary. invariant function -> applies to invariant object and may or may not require synchronization. but sure as shit invariant data does not need synchronization.

All of my posts on this topic are about invariant functions rather than invariant data. Walter's response focused more on invariant data, and I'm intentionally trying to draw the distinction in what we're talking about. I want to shift the discussion away from discussing purely invariant data and instead discuss the functions to access the data. Proper object oriented programming requires using functions, so any proper analysis of a const system must include analyzing how functions are handled.

the functions connected to invariant data are pure functions, invariant functions are just functions with an invariant argument (this), see Steven's reply to you in the other thread.

But when does that happen? Seems to me that it can only happen if the class it is part of contains only invariant data. Which seems really obscure. Any _member_ which is invariant is presumably declared invariant anyway. Can anyone come up with a use case?
Jul 23 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Don wrote:
 Fawzi Mohamed wrote:
 On 2008-07-23 17:30:48 +0200, Jason House 
 <jason.james.house gmail.com> said:

 superdan Wrote:

 Jason House Wrote:

 Walter Bright Wrote:
 5. Invariant data does not have to be synchronized to be multithread
 accessible.

#5 is not true. Invariant functions require synchronization because they can manipulate global state. If #5 is restricted to direct data access without using properties or member functions, then I'd agree with it. Of course, that qualification eliminates most of the benefit from #5. notice how walter says "data" and you say "function" and you'll pretty much have understood where the problem in your reasoning was.

of course #5 is true. looks like there was and still is a basic misunderstanding of data vs. function behavior with regard to immutability. don't confuse data with functions. invariant data -> can't modify it even with the sas. that means no synchronization on data necessary. invariant function -> applies to invariant object and may or may not require synchronization. but sure as shit invariant data does not need synchronization.

All of my posts on this topic are about invariant functions rather than invariant data. Walter's response focused more on invariant data, and I'm intentionally trying to draw the distinction in what we're talking about. I want to shift the discussion away from discussing purely invariant data and instead discuss the functions to access the data. Proper object oriented programming requires using functions, so any proper analysis of a const system must include analyzing how functions are handled.

the functions connected to invariant data are pure functions, invariant functions are just functions with an invariant argument (this), see Steven's reply to you in the other thread.

But when does that happen? Seems to me that it can only happen if the class it is part of contains only invariant data. Which seems really obscure. Any _member_ which is invariant is presumably declared invariant anyway. Can anyone come up with a use case?

I think the only point of an 'invariant' or even a 'const' label for member functions is just that--a way to indicate to the compiler that the hidden context pointer is invariant or const. Sean
Jul 23 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 I think the only point of an 'invariant' or even a 'const' label for 
 member functions is just that--a way to indicate to the compiler that 
 the hidden context pointer is invariant or const.

Yes. That is all it is. It says nothing about the purity of the function.
Jul 23 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
superdan wrote:
 Jason House Wrote:
 
 Walter Bright Wrote:

 Jason House wrote:
 What *other* purposes does the const system serve besides
 opening the door to functional programming?  I understand that the
 const system must remain simple to be usable.

2. Invariance allows one to pass large data structures around by reference yet treat them as if one passed them by value. Strings are the canonical example of that. 3. Const allows one function to service both mutable and invariant arguments. 4. Invariant data can be placed in hardware protected readonly memory, such as ROM. 5. Invariant data does not have to be synchronized to be multithread accessible. 6. Invariant data improves the ability of automated tools to make inferences about what is happening. Optimization is an example of such.


of course #5 is true. looks like there was and still is a basic misunderstanding of data vs. function behavior with regard to immutability. don't confuse data with functions. invariant data -> can't modify it even with the sas. that means no synchronization on data necessary. invariant function -> applies to invariant object and may or may not require synchronization. but sure as shit invariant data does not need synchronization.

To be fair, invariant data created at runtime does need synchronization before passing it to another thread. But once the thread has it then no more synchronization is necessary to access it. This is one aspect of invariant that I think has been largely overlooked thus far, perhaps partially because most people still have single core machines and/or are using x86 machines, which have a pretty strict memory model. Sean
Jul 23 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 Walter Bright Wrote:
 
 Jason House wrote:
 What *other* purposes does the const system serve besides opening
 the door to functional programming?  I understand that the const
 system must remain simple to be usable.

one to pass large data structures around by reference yet treat them as if one passed them by value. Strings are the canonical example of that. 3. Const allows one function to service both mutable and invariant arguments. 4. Invariant data can be placed in hardware protected readonly memory, such as ROM. 5. Invariant data does not have to be synchronized to be multithread accessible. 6. Invariant data improves the ability of automated tools to make inferences about what is happening. Optimization is an example of such.

#5 is not true. Invariant functions require synchronization because they can manipulate global state.

Not so. The only invariant functions in D are member functions which cannot change the state referenced by 'this'. They can certainly change other state. Pure functions, on the other hand, may not manipulate global state.
 If #5 is restricted to direct data
 access without using properties or member functions, then I'd agree
 with it.  Of course, that qualification eliminates most of the
 benefit from #5.

I think you are confusing invariance with purity. They are distinct concepts with distinct rules and uses.
 #2 makes me think a bit...  When would const objects be used to
 manipulate non-const data that isn't effected by transitive const?

I don't understand your question. #2 is about invariance, not const.
 It seems to me that simple cases could work, but it quickly breaks
 down when trying to generalize. For example, I could write a log
 utility that writes messages to standard out.  To write to any
 output, I'd need to store where to write log output to.  Maybe I
 could circumvent the const system and create a global object that
 looks up where to write stuff.  That'd let me pass around my logger
 as an invariant object but then it'd be making an extra function call
 every time something gets logged.  That's a horrible design.
 Advanced compiler tricks may eliminate the overhead, but it doesn't
 mean it'd save headache for the programmer.

It still sounds like you're mixing up purity with invariance.
 Pure functions requires that any shared data is invariant.



It shouldn't be translated that way, because invariance and purity are fairly common comp sci constructs, and I believe that D uses them in conformance with that (although the term 'invariance' isn't used).
 Also, we need
 to distinguish between raw access to invariant data and use of
 (invariant) methods.  See my discussion of your #5 above

No, once again, I think you are confusing invariance with purity. An invariant function means that it cannot modify anything through its 'this'. It can modify anything else.
 I hope this post will convince you otherwise. If not, I can try
 again <g>.


First we need to agree on what purity and invariance are.
Jul 23 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright wrote:

 Jason House wrote:
 Walter Bright Wrote:
 5. Invariant data 
 does not have to be synchronized to be multithread accessible. 6.
 Invariant data improves the ability of automated tools to make
 inferences about what is happening. Optimization is an example of
 such.

#5 is not true. Invariant functions require synchronization because they can manipulate global state.

Not so. The only invariant functions in D are member functions which cannot change the state referenced by 'this'. They can certainly change other state. Pure functions, on the other hand, may not manipulate global state.

Maybe an example will help: int a; int b; struct bar{ void write(int x) invariant out{ assert(a==b); } body{ a = x; b = x; } } The state of bar is never modified, but bar should not be used without synchronization. The function's contract can be violated due to a race condition. This may be an artificial example, but I hope it shows that #5 requires qualification.
Jul 23 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Simen Kjaeraas Wrote:
 You are expecting invariant member functions to not do things they can
 and should do.

My example was in response to Walter's statement (#5) that invariant objects can be accessed without synchronization. I was providing a simple counter example.
Jul 24 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jason House" wrote
 Simen Kjaeraas Wrote:
 You are expecting invariant member functions to not do things they can
 and should do.

My example was in response to Walter's statement (#5) that invariant objects can be accessed without synchronization. I was providing a simple counter example.

Your counter-example fails to show that. You can access invariant objects without synchronization, you cannot necessarily call invariant functions without synchronization. In your example, you are accessing a and b, which are not invariant, which means you will have to synchronize on something. If there was data you were accessing in the struct itself, then you would not need to synchronize to access that data. If you are accessing both struct data and global data, you only need to synchronize on the global data access. And you will need to synchronize on something outside the struct, as other classes might be able to access global data. Let me show you exactly how the compiler views your code: int a; int b; struct bar{ } void bar.write(invariant bar *this, int x) out{ assert(a==b); } body{ a = x; b = x; } -Steve
Jul 24 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 Simen Kjaeraas Wrote:
 You are expecting invariant member functions to not do things they
 can and should do.

My example was in response to Walter's statement (#5) that invariant objects can be accessed without synchronization. I was providing a simple counter example.

The counter example was changing global state, not the invariant object. The statement #5 is correct - the counter example did not change the invariant object's state.
Jul 24 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Jason House wrote:
 Simen Kjaeraas Wrote:
 You are expecting invariant member functions to not do things they
 can and should do.

My example was in response to Walter's statement (#5) that invariant objects can be accessed without synchronization. I was providing a simple counter example.

The counter example was changing global state, not the invariant object. The statement #5 is correct - the counter example did not change the invariant object's state.

Letís dissect the original statement #5 and all of itís possible meanings: 5. Invariant data does not have to be synchronized to be multithread accessible. Invariant data: This would be various forms of invariant(T) with different Tís. Itís possible that T is just fundamental types such as int and float, but I think thatís unlikely. Given other goals such as using reference types as value types, this has to include classes and structs. Iíd also assume from this that common uses of the various types would have to be included. This would mean classic OOP styles such as data encapsulation. Does not have to be synchronized: I interpret this as ďnever requires synchronizationĒ while others have interpreted it as ďmight not need synchronizationĒ. I canít believe the latter because of how much Walter has said in the past about the inherent dangers of multi-threading and an inability to trust programmers to conform to best practices. Multithread accessible: If this doesn't mean "safely accessible by multiple simultaneous threads without incorrect or undesired outcomes", then there's no point is claiming anything about multi-threading. What is meant by "accessible"? For strings, this clearly means reading the characters within the string, but when expanded to all types of invariant data, the meaning is less clear to me. As discussed above, invariant data needs to cover the case of data encapsulation. Proper encapsulation means that _no_ data members are exposed for direct access and that all access must be through member functions. If object are to be multithread accessible, then the access functions must be included. All of the above drives me to believe that the original statement #5 implicitly includes the statement that ďAll compilable calls to member functions of invariant objects can be done without synchronizationĒ. Itís become pretty clear that most people disagree with that conclusion. In my original reply to Walter, I said ďIf #5 is restricted to direct data access without using properties or member functions, then I'd agree with it.Ē I didnít think that was such an outlandish statement or possible requirement that Walter left out. I said it before, and Iíll say it again: ďOf course, that qualification eliminates most of the benefit from #5.Ē Itís amazing how such basic stuff can completely spiral out of control with people claiming that I donít know what Iím talking about and assuming all kinds of inaccurate stuff. Itís not like I wasnít aware that extending Walterís statement to include ďinvariant (member) functionsĒ was possibly contentious. Simply agreeing that statement #5 should be qualified as direct member access would be sufficient to end the problems with this bit of the conversation and move on to more productive conversation. I donít have the time to write long and verbose posts like this one to explain the tiniest bits of stuff that Iím talking about. Beyond being annoying, huge posts about the littlest details will prevent anyone from reading the post or simply losing sight of the forest through the trees. Iím done talking about this topic!
Jul 25 2008
parent reply superdan <super dan.org> writes:
Jason House Wrote:

 Walter Bright Wrote:
 
 Jason House wrote:
 Simen Kjaeraas Wrote:
 You are expecting invariant member functions to not do things they
 can and should do.

My example was in response to Walter's statement (#5) that invariant objects can be accessed without synchronization. I was providing a simple counter example.

The counter example was changing global state, not the invariant object. The statement #5 is correct - the counter example did not change the invariant object's state.

Letís dissect the original statement #5 and all of itís possible meanings: 5. Invariant data does not have to be synchronized to be multithread accessible. Invariant data: This would be various forms of invariant(T) with different Tís. Itís possible that T is just fundamental types such as int and float, but I think thatís unlikely. Given other goals such as using reference types as value types, this has to include classes and structs. Iíd also assume from this that common uses of the various types would have to be included. This would mean classic OOP styles such as data encapsulation. Does not have to be synchronized: I interpret this as ďnever requires synchronizationĒ while others have interpreted it as ďmight not need synchronizationĒ. I canít believe the latter because of how much Walter has said in the past about the inherent dangers of multi-threading and an inability to trust programmers to conform to best practices. Multithread accessible: If this doesn't mean "safely accessible by multiple simultaneous threads without incorrect or undesired outcomes", then there's no point is claiming anything about multi-threading. What is meant by "accessible"? For strings, this clearly means reading the characters within the string, but when expanded to all types of invariant data, the meaning is less clear to me. As discussed above, invariant data needs to cover the case of data encapsulation. Proper encapsulation means that _no_ data members are exposed for direct access and that all access must be through member functions. If object are to be multithread accessible, then the access functions must be included. All of the above drives me to believe that the original statement #5 implicitly includes the statement that ďAll compilable calls to member functions of invariant objects can be done without synchronizationĒ. Itís become pretty clear that most people disagree with that conclusion. In my original reply to Walter, I said ďIf #5 is restricted to direct data access without using properties or member functions, then I'd agree with it.Ē I didnít think that was such an outlandish statement or possible requirement that Walter left out. I said it before, and Iíll say it again: ďOf course, that qualification eliminates most of the benefit from #5.Ē Itís amazing how such basic stuff can completely spiral out of control with people claiming that I donít know what Iím talking about and assuming all kinds of inaccurate stuff. Itís not like I wasnít aware that extending Walterís statement to include ďinvariant (member) functionsĒ was possibly contentious. Simply agreeing that statement #5 should be qualified as direct member access would be sufficient to end the problems with this bit of the conversation and move on to more productive conversation. I donít have the time to write long and verbose posts like this one to explain the tiniest bits of stuff that Iím talking about. Beyond being annoying, huge posts about the littlest details will prevent anyone from reading the post or simply losing sight of the forest through the trees. Iím done talking about this topic!

dood. so glad you're done. here's a hint. instead of easing us all in excruciating detail into your multiple misunderstandings and term fudging, why not shut the piehole and open the ears a lil more.
Jul 25 2008
parent reply Jason House <jason.james.house gmail.com> writes:
superdan Wrote:
 
 dood. 
 
 so glad you're done. here's a hint. instead of easing us all in excruciating
detail into your multiple misunderstandings and term fudging, why not shut the
piehole and open the ears a lil more.

Personally, I find many of your posts insensitive and offensive. I'd like to believe that I've remained polite to people, even when I disagree with them. Maybe I failed at it, but I tried to read what people were saying and understand where they were coming from. I was probably taking things too personally because I found myself getting upset over the responses that people were making. If that came out in my last post, I apologize for that.
Jul 25 2008
parent superdan <super dan.org> writes:
Jason House Wrote:

 superdan Wrote:
  
 dood. 
 
 so glad you're done. here's a hint. instead of easing us all in excruciating
detail into your multiple misunderstandings and term fudging, why not shut the
piehole and open the ears a lil more.

Personally, I find many of your posts insensitive and offensive. I'd like to believe that I've remained polite to people, even when I disagree with them.

don't mind me. the sky is blue, yadda yadda yadda, and i'm a motherfucker. what else is new.
 Maybe I failed at it, but I tried to read what people were saying and
understand where they were coming from.  I was probably taking things too
personally because I found myself getting upset over the responses that people
were making.  If that came out in my last post, I apologize for that.

don't be all beta and sh... stuff. guess the discussion got to a violent agreement. what everybody i guess agrees on is that when data truly never changes you can always share it without care. just data. not objects with interfaces and shit. that read-only sharing is cool is as old news as my being an asshole. the cool thing is that d's invariant guarantees that statically.
Jul 25 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 #5 is not true.  Invariant functions require synchronization because
 they can manipulate global state.

cannot change the state referenced by 'this'. They can certainly change other state. Pure functions, on the other hand, may not manipulate global state.

Maybe an example will help: int a; int b; struct bar{ void write(int x) invariant out{ assert(a==b); } body{ a = x; b = x; } } The state of bar is never modified, but bar should not be used without synchronization. The function's contract can be violated due to a race condition. This may be an artificial example, but I hope it shows that #5 requires qualification.

You're imputing meaning to an "invariant function" that isn't there. An invariant function is a function that does not change the state of the object it is a member of. It can change other state.
Jul 24 2008
parent David Gileadi <foo bar.com> writes:
Walter Bright wrote:
 You're imputing meaning to an "invariant function" that isn't there. An 
 invariant function is a function that does not change the state of the 
 object it is a member of. It can change other state.

At the risk of exhuming and beating a dead horse, this was why I liked the proposal for using invariant(this) and const(this) for member function definitions. More verbose, but also IMHO quite a bit clearer.
Jul 24 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright wrote:
 First we need to agree on what purity and invariance are.

Probably invariant functions too since I find myself using that term a lot. Invariant data: Data/bits that will never change. This can include data stored in ROM and other readonly memory. Pure functions: Function calls without side effects such that they can be safely run in a multithreaded environment without synchronization. Many talk about input arguments to pure functions as being invarinat (thread local storage or unique references and scoped access could be used to lift that restriction, but I hope that's a different discussion) Invariant functions: 1. (Current D definition) functions using invariant keyword e.g. int bar(int x) invariant{} 2. (As I've been meaning it) Member functions of invariant data e.g. invariant T obj; obj.memberFunction();
Jul 23 2008
parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-07-24 03:33:41 +0200, Jason House <jason.james.house gmail.com> said:

 Walter Bright wrote:
 First we need to agree on what purity and invariance are.

Probably invariant functions too since I find myself using that term a lot.

yes but it has become clear that the way you use the term, and how everybody else does is different, so it might be good to change your definition, so that other understand you better.
 Invariant data: Data/bits that will never change.  This can include data
 stored in ROM and other readonly memory.

yes
 Pure functions: Function calls without side effects such that they can be
 safely run in a multithreaded environment without synchronization.  Many
 talk about input arguments to pure functions as being invarinat (thread
 local storage or unique references and scoped access could be used to lift
 that restriction, but I hope that's a different discussion)

different discussion
 Invariant functions:
  1. (Current D definition) functions using invariant keyword
     e.g. int bar(int x) invariant{}

you agree that it makes sense to have functions that have some arguments that are invariant? Which syntax would you use to describe member functions whose this argument is invariant?
  2. (As I've been meaning it) Member functions of invariant data
     e.g. invariant T obj;  obj.memberFunction();

member function of invariant data need to have the this argument that is either const or invariant. There are two kinds of them those that can have all sorts of side effects (but obviously not modify the object), and those that have no side effects (which we, as most other people call pure), the result of these functions shares all the nice properties of invariant data (i.e. you can basically treat a.x the same if x is a member variable or a pure method with no other arguments returning a value of the same type). Fawzi
Jul 23 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jason House" wrote
 Walter Bright Wrote:
 The missing ingredient here is what the 'pure' modifier for functions
 provides. That is the ability to diagnose attempts to alter global state
 from within a function that is not supposed to do that. Invariant does
 not imply pure.

That's actually a very key part to my whole point. There is very little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference.

You are misunderstanding what an 'invariant' member function is. The function itself is not invariant. It's a function whose 'this' pointer is marked as invariant. Remember that: class C { invariant void f() {} } Is somewhat equivalent to: class C { } void f(invariant C this) {} Note that f is not invariant, but 'this' is. However, for pure functions, pure describes the function, not the data. Invariant describes the data. In fact, a pure member function would have to be marked as: pure invariant void f(); Or else the compiler would complain that you were trying to call a pure function with non-invariant data. As for how useful would an invariant (but not pure) function be? Consider something like: class C { int x; invariant void printTo(stream s) { s.print(x); } } Without invariant member functions, you could not have a function like printTo for an invariant class instance. A pure function would not be able to print, because the stream argument would also have to be invariant, and most likely, stream.print would not be a pure function. Note that I'm too lazy right now to look up actual stream objects in Phobos or Tango and their syntax, so just imagine that what I wrote compiles :) -Steve
Jul 23 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Simen Kjaeraas" wrote
 Steven Schveighoffer wrote:

 In fact, a pure member function would have tobe marked as:
  pure invariant void f();

While I agree a pure member function would also need to be invariant, it seems superfluous to have to write that in the function signature. It /has/ to be, so why should I need to specify it?

I was showing that invariant and pure affect separate pieces of the function, and so I showed the syntax this way to make a point. Most likely, a pure member function implies that 'this' is invariant, as there is no reason to have it otherwise.
 As for how useful would an invariant (but not pure) function be? 
 Consider
 something like:

 class C
 {
    int x;
    invariant void printTo(stream s) { s.print(x); }
 }

Could this not just as easily have been done with a const function, as invariant is implicitly castable to const?

Yes, and as Koroskin says, there is a benefit to having invariant vs. const in that you do not need to synchronize. How important this will be in practice, I don't know. But for those crazies trying to squeeze every last ounce of performance from an app, it will be a possible optimization point :) I'll probably never use invariant in anything but pure functions (if I ever use those). However, the point is, in order to be consistent with other functions, which can have parameters declared as invariant, you must be able to declare the 'this' pointer as invariant. To not do this leaves a hole the same size as if you couldn't have tail-const class references. Oh wait... -Steve
Jul 23 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Steven Schveighoffer Wrote:

 "Jason House" wrote
 Walter Bright Wrote:
 The missing ingredient here is what the 'pure' modifier for functions
 provides. That is the ability to diagnose attempts to alter global state
 from within a function that is not supposed to do that. Invariant does
 not imply pure.

That's actually a very key part to my whole point. There is very little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference.

You are misunderstanding what an 'invariant' member function is. The function itself is not invariant. It's a function whose 'this' pointer is marked as invariant.

It's not that I misunderstand but that I question. Given the goals of the const system, invariant functions, as defined, don't make a lot of sense. They make some sense, but not a lot of sense :)
 Without invariant member functions, you could not have a function like 
 printTo for an invariant class instance.  A pure function would not be able 
 to print, because the stream argument would also have to be invariant, and 
 most likely, stream.print would not be a pure function.

It's true that what I'm talking about implies that such a thing could not occur. In C++ const (and the current D const), that type of construct is possible. It really comes down to if const exists for multithreading or if it exists for faking pass by value. I know Walter has tried to eliminate loopholes with the pass by value semantics with the transitive const. For example, transitive const protects tree manipulations such as parent.child.property = 1; from violating const, but it doesn't stop global_root.child.property = 1;. Such loopholes are not good when compilers are trying to optimize. I also can't really get past how the const system allows people to bypass "mutable members" through the use of global variables.
Jul 23 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jason House" wrote
 Steven Schveighoffer Wrote:

 "Jason House" wrote
 Walter Bright Wrote:
 The missing ingredient here is what the 'pure' modifier for functions
 provides. That is the ability to diagnose attempts to alter global 
 state
 from within a function that is not supposed to do that. Invariant does
 not imply pure.

That's actually a very key part to my whole point. There is very little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference.

You are misunderstanding what an 'invariant' member function is. The function itself is not invariant. It's a function whose 'this' pointer is marked as invariant.

It's not that I misunderstand but that I question. Given the goals of the const system, invariant functions, as defined, don't make a lot of sense. They make some sense, but not a lot of sense :)

They don't make any less sense than declaring invariant variables. Or declaring invariant parameters. Can you see use in the following function signature: void f(invariant(somestruct) *x) {...} If so, an invariant member function is no different. While I agree that having invariant functions is probably not going to be extremely useful, to not allow invariant methods is to make an inconsistency in the type system. If I can declare a variable is invariant, then I should be able to pass that variable to a function as invariant. If there is a special case that you can't pass it to it's own member function, then it is not only inconsistent, but probably makes the compiler more complex for no good reason. If you don't like invariant functions, don't use them. I probably won't. -Steve
Jul 23 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Steven Schveighoffer Wrote:

 "Jason House" wrote
 Steven Schveighoffer Wrote:

 "Jason House" wrote
 Walter Bright Wrote:
 The missing ingredient here is what the 'pure' modifier for functions
 provides. That is the ability to diagnose attempts to alter global 
 state
 from within a function that is not supposed to do that. Invariant does
 not imply pure.

That's actually a very key part to my whole point. There is very little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference.

You are misunderstanding what an 'invariant' member function is. The function itself is not invariant. It's a function whose 'this' pointer is marked as invariant.

It's not that I misunderstand but that I question. Given the goals of the const system, invariant functions, as defined, don't make a lot of sense. They make some sense, but not a lot of sense :)

They don't make any less sense than declaring invariant variables. Or declaring invariant parameters. Can you see use in the following function signature: void f(invariant(somestruct) *x) {...} If so, an invariant member function is no different.

Will the fields of somestruct be accessed directly? If so, there's no change in functionality. If not, will the invariant functions of somestruct be used to modify global state? If not, there's not change in functionality... I don't think what I'm suggesting changes a lot of code.
 I agree that having invariant functions is probably not going to be 
 extremely useful

Are we including invariant functions as an assumed feature that people need? Walter was recently considering eliminating one use of synchronized statements because there was no real use for it.
 to not allow invariant methods is to make an inconsistency 
 in the type system.  If I can declare a variable is invariant, then I should 
 be able to pass that variable to a function as invariant.

I'm missing something here... Why couldn't you pass an invariant object as an invariant parameter into a function?
 If there is a 
 special case that you can't pass it to it's own member function, then it is 
 not only inconsistent, but probably makes the compiler more complex for no 
 good reason.  

I've lost your line of reasoning, can you explain more?
 If you don't like invariant functions, don't use them.  I 
 probably won't.

That all depends on how the libraries you use are written. Hopefully they won't forget to add the pure keyword where it matters ;)
Jul 23 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jason House" wrote
 Steven Schveighoffer Wrote:

 "Jason House" wrote
 Steven Schveighoffer Wrote:

 "Jason House" wrote
 Walter Bright Wrote:
 The missing ingredient here is what the 'pure' modifier for 
 functions
 provides. That is the ability to diagnose attempts to alter global
 state
 from within a function that is not supposed to do that. Invariant 
 does
 not imply pure.

That's actually a very key part to my whole point. There is very little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference.

You are misunderstanding what an 'invariant' member function is. The function itself is not invariant. It's a function whose 'this' pointer is marked as invariant.

It's not that I misunderstand but that I question. Given the goals of the const system, invariant functions, as defined, don't make a lot of sense. They make some sense, but not a lot of sense :)

They don't make any less sense than declaring invariant variables. Or declaring invariant parameters. Can you see use in the following function signature: void f(invariant(somestruct) *x) {...} If so, an invariant member function is no different.

Will the fields of somestruct be accessed directly? If so, there's no change in functionality. If not, will the invariant functions of somestruct be used to modify global state? If not, there's not change in functionality... I don't think what I'm suggesting changes a lot of code.

You are suggesting that invariant functions simply be illegal, and pure functions not. I am saying that you are leaving a hole in the type system by doing that. It is analogous to saying, if a function has any invariant parameters, those functions should be marked pure, and all parameters should be marked invariant. I can see many places where some parameters could be invariant and some not. Pure functions (as Walter envisions them) require ALL invariant parameters.
 I agree that having invariant functions is probably not going to be
 extremely useful

Are we including invariant functions as an assumed feature that people need? Walter was recently considering eliminating one use of synchronized statements because there was no real use for it.

I'm saying if I can make any parameter invariant, I should be able to make the 'this' parameter invariant. Regardless of whether the function is pure or not. This is all an invariant function is. To not do this makes the type system inconsistent in that you can apply invariant to all types except the parameter named 'this' on a member function. Why separate that out, especially when it's already implemented?
 to not allow invariant methods is to make an inconsistency
 in the type system.  If I can declare a variable is invariant, then I 
 should
 be able to pass that variable to a function as invariant.

I'm missing something here... Why couldn't you pass an invariant object as an invariant parameter into a function?

This is what you are trying to prevent (passing of an invariant object as an invariant parameter). You are singling out the parameter named 'this' to prevent it on.
 If there is a
 special case that you can't pass it to it's own member function, then it 
 is
 not only inconsistent, but probably makes the compiler more complex for 
 no
 good reason.

I've lost your line of reasoning, can you explain more?

Maybe my above comments have done so, but here is a 'proof' of sorts. Let's say invariant functions are not allowed, but you can declare invariant parameters. I can declare the equivalent to an invariant function like so: class C { static f(invariant(C) c) {...} } ... auto c = cast(invariant(C)) new C; // instead of c.f() C.f(c); So with your removal of invariant functions, I can still have semantically equivalent invariant functions, but it's just more of a pain in the ass to use them. Why do you need to add this difficulty? -Steve
Jul 23 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Steven Schveighoffer Wrote:

 They don't make any less sense than declaring invariant variables.  Or
 declaring invariant parameters.

 Can you see use in the following function signature:

 void f(invariant(somestruct) *x) {...}

 If so, an invariant member function is no different.

Will the fields of somestruct be accessed directly? If so, there's no change in functionality. If not, will the invariant functions of somestruct be used to modify global state? If not, there's not change in functionality... I don't think what I'm suggesting changes a lot of code.

You are suggesting that invariant functions simply be illegal, and pure functions not. I am saying that you are leaving a hole in the type system by doing that. It is analogous to saying, if a function has any invariant parameters, those functions should be marked pure, and all parameters should be marked invariant. I can see many places where some parameters could be invariant and some not. Pure functions (as Walter envisions them) require ALL invariant parameters.

No, I'm not. I'm only suggesting that functions that are invariant and const functions are redefined to be like pure functions... Merging concepts together. There's no reason for an invariant argument to a function require the function itself to be invariant/pure.
Jul 23 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 No, I'm not.  I'm only suggesting that functions that are invariant
 and const functions are redefined to be like pure functions...
 Merging concepts together.  There's no reason for an invariant
 argument to a function require the function itself to be
 invariant/pure.

If invariance and purity were merged, then the whole system of invariant strings, which works great, would have to be scrapped. I don't see a gain that approaches that downside.
Jul 23 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Jason House wrote:
 No, I'm not.  I'm only suggesting that functions that are invariant
 and const functions are redefined to be like pure functions...
 Merging concepts together.  There's no reason for an invariant
 argument to a function require the function itself to be
 invariant/pure.

If invariance and purity were merged, then the whole system of invariant strings, which works great, would have to be scrapped. I don't see a gain that approaches that downside.

Why is that? The only thing I can think of is the dup function.
Jul 23 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 Walter Bright Wrote:
 
 Jason House wrote:
 No, I'm not.  I'm only suggesting that functions that are invariant
 and const functions are redefined to be like pure functions...
 Merging concepts together.  There's no reason for an invariant
 argument to a function require the function itself to be
 invariant/pure.

strings, which works great, would have to be scrapped. I don't see a gain that approaches that downside.

Why is that?

Because any function that takes a string argument (strings are invariant) would then have to be a pure function. You couldn't even write: writefln("hello world"); because I/O functions cannot be pure.
Jul 23 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright wrote:

 Jason House wrote:
 Walter Bright Wrote:
 
 Jason House wrote:
 No, I'm not.  I'm only suggesting that functions that are invariant
 and const functions are redefined to be like pure functions...
 Merging concepts together.  There's no reason for an invariant
 argument to a function require the function itself to be
 invariant/pure.

strings, which works great, would have to be scrapped. I don't see a gain that approaches that downside.

Why is that?

Because any function that takes a string argument (strings are invariant) would then have to be a pure function. You couldn't even write: writefln("hello world"); because I/O functions cannot be pure.

I must have really messed up something that I said somewhere along the line because you're the second person to think that! writefln is neither invariant nor pure and would not be modified by this discussion.
Jul 23 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 I must have really messed up something that I said somewhere along the line
 because you're the second person to think that!  writefln is neither
 invariant nor pure and would not be modified by this discussion.

My understanding was that you were suggesting that any function with any invariant arguments should also be pure. My apologies if that was a misunderstanding.
Jul 24 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jason House" wrote
 Steven Schveighoffer Wrote:

 They don't make any less sense than declaring invariant variables.  Or
 declaring invariant parameters.

 Can you see use in the following function signature:

 void f(invariant(somestruct) *x) {...}

 If so, an invariant member function is no different.

Will the fields of somestruct be accessed directly? If so, there's no change in functionality. If not, will the invariant functions of somestruct be used to modify global state? If not, there's not change in functionality... I don't think what I'm suggesting changes a lot of code.

You are suggesting that invariant functions simply be illegal, and pure functions not. I am saying that you are leaving a hole in the type system by doing that. It is analogous to saying, if a function has any invariant parameters, those functions should be marked pure, and all parameters should be marked invariant. I can see many places where some parameters could be invariant and some not. Pure functions (as Walter envisions them) require ALL invariant parameters.

No, I'm not. I'm only suggesting that functions that are invariant and const functions are redefined to be like pure functions... Merging concepts together. There's no reason for an invariant argument to a function require the function itself to be invariant/pure.

An invariant function is defined as one that has an invariant argument (the 'this' pointer). There are no other special requirements for invariant functions. So I think you still don't understand the concept. invariant functions === invariant data. -Steve
Jul 24 2008
prev sibling parent reply Don <nospam nospam.com.au> writes:
Steven Schveighoffer wrote:
 "Jason House" wrote
 Steven Schveighoffer Wrote:

 "Jason House" wrote
 Walter Bright Wrote:
 The missing ingredient here is what the 'pure' modifier for functions
 provides. That is the ability to diagnose attempts to alter global 
 state
 from within a function that is not supposed to do that. Invariant does
 not imply pure.

That's actually a very key part to my whole point. There is very little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference.

function itself is not invariant. It's a function whose 'this' pointer is marked as invariant.

It's not that I misunderstand but that I question. Given the goals of the const system, invariant functions, as defined, don't make a lot of sense. They make some sense, but not a lot of sense :)

They don't make any less sense than declaring invariant variables. Or declaring invariant parameters. Can you see use in the following function signature: void f(invariant(somestruct) *x) {...} If so, an invariant member function is no different.

I think it is quite different. The member function is defined inside the class. Think what it means for the 'this' parameter to be invariant. Unlike const, it's not conditional. An invariant instance can only call invariant and const member functions; it can never call mutable member functions. Likewise, a non-invariant instance can never call invariant member functions. Seems to me, that you've actually defined 2 classes. There could, for example, be completely different vtables for invariant vs mutable instances. interface ConstFoo { .. constmemberfunctions } class MutableFoo: ConstFoo { } class InvariantFoo: ConstFoo { } Any instance of Foo is either an instance of MutableFoo, or of InvariantFoo. I'm not sure why you wouldn't just make two classes, and apply invariant at the class definition level.
Jul 24 2008
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-07-24 05:01:37 -0400, Don <nospam nospam.com.au> said:

 I think it is quite different. The member function is defined inside the class.
 
 Think what it means for the 'this' parameter to be invariant. Unlike 
 const, it's not conditional. An invariant instance can only call 
 invariant and const member functions; it can never call mutable member 
 functions. Likewise, a non-invariant instance can never call invariant 
 member functions.
 Seems to me, that you've actually defined 2 classes. There could, for 
 example, be completely different vtables for invariant vs mutable 
 instances.
 
 interface ConstFoo
 {
    .. constmemberfunctions
 }
 
 class MutableFoo: ConstFoo
 {
 }
 
 class InvariantFoo: ConstFoo
 {
 }
 
 Any instance of Foo is either an instance of MutableFoo, or of InvariantFoo.
 
 I'm not sure why you wouldn't just make two classes, and apply 
 invariant at the class definition level.

Indeed, and that's pretty much how it is done in Objective-C, and it works very well there, except that in Objective-C you generally find this pattern: abstract class Foo {} abstract class MutableFoo : Foo {} class PrivateFooImpl : Foo {} class PrivateMutableFooImpl : MutableFoo {} where abstract classes here represent the base class of a class cluster[1], providing mainly an interface to build upon. The downside is that this scheme only works with classes. You can't have invariant primitive types this way, and since a D string is a primitive type, you still have a need for invariant in D. Basically I like all this const/invariant stuff, but I feel the model in Objective-C works better for classes. [1]: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_9.html -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 24 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Don" wrote
 Steven Schveighoffer wrote:
 "Jason House" wrote
 Steven Schveighoffer Wrote:

 "Jason House" wrote
 Walter Bright Wrote:
 The missing ingredient here is what the 'pure' modifier for functions
 provides. That is the ability to diagnose attempts to alter global 
 state
 from within a function that is not supposed to do that. Invariant 
 does
 not imply pure.

That's actually a very key part to my whole point. There is very little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference.

function itself is not invariant. It's a function whose 'this' pointer is marked as invariant.

It's not that I misunderstand but that I question. Given the goals of the const system, invariant functions, as defined, don't make a lot of sense. They make some sense, but not a lot of sense :)

They don't make any less sense than declaring invariant variables. Or declaring invariant parameters. Can you see use in the following function signature: void f(invariant(somestruct) *x) {...} If so, an invariant member function is no different.

I think it is quite different. The member function is defined inside the class. Think what it means for the 'this' parameter to be invariant. Unlike const, it's not conditional. An invariant instance can only call invariant and const member functions; it can never call mutable member functions. Likewise, a non-invariant instance can never call invariant member functions. Seems to me, that you've actually defined 2 classes. There could, for example, be completely different vtables for invariant vs mutable instances.

With invariant functions, what you are defining is a contract for that member function. The contract states that the object passed to the function as the 'this' pointer must be invariant. Let's not forget that member functions are simply functions which require you to pass the object. The only 'special' part of it is the way you write the function call. There is no reason you need to define multiple classes. You are just defining more functions that take a different argument type as the 'this' pointer. I don't see why it's so confusing to define those functions in the same class as the mutable functions. Personally, I probably will only ever write const functions, because I don't see myself using invariant classes very much. But it could be a source of optimization. For example, if there is member data used in the function that could be changing, even a const function must synchronize the data. If the function is invariant, the coder does not have to synchronize, and saves the cost of that. -Steve
Jul 24 2008
next sibling parent reply Don <nospam nospam.com.au> writes:
Steven Schveighoffer wrote:
 "Don" wrote
 Steven Schveighoffer wrote:
 "Jason House" wrote
 Steven Schveighoffer Wrote:

 "Jason House" wrote
 Walter Bright Wrote:
 The missing ingredient here is what the 'pure' modifier for functions
 provides. That is the ability to diagnose attempts to alter global 
 state
 from within a function that is not supposed to do that. Invariant 
 does
 not imply pure.

little difference between pure and invariant functions. Why do we need a concept for both? Under the assumption that we're adding const to support functional programming, I don't understand the motivation for this difference.

function itself is not invariant. It's a function whose 'this' pointer is marked as invariant.

the const system, invariant functions, as defined, don't make a lot of sense. They make some sense, but not a lot of sense :)

declaring invariant parameters. Can you see use in the following function signature: void f(invariant(somestruct) *x) {...} If so, an invariant member function is no different.

class. Think what it means for the 'this' parameter to be invariant. Unlike const, it's not conditional. An invariant instance can only call invariant and const member functions; it can never call mutable member functions. Likewise, a non-invariant instance can never call invariant member functions. Seems to me, that you've actually defined 2 classes. There could, for example, be completely different vtables for invariant vs mutable instances.

With invariant functions, what you are defining is a contract for that member function. The contract states that the object passed to the function as the 'this' pointer must be invariant. Let's not forget that member functions are simply functions which require you to pass the object. The only 'special' part of it is the way you write the function call.

There's another difference. The person writing a member function is always the same person who wrote the class. They've made a conscious design decision that this class can be used as an invariant class (Not all classes can be used in this way, in fact most cannot).
 There is no reason you need to define multiple classes.  You are just 
 defining more functions that take a different argument type as the 'this' 
 pointer.  I don't see why it's so confusing to define those functions in the 
 same class as the mutable functions.

My gut feel is that mixing mutable and invariant functions in the one class would be an indication of poor design. Which is why I'd be very interested in use cases.
Jul 24 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Don" wrote
 Steven Schveighoffer wrote:
 With invariant functions, what you are defining is a contract for that 
 member function.  The contract states that the object passed to the 
 function as the 'this' pointer must be invariant.  Let's not forget that 
 member functions are simply functions which require you to pass the 
 object.  The only 'special' part of it is the way you write the function 
 call.

There's another difference. The person writing a member function is always the same person who wrote the class. They've made a conscious design decision that this class can be used as an invariant class (Not all classes can be used in this way, in fact most cannot).

Any class that has const functions can be used as an invariant.
 There is no reason you need to define multiple classes.  You are just 
 defining more functions that take a different argument type as the 'this' 
 pointer.  I don't see why it's so confusing to define those functions in 
 the same class as the mutable functions.

My gut feel is that mixing mutable and invariant functions in the one class would be an indication of poor design. Which is why I'd be very interested in use cases.

What about building an invariant lookup table dynamically? First you use the mutable methods to build the table, then you mark it as invariant so you no longer have to synchronize. I can see someone using such a table in another part of the code in a mutable state, so why repeat all the code for that lookup object? You could put the common parts of code in unsynchronized const private functions, and then the synchronization in the public const API. -Steve
Jul 24 2008
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-07-24 10:21:20 -0400, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 There is no reason you need to define multiple classes.  You are just
 defining more functions that take a different argument type as the 'this'
 pointer.  I don't see why it's so confusing to define those functions in the
 same class as the mutable functions.

You probably never absolutely need two classes, but sometime it would help to have a different implementation, and thus different members, for a mutable and an invariant version of a class. For instance, a mutable collection could have additional storage for keeping track of the last inserted object, a more complex data structure to list some late-bound parts, or perhaps an undo history. All of this is usless to the invariant version, but if both are the same class you can't escape the additional logic and storage space of the mutable one. Thus, the need to make two classes. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 24 2008
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
Don wrote:
 I'm not sure why you wouldn't just make two classes, and apply invariant 
 at the class definition level.

As I understand it, the difference is that you can only call invariant functions on an invariant object. So, if you have a reference to the class, and the reference is marked invariant, then all of the non-invariant functions can't be called. Why would you have an invariant object, you say? Well, a basic example is where you create an object, initialize it, then cast it to invariant. (Presumably, you can guarantee, that it is invariant from the moment of the cast until the program dies.)
Jul 24 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Don wrote:
 What if the community concensus remains that const is just too
 complicated, without enough benefit?

all the other const proposals were much more complex.

That doesn't mean I have to like what we ended up with :-) I think part of the problem is that I simply don't agree with the mixed functional / imperative approach that appears to be the overarching direction of D. And while I do quite a bit of concurrent programming, it's not in a way that will reap any benefit from this design. In fact, the language features added to support it are more of an annoyance than they are an aid. This may very well mean that D is simply not the language for me in the long term. However, with C and C++ as the only real alternatives for systems programming, there aren't many other options available. Sean
Jul 21 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:
 I simply don't agree with the mixed functional / imperative approach
 that appears to be the overarching direction of D.

 This may very well mean that D is simply not the language for me
 in the long term. However, with C and C++ as the only real
 alternatives for systems programming, there aren't many other
 options available.

I know this is a scary/huge question, but may ask you what kind of computer language is your dream/ideal language? (I think all good programmers/technicians have to keep looking for better languages/tools for all their professional life). Bye, bearophile
Jul 21 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Sean Kelly:
 I simply don't agree with the mixed functional / imperative approach
 that appears to be the overarching direction of D.

 This may very well mean that D is simply not the language for me
 in the long term. However, with C and C++ as the only real
 alternatives for systems programming, there aren't many other
 options available.


 (I think all good programmers/technicians have to keep looking for better
languages/tools for all their

Depends on the problem being solved. Right now however, Erlang backed by D is the best I've found for general purpose server / distributed programming. That gives me a control language with a good parallel programming model as well as systems / mutable state language for optimization points, shared data, and systems programming bits. So perhaps roughly similar to D2 from a 1000' viewpoint, but as always, the devil's in the details. Sean
Jul 21 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Depends on the problem being solved.  Right now however, Erlang backed by
 D is the best I've found for general purpose server / distributed programming.
 That gives me a control language with a good parallel programming model as
 well as systems / mutable state language for optimization points, shared data,
 and systems programming bits.  So perhaps roughly similar to D2 from a 1000'
 viewpoint, but as always, the devil's in the details.

But, you said you didn't wish to mix functional and imperative programming? I don't understand.
Jul 21 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Depends on the problem being solved.  Right now however, Erlang backed by
 D is the best I've found for general purpose server / distributed 
 programming.
 That gives me a control language with a good parallel programming 
 model as
 well as systems / mutable state language for optimization points, 
 shared data,
 and systems programming bits.  So perhaps roughly similar to D2 from a 
 1000'
 viewpoint, but as always, the devil's in the details.

But, you said you didn't wish to mix functional and imperative programming? I don't understand.

Sean Kelly on Erlang: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=72496 """ I agree that it's important for mutability to be available if necessary. But Erlang integrates reasonably well with C, so I don't consider this an issue really. In fact, I prefer this approach to the "all in one" approach that D 2.0 seems to be aiming for, as I prefer that there be a semantic separation between my functional and imperative code. I feel that this is a good way of preventing "bleed through" of concepts that would complicate and confuse code. It also neatly avoids a motivator for producing monolithic code, and the consequent risk that the mutable-state portion may fail and corrupt the entire process. But this is really a matter of preference. I'm sure many people disagree, and others simply don't work on the type of applications Erlang was designed to target. I just happen to be in the niche that Erlang was specifically intended for. I only wish I'd heard about it 15 years ago instead of spending all that time mucking about with C++. """ --bb
Jul 21 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Depends on the problem being solved.  Right now however, Erlang backed by
 D is the best I've found for general purpose server / distributed 
 programming.
 That gives me a control language with a good parallel programming 
 model as
 well as systems / mutable state language for optimization points, 
 shared data,
 and systems programming bits.  So perhaps roughly similar to D2 from a 
 1000'
 viewpoint, but as always, the devil's in the details.

But, you said you didn't wish to mix functional and imperative programming? I don't understand.

Not in the same language. One reason being the impact it will have on managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess. Regarding the D mixed functional / imperative approach, another issue I have with it is that it's exactly the reverse of the Erlang / C model. While Erlang / C is functional for control structures and imperative for optimization points, D looks like it will be imperative for control and functional for optimization. Plus, I really like the concurrency model in Erlang. Sean
Jul 21 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Walter Bright wrote:
 But, you said you didn't wish to mix functional and imperative 
 programming? I don't understand.

Not in the same language. One reason being the impact it will have on managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess.

I agree that diverse paradigm support can lead to a mess. On the other hand, to be a mainstream language I think one must support diverse paradigms because programmers are diverse. Additionally, nobody really knows yet which horse is the right one to back for multicore programming, but functional certainly is a favorite. I disagree that using multiple languages for one project is a good idea, unless one language is hosted by the other (like emacs/elisp). Trying to get two languages produced by different vendors to consistently work together across platforms and differing upgrade schedules can be a prescription for a lot of extra work. Is learning two different languages really easier than learning two different paradigms in the same language?
 Regarding the D mixed functional / imperative approach, another issue I 
 have with it is that it's exactly the reverse of the Erlang / C model. 
 While Erlang / C is functional for control structures and imperative for 
 optimization points, D looks like it will be imperative for control and 
 functional for optimization.  Plus, I really like the concurrency model 
 in Erlang.

A side note: Everyone complains about feature bloat in Microsoft Word. What the world needs is a lean, mean word processor. But the problem is, customer Bill says: "That's great, but I need feature #543. Not having it is a deal breaker for me." Customer Sue says: "I'd buy the lean & mean one, but I need feature #1678. Everything I do is based on that." And so on. Feature creep is the result of inexorable and unrelenting pressure for them.
Jul 22 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 I agree that diverse paradigm support can lead to a mess. On the other 
 hand, to be a mainstream language I think one must support diverse 
 paradigms because programmers are diverse. Additionally, nobody really 
 knows yet which horse is the right one to back for multicore 
 programming, but functional certainly is a favorite.

Yet, it's becoming standard, in most places I look now people are starting to use different languages for different purposes. It's all the "the right tool for the right job" thing. Especially in the dynamic language camp people mix Python with many other kinds of languages. In some situations such mixing isn't too much difficult, for example if your want to use C# from IronPython or Java from Groovy, because those higher level languages are written in the lower level one and both run on the same VM. Bye, bearophile
Jul 22 2008
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Walter Bright wrote:
 But, you said you didn't wish to mix functional and imperative
 programming? I don't understand.

Not in the same language. One reason being the impact it will have on managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess.

I agree that diverse paradigm support can lead to a mess. On the other hand, to be a mainstream language I think one must support diverse paradigms because programmers are diverse. Additionally, nobody really knows yet which horse is the right one to back for multicore programming, but functional certainly is a favorite. I disagree that using multiple languages for one project is a good idea, unless one language is hosted by the other (like emacs/elisp). Trying to get two languages produced by different vendors to consistently work together across platforms and differing upgrade schedules can be a prescription for a lot of extra work. Is learning two different languages really easier than learning two different paradigms in the same language?
 Regarding the D mixed functional / imperative approach, another issue
 I have with it is that it's exactly the reverse of the Erlang / C
 model. While Erlang / C is functional for control structures and
 imperative for optimization points, D looks like it will be imperative
 for control and functional for optimization.  Plus, I really like the
 concurrency model in Erlang.

A side note: Everyone complains about feature bloat in Microsoft Word. What the world needs is a lean, mean word processor. But the problem is, customer Bill says: "That's great, but I need feature #543. Not having it is a deal breaker for me." Customer Sue says: "I'd buy the lean & mean one, but I need feature #1678. Everything I do is based on that." And so on. Feature creep is the result of inexorable and unrelenting pressure for them.

The word example is wrong in that, in your example, bill doesn't need feature #1678, and sue doesn't need #543. The answer to that is a model similar to eclipse: both sue and bill can use eclipse but since bill works with c/c++ he can get a pre-packaged version with CDT which is much smaller than the entire eclipse project, and sue can get her eclipse pre-packaged with JDT since she works with Java. This is why Eclipse is so popular and supported by many large companies like oracle, IBM, etc.. The same goes to the popular browser Firefox and its extensions. No need to bundle everything like Microsoft word does, it's much better to have a system to allow users to integrate features they require beyond the lean & mean core. here's my educated guess: Sean uses erlang + D to get the same benefits. he can have the feature sets of both languages with their own lean & mean syntaxes that are geared toward their respective feature sets. while if he had used one language with both feature sets, than the syntax of that language would be much more complicated in order to support all the features. C++ as an example: its syntax is horrible due to the fact that it can do so much. if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk or something like that. if I want to do procedural code I'll prefer C syntax instead, but I definitely do not want to have a compromise of both syntaxes in one language (we all know that a programing language is an agreed upon compromise) that will not allow me to express my OOP code in a concise OOP way and also will not allow me to express my procedural code in a concise procedural way. an everything-including-the-kitchen-sink language cannot provide concise syntax for any of the paradigms it supports.
Jul 22 2008
next sibling parent reply superdan <super dan.org> writes:
Yigal Chripun Wrote:

 Walter Bright wrote:
 Sean Kelly wrote:
 Walter Bright wrote:
 But, you said you didn't wish to mix functional and imperative
 programming? I don't understand.

Not in the same language. One reason being the impact it will have on managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess.

I agree that diverse paradigm support can lead to a mess. On the other hand, to be a mainstream language I think one must support diverse paradigms because programmers are diverse. Additionally, nobody really knows yet which horse is the right one to back for multicore programming, but functional certainly is a favorite. I disagree that using multiple languages for one project is a good idea, unless one language is hosted by the other (like emacs/elisp). Trying to get two languages produced by different vendors to consistently work together across platforms and differing upgrade schedules can be a prescription for a lot of extra work. Is learning two different languages really easier than learning two different paradigms in the same language?
 Regarding the D mixed functional / imperative approach, another issue
 I have with it is that it's exactly the reverse of the Erlang / C
 model. While Erlang / C is functional for control structures and
 imperative for optimization points, D looks like it will be imperative
 for control and functional for optimization.  Plus, I really like the
 concurrency model in Erlang.

A side note: Everyone complains about feature bloat in Microsoft Word. What the world needs is a lean, mean word processor. But the problem is, customer Bill says: "That's great, but I need feature #543. Not having it is a deal breaker for me." Customer Sue says: "I'd buy the lean & mean one, but I need feature #1678. Everything I do is based on that." And so on. Feature creep is the result of inexorable and unrelenting pressure for them.

The word example is wrong in that, in your example, bill doesn't need feature #1678, and sue doesn't need #543. The answer to that is a model similar to eclipse: both sue and bill can use eclipse but since bill works with c/c++ he can get a pre-packaged version with CDT which is much smaller than the entire eclipse project, and sue can get her eclipse pre-packaged with JDT since she works with Java. This is why Eclipse is so popular and supported by many large companies like oracle, IBM, etc.. The same goes to the popular browser Firefox and its extensions. No need to bundle everything like Microsoft word does, it's much better to have a system to allow users to integrate features they require beyond the lean & mean core.

good point, i was thinking of firefox and thunderbird too. then i realized the reality is, both ff and tb ended up integrating the most popular extensions in their core. why? because there is pressure, hence walter's point.
 here's my educated guess: Sean uses erlang + D to get the same benefits.
 he can have the feature sets of both languages with their own lean &
 mean syntaxes that are geared toward their respective feature sets.
 while if he had used one language with both feature sets, than the
 syntax of that language would be much more complicated in order to
 support all the features.
 C++ as an example: its syntax is horrible due to the fact that it can do
 so much. 

no. its syntax is horrible because it has a shitty design. bjarne has made the tactical mistake of ignoring theoretical syntax matters and also compiler construction costs, in favor of what greedily looked most usable at the moment for the feature being designed. he is known for shooing away all those who opposed additions on grounds of syntactic and implementation difficulties. he pushed the fucking angle brackets over the dead body of pennello and the fucking export and two-phase lookup shit over everybody's dead body. what does that have to do with c++ being multiparadigm? nothing? correct! congratulations, you won a plasma tv set. bjarne was strong on strategy and extremely weak in tactics. that can be clearly seen today as frozen into the language. walter is ok in both. his only problem is that he looks too much at c++, both up and down. when in doubt he does what c++ does, for example why the hell is this a pointer? makes no sense. well it is in c++. and so on. thank god const is not the same. in fact i could see a more definite break with c++'s shitty parts once walter got those new aides bartosz and andrei and i forgot the rest.
 if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk
 or something like that. if I want to do procedural code I'll prefer C
 syntax instead, but I definitely do not want to have a compromise of
 both syntaxes in one language (we all know that a programing language is
 an agreed upon compromise) that will not allow me to express my OOP code
 in a concise OOP way and also will not allow me to express my procedural
 code in a concise procedural way.
 
 an everything-including-the-kitchen-sink language cannot provide concise
 syntax for any of the paradigms it supports.

good language design is not about the kitchen sink as much as harmoniously accommodating multiple styles. nobody has shown that that can't be done.
Jul 22 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
superdan wrote:
 
 good point, i was thinking of firefox and thunderbird too. then i
 realized the reality is, both ff and tb ended up integrating the most
 popular extensions in their core. why? because there is pressure,
 hence walter's point.
 

of the browser itself only when the extension "fixed" problems in the core itself and/or the feature is general enough that it should have been designed as part of the core. the Tab implementation for example benefited from integrating functionally from extensions and the session feature was added since it is general and useful for all FF users. let's look again to eclipse to see this difference: eclipse 3.4 added a new update manager with lots of new features. this makes sense as part of the SDK of eclipse itself since all users of eclipse will benefit from this. on the other hand, JDT will not ever be needed by a c++ programmer (unless he decides to move to Java). same goes for CDT, PDT, etc.. some features should be added to the core, and some will not ever be general to be part of the core. another example, the delicious extension will always be only useful for delicious subscribers and should never be part of Firefox itself.
 here's my educated guess: Sean uses erlang + D to get the same
 benefits. he can have the feature sets of both languages with their
 own lean & mean syntaxes that are geared toward their respective
 feature sets. while if he had used one language with both feature
 sets, than the syntax of that language would be much more
 complicated in order to support all the features. C++ as an
 example: its syntax is horrible due to the fact that it can do so
 much.

no. its syntax is horrible because it has a shitty design. bjarne has made the tactical mistake of ignoring theoretical syntax matters and also compiler construction costs, in favor of what greedily looked most usable at the moment for the feature being designed. he is known for shooing away all those who opposed additions on grounds of syntactic and implementation difficulties. he pushed the fucking angle brackets over the dead body of pennello and the fucking export and two-phase lookup shit over everybody's dead body. what does that have to do with c++ being multiparadigm? nothing? correct! congratulations, you won a plasma tv set.

Even with that in mind, that's not enough. think of this this way: what's the best way to design GUI? probably to draw it in a visual designer and not using some API. what's the best way to write a database query? probably SQL is the most concise way to express that. etc, etc.. there's a whole paradigm of Language Oriented Programming that you should look at. (MPS by jetbrains is a good example of that, I think) the point is - when you restrict yourself to a specific domain you can design the best way to express in that domain that may conflict with other domains in a general language ( you probably wouldn't want to draw all your "code" with a visual designer, while that's the best way to express gui..)
 bjarne was strong on strategy and extremely weak in tactics. that can
 be clearly seen today as frozen into the language. walter is ok in
 both. his only problem is that he looks too much at c++, both up and
 down. when in doubt he does what c++ does, for example why the hell
 is this a pointer? makes no sense. well it is in c++. and so on.
 thank god const is not the same. in fact i could see a more definite
 break with c++'s shitty parts once walter got those new aides bartosz
 and andrei and i forgot the rest.

I totally agree with that point about C++. Walter always looks at C++ when unsure, and that isn't good IMHO. D is a new language that should draw on the good stuff from all designs and languages instead of just looking at C++. I disagree about const those. it is a departure from C++ but not a big enough departure.
 
 if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk or
 something like that. if I want to do procedural code I'll prefer C 
 syntax instead, but I definitely do not want to have a compromise
 of both syntaxes in one language (we all know that a programing
 language is an agreed upon compromise) that will not allow me to
 express my OOP code in a concise OOP way and also will not allow me
 to express my procedural code in a concise procedural way.
 
 an everything-including-the-kitchen-sink language cannot provide
 concise syntax for any of the paradigms it supports.

good language design is not about the kitchen sink as much as harmoniously accommodating multiple styles. nobody has shown that that can't be done.

Since a language is a compromise that's only true to an extent. Some features are conflicting and you cannot design a language with all features because of that. You cannot design a language both static and dynamic ( At least to my knowledge ) since these two approaches are conflicting designs. And both ways have cons and pros. Can you design a language with the benefits of both, without the drawbacks of both?
Jul 22 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Yigal Chripun wrote:
 superdan wrote:
 good language design is not about the kitchen sink as much as
 harmoniously accommodating multiple styles. nobody has shown that
 that can't be done.

Since a language is a compromise that's only true to an extent. Some features are conflicting and you cannot design a language with all features because of that. You cannot design a language both static and dynamic ( At least to my knowledge ) since these two approaches are conflicting designs. And both ways have cons and pros. Can you design a language with the benefits of both, without the drawbacks of both?

Java is a statically typed, dynamic language. So it can be done, though I'm sure people have varying opinions about the benefits of this approach :-) Sean
Jul 22 2008
next sibling parent superdan <super dan.org> writes:
Sean Kelly Wrote:

 Yigal Chripun wrote:
 superdan wrote:
 good language design is not about the kitchen sink as much as
 harmoniously accommodating multiple styles. nobody has shown that
 that can't be done.

Since a language is a compromise that's only true to an extent. Some features are conflicting and you cannot design a language with all features because of that. You cannot design a language both static and dynamic ( At least to my knowledge ) since these two approaches are conflicting designs. And both ways have cons and pros. Can you design a language with the benefits of both, without the drawbacks of both?

Java is a statically typed, dynamic language. So it can be done, though I'm sure people have varying opinions about the benefits of this approach :-)

yeah i was about to write something to that effect too. forth also comes to mind. once d gets proper compile-time reflection, dynamic semantics will be a fart in the standard library. just look at std.variant, particularly how it implements the "length" shit. it screams "give me static reflection and i'll move the earth".
Jul 22 2008
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Sean Kelly wrote:
 Yigal Chripun wrote:
 superdan wrote:
 good language design is not about the kitchen sink as much as
 harmoniously accommodating multiple styles. nobody has shown that
 that can't be done.

Since a language is a compromise that's only true to an extent. Some features are conflicting and you cannot design a language with all features because of that. You cannot design a language both static and dynamic ( At least to my knowledge ) since these two approaches are conflicting designs. And both ways have cons and pros. Can you design a language with the benefits of both, without the drawbacks of both?

Java is a statically typed, dynamic language. So it can be done, though I'm sure people have varying opinions about the benefits of this approach :-) Sean

I meant statically typed vs. dynamically typed. and you cannot have both. I do not understand what you mean with your Java example.
Jul 23 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Yigal Chripun (yigal100 gmail.com)'s article
 Sean Kelly wrote:
 Yigal Chripun wrote:
 superdan wrote:
 good language design is not about the kitchen sink as much as
 harmoniously accommodating multiple styles. nobody has shown that
 that can't be done.

Since a language is a compromise that's only true to an extent. Some features are conflicting and you cannot design a language with all features because of that. You cannot design a language both static and dynamic ( At least to my knowledge ) since these two approaches are conflicting designs. And both ways have cons and pros. Can you design a language with the benefits of both, without the drawbacks of both?

Java is a statically typed, dynamic language. So it can be done, though I'm sure people have varying opinions about the benefits of this approach :-)

I meant statically typed vs. dynamically typed. and you cannot have both. I do not understand what you mean with your Java example.

I suppose I should have been more clear. Java is statically typed but dynamically bound. Pretty uncommon for a pure OO language. Sean
Jul 23 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
 
 I suppose I should have been more clear.  Java is statically typed but
 dynamically bound.  Pretty uncommon for a pure OO language.
 
 
 Sean

There must be some misunderstanding here. Java is not dynamically bound, in the normal, general sense. The normal sense referring to the binding of *variables* of course. Were you meaning that the binding of *classes* was dynamic? That is true of course, but one wouldn't call Java dynamically-bound because of that. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 26 2008
prev sibling parent Justin Spahr-Summers <Justin.SpahrSummers gmail.com> writes:
On 2008-07-23 16:09:02 -0500, Yigal Chripun <yigal100 gmail.com> said:

 Sean Kelly wrote:
 Yigal Chripun wrote:
 superdan wrote:
 
 good language design is not about the kitchen sink as much as
 harmoniously accommodating multiple styles. nobody has shown that
 that can't be done.

Since a language is a compromise that's only true to an extent. Some features are conflicting and you cannot design a language with all features because of that. You cannot design a language both static and dynamic ( At least to my knowledge ) since these two approaches are conflicting designs. And both ways have cons and pros. Can you design a language with the benefits of both, without the drawbacks of both?

Java is a statically typed, dynamic language. So it can be done, though I'm sure people have varying opinions about the benefits of this approach :-) Sean

I meant statically typed vs. dynamically typed. and you cannot have both. I do not understand what you mean with your Java example.

Actually, Objective-C is pretty close to having both. Variables are statically typed for types inherited from C (primitives, essentially), and can optionally be statically typed for object pointers (e.g. NSString *), but you can also use "id" to represent any object. Even beyond declarations, there are things like "isa swizzling" that can change the observable type of an object or class at runtime.
Jul 23 2008
prev sibling parent reply superdan <super dan.org> writes:
Yigal Chripun Wrote:

 superdan wrote:
 
 good point, i was thinking of firefox and thunderbird too. then i
 realized the reality is, both ff and tb ended up integrating the most
 popular extensions in their core. why? because there is pressure,
 hence walter's point.
 

of the browser itself only when the extension "fixed" problems in the core itself and/or the feature is general enough that it should have been designed as part of the core. the Tab implementation for example benefited from integrating functionally from extensions and the session feature was added since it is general and useful for all FF users. let's look again to eclipse to see this difference: eclipse 3.4 added a new update manager with lots of new features. this makes sense as part of the SDK of eclipse itself since all users of eclipse will benefit from this. on the other hand, JDT will not ever be needed by a c++ programmer (unless he decides to move to Java). same goes for CDT, PDT, etc.. some features should be added to the core, and some will not ever be general to be part of the core. another example, the delicious extension will always be only useful for delicious subscribers and should never be part of Firefox itself.
 here's my educated guess: Sean uses erlang + D to get the same
 benefits. he can have the feature sets of both languages with their
 own lean & mean syntaxes that are geared toward their respective
 feature sets. while if he had used one language with both feature
 sets, than the syntax of that language would be much more
 complicated in order to support all the features. C++ as an
 example: its syntax is horrible due to the fact that it can do so
 much.

no. its syntax is horrible because it has a shitty design. bjarne has made the tactical mistake of ignoring theoretical syntax matters and also compiler construction costs, in favor of what greedily looked most usable at the moment for the feature being designed. he is known for shooing away all those who opposed additions on grounds of syntactic and implementation difficulties. he pushed the fucking angle brackets over the dead body of pennello and the fucking export and two-phase lookup shit over everybody's dead body. what does that have to do with c++ being multiparadigm? nothing? correct! congratulations, you won a plasma tv set.

Even with that in mind, that's not enough. think of this this way: what's the best way to design GUI? probably to draw it in a visual designer and not using some API. what's the best way to write a database query? probably SQL is the most concise way to express that. etc, etc.. there's a whole paradigm of Language Oriented Programming that you should look at. (MPS by jetbrains is a good example of that, I think) the point is - when you restrict yourself to a specific domain you can design the best way to express in that domain that may conflict with other domains in a general language ( you probably wouldn't want to draw all your "code" with a visual designer, while that's the best way to express gui..)
 bjarne was strong on strategy and extremely weak in tactics. that can
 be clearly seen today as frozen into the language. walter is ok in
 both. his only problem is that he looks too much at c++, both up and
 down. when in doubt he does what c++ does, for example why the hell
 is this a pointer? makes no sense. well it is in c++. and so on.
 thank god const is not the same. in fact i could see a more definite
 break with c++'s shitty parts once walter got those new aides bartosz
 and andrei and i forgot the rest.

I totally agree with that point about C++. Walter always looks at C++ when unsure, and that isn't good IMHO. D is a new language that should draw on the good stuff from all designs and languages instead of just looking at C++. I disagree about const those. it is a departure from C++ but not a big enough departure.
 
 if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk or
 something like that. if I want to do procedural code I'll prefer C 
 syntax instead, but I definitely do not want to have a compromise
 of both syntaxes in one language (we all know that a programing
 language is an agreed upon compromise) that will not allow me to
 express my OOP code in a concise OOP way and also will not allow me
 to express my procedural code in a concise procedural way.
 
 an everything-including-the-kitchen-sink language cannot provide
 concise syntax for any of the paradigms it supports.

good language design is not about the kitchen sink as much as harmoniously accommodating multiple styles. nobody has shown that that can't be done.

Since a language is a compromise that's only true to an extent. Some features are conflicting and you cannot design a language with all features because of that. You cannot design a language both static and dynamic ( At least to my knowledge ) since these two approaches are conflicting designs. And both ways have cons and pros. Can you design a language with the benefits of both, without the drawbacks of both?

obviously if you forgo some shit it's easier to pay attention to other shit and do it better. that goes without sayin' and pretty much anyone who's ever done business at any level knows it, let alone programmers. but forgoing that shit also means there's a loss in expressiveness. all i'm sayin' is that there are many local maxima in this multidimensional shit that language design is, and the easily reachable ones have already been reached (e.g. "all shit is just objects" or "all shit is just functions" or "all shit is just oatmeal and toenails"). but these are local maxima that only greedily optimize on a couple of directions. nobody knows where the global optimum is, but sure as shit it's not on one axis. feel me? is d closing in to that optimum? no idea. is it closer to the optimum than some other languages? fuck yeah. is its gradient positive? looks to me like it is, if only walter doesn't acquire alzheimer or shit.
Jul 22 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 is d closing in to that optimum? no idea. is it closer to the optimum
 than some other languages? fuck yeah. is its gradient positive? looks
 to me like it is, if only walter doesn't acquire alzheimer or shit.

I hope to have a few good years left in me before I get alzheimer's <g>.
Jul 22 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Yigal Chripun wrote:
 The word example is wrong in that, in your example, bill doesn't need
 feature #1678, and sue doesn't need #543. The answer to that is a model
 similar to eclipse: both sue and bill can use eclipse but since bill
 works with c/c++ he can get a pre-packaged version with CDT which is
 much smaller than the entire eclipse project, and sue can get her
 eclipse pre-packaged with JDT since she works with Java. This is why
 Eclipse is so popular and supported by many large companies like oracle,
 IBM, etc.. The same goes to the popular browser Firefox and its
 extensions. No need to bundle everything like Microsoft word does, it's
 much better to have a system to allow users to integrate features they
 require beyond the lean & mean core.

What you're saying is provide a lean & mean core with a pluggable architecture that can be extended by 3rd parties. I think you're quite right that that is a better system than all-in-one. D has a lot of support for "pluggable architecture", such as template metaprogramming and string mixins. Lisp is famous for being a very pluggable language. Unfortunately, I don't see any way to be able to "plug in" the needed support for functional coding, there just isn't enough basic capability in the language. We're trying to fix that.
 C++ as an example: its syntax is horrible due to the fact that it can do
 so much.

I don't agree with that being the reason its syntax is horrible. The reason is more related to efforts to preserve backwards syntax compatibility, and because some expert advice was ignored in the case of using < > for templates.
 if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk
 or something like that. if I want to do procedural code I'll prefer C
 syntax instead, but I definitely do not want to have a compromise of
 both syntaxes in one language (we all know that a programing language is
 an agreed upon compromise) that will not allow me to express my OOP code
 in a concise OOP way and also will not allow me to express my procedural
 code in a concise procedural way.
 
 an everything-including-the-kitchen-sink language cannot provide concise
 syntax for any of the paradigms it supports.

You're right, it can't, but it can provide good enough syntax that overweights the large disadvantages of trying to get two very different languages to work together.
Jul 22 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Walter,
Thanks for replying, please see my notes in the body of the text

Walter Bright wrote:
 Yigal Chripun wrote:
 The word example is wrong in that, in your example, bill doesn't need
 feature #1678, and sue doesn't need #543. The answer to that is a model
 similar to eclipse: both sue and bill can use eclipse but since bill
 works with c/c++ he can get a pre-packaged version with CDT which is
 much smaller than the entire eclipse project, and sue can get her
 eclipse pre-packaged with JDT since she works with Java. This is why
 Eclipse is so popular and supported by many large companies like oracle,
 IBM, etc.. The same goes to the popular browser Firefox and its
 extensions. No need to bundle everything like Microsoft word does, it's
 much better to have a system to allow users to integrate features they
 require beyond the lean & mean core.

What you're saying is provide a lean & mean core with a pluggable architecture that can be extended by 3rd parties. I think you're quite right that that is a better system than all-in-one. D has a lot of support for "pluggable architecture", such as template metaprogramming and string mixins. Lisp is famous for being a very pluggable language. Unfortunately, I don't see any way to be able to "plug in" the needed support for functional coding, there just isn't enough basic capability in the language. We're trying to fix that.

Walter, please take a look at the design used by Nemerle. The language designers of Nemerle achieved a _very_ pluggable architecture via Macros (probably identical to your idea of AST macros). their system allows to implement whole subsets of the language *including the syntax* as plugins which in D are now part of the language. They have DBC, concurrency, etc implemented like that. they have a plan to make an AOP plugin as well. look at: http://nemerle.org/Macros http://nemerle.org/Syntax_extensions http://nemerle.org/doc/Nemerle.Compiler.html etc..
 
 C++ as an example: its syntax is horrible due to the fact that it can do
 so much.

I don't agree with that being the reason its syntax is horrible. The reason is more related to efforts to preserve backwards syntax compatibility, and because some expert advice was ignored in the case of using < > for templates.
 if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk
 or something like that. if I want to do procedural code I'll prefer C
 syntax instead, but I definitely do not want to have a compromise of
 both syntaxes in one language (we all know that a programing language is
 an agreed upon compromise) that will not allow me to express my OOP code
 in a concise OOP way and also will not allow me to express my procedural
 code in a concise procedural way.

 an everything-including-the-kitchen-sink language cannot provide concise
 syntax for any of the paradigms it supports.

You're right, it can't, but it can provide good enough syntax that overweights the large disadvantages of trying to get two very different languages to work together.

It depends on what kind of languages you try to integrate, C and python probably will have issues since they use very different run-times. But, compare that with Java and [J]Ruby both running on the same JVM in one process. you can use classes from both languages together with no trouble at all. you get all the benefits of combining the strengths of both without any drawbacks. in the same way you can instantiate Java classes inside Scala since, again, both run in the same JVM.
Jul 23 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Yigal Chripun:
 Walter, please take a look at the design used by Nemerle.
 The language designers of Nemerle achieved a _very_ pluggable
 architecture via Macros (probably identical to your idea of AST macros).

OMeta is better, it's a tiny metalanguage, that can be implemented in various languages (already done: javascript, scheme, Python, Cola, and maybe more): http://www.cs.ucla.edu/~awarth/ometa/ This is a (partial, but already usable) Python implementation, PyMeta: http://washort.twistedmatrix.com/ I am sure that OMeta will shake the world of computer science. Bye, bearophile
Jul 23 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Yigal Chripun wrote:
 Walter, please take a look at the design used by Nemerle.
 The language designers of Nemerle achieved a _very_ pluggable
 architecture via Macros (probably identical to your idea of AST macros).
 their system allows to implement whole subsets of the language
 *including the syntax* as plugins which in D are now part of the
 language. They have DBC, concurrency, etc implemented like that. they
 have a plan to make an AOP plugin as well.
 look at:
 http://nemerle.org/Macros
 http://nemerle.org/Syntax_extensions
 http://nemerle.org/doc/Nemerle.Compiler.html
 etc..

I've heard about nemerle now and then, but have never looked at it. One of the problems with a user definable syntax is the code may become unreadable. I still find it hard to see how one could implement a const type system, for example, as a language extension. It's a lot more than just syntax.
Jul 23 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
Walter Bright wrote:
 Yigal Chripun wrote:
 Walter, please take a look at the design used by Nemerle.
 The language designers of Nemerle achieved a _very_ pluggable
 architecture via Macros (probably identical to your idea of AST macros).
 their system allows to implement whole subsets of the language
 *including the syntax* as plugins which in D are now part of the
 language. They have DBC, concurrency, etc implemented like that. they
 have a plan to make an AOP plugin as well.
 look at:
 http://nemerle.org/Macros
 http://nemerle.org/Syntax_extensions
 http://nemerle.org/doc/Nemerle.Compiler.html
 etc..

I've heard about nemerle now and then, but have never looked at it. One of the problems with a user definable syntax is the code may become unreadable. I still find it hard to see how one could implement a const type system, for example, as a language extension. It's a lot more than just syntax.

IMHO, syntax extensions with a few restrictions on what syntax can be added to the language is very powerful. but even without the syntax sugar, those macros of nemerle are very powerful and a lot more expressive than templates. the main gripe I have with templates is that they require a different syntax. in nemerle you just use the same code you write at run time to create compile time constructs/ plugins to the language. you do not need to copy OOP features such as interfaces into compile time "concepts" as C++0x does. It's possible to implement D const in nemerle beacuse they provide Compiler APIs that let the programmer plug their macros at different stages of compilation. This is the important thing here, more than the syntax. You have a way to talk with the compiler from your code. This is why DBC is implemented as a set of macros with syntax extensions and allows to implement AOP in the same way. The GC in D has an API that allows your code to control GC via APIs. In the same way, Compiler APIs allow you in compile-time code to control and alter the compilation process.
Jul 23 2008
prev sibling parent reply superdan <super dan.org> writes:
Yigal Chripun Wrote:

 Walter,
 Thanks for replying, please see my notes in the body of the text
 
 Walter Bright wrote:
 Yigal Chripun wrote:
 The word example is wrong in that, in your example, bill doesn't need
 feature #1678, and sue doesn't need #543. The answer to that is a model
 similar to eclipse: both sue and bill can use eclipse but since bill
 works with c/c++ he can get a pre-packaged version with CDT which is
 much smaller than the entire eclipse project, and sue can get her
 eclipse pre-packaged with JDT since she works with Java. This is why
 Eclipse is so popular and supported by many large companies like oracle,
 IBM, etc.. The same goes to the popular browser Firefox and its
 extensions. No need to bundle everything like Microsoft word does, it's
 much better to have a system to allow users to integrate features they
 require beyond the lean & mean core.

What you're saying is provide a lean & mean core with a pluggable architecture that can be extended by 3rd parties. I think you're quite right that that is a better system than all-in-one. D has a lot of support for "pluggable architecture", such as template metaprogramming and string mixins. Lisp is famous for being a very pluggable language. Unfortunately, I don't see any way to be able to "plug in" the needed support for functional coding, there just isn't enough basic capability in the language. We're trying to fix that.

Walter, please take a look at the design used by Nemerle. The language designers of Nemerle achieved a _very_ pluggable architecture via Macros (probably identical to your idea of AST macros). their system allows to implement whole subsets of the language *including the syntax* as plugins which in D are now part of the language. They have DBC, concurrency, etc implemented like that. they have a plan to make an AOP plugin as well. look at: http://nemerle.org/Macros http://nemerle.org/Syntax_extensions http://nemerle.org/doc/Nemerle.Compiler.html etc..

nemerle is a stillborn, you can quote me on that. since 1970 languages tried to make configurable syntax palatable. never works. ever heard of imp72? that's telling. probably the nemerle folks also didn't know. and they will pay for it. why is it the case that configurable syntax never works? no idea. if i had to venture an opinion i'd say configurable syntax does not come natural to humans. natural language has fixed syntax.
Jul 23 2008
next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
superdan wrote:

 nemerle is a stillborn, you can quote me on that. since 1970
 languages tried to make configurable syntax palatable. never works.
 ever heard of imp72? that's telling. probably the nemerle folks also
 didn't know. and they will pay for it.
 
 why is it the case that configurable syntax never works? no idea. if
 i had to venture an opinion i'd say configurable syntax does not come
 natural to humans. natural language has fixed syntax.

nemerle does not provide configurable syntax but rather a core language that you can add extensions to (with some restrictions, I think). It takes a long time for people to switch languages, since it also requires changing a mindset. thus, it takes generations of programmers till new concepts become generally used. languages developed in the 60's had concepts like closures but only now it enters mainstream with c# delegates & events/D delegates/Java is in the process of adding them as well. last point: the comparison with natural languages is wrong - a human need to know only one language to communicate since natural languages are much more powerful. they allow concepts like irony, metaphors, etc, which are not possible in a formal language. I haven't seen a compiler that understands irony yet, but if you plan to develop one than do share, this would be interesting to try out.
Jul 24 2008
prev sibling parent BCS <ao pathlink.com> writes:
Reply to superdan,
 why is it the case that configurable syntax never works? no idea. if i
 had to venture an opinion i'd say configurable syntax does not come
 natural to humans. natural language has fixed syntax.
 

Sort of. Take a walk from the Burbs to the Ghetto and tell me that natural language has fixed syntax. Different people use the same language with different (but to them fixed) syntax. OTOH people often have a hard time understanding people who use different syntax.
Jul 24 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Walter Bright wrote:
 But, you said you didn't wish to mix functional and imperative 
 programming? I don't understand.

Not in the same language. One reason being the impact it will have on managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess.

I agree that diverse paradigm support can lead to a mess. On the other hand, to be a mainstream language I think one must support diverse paradigms because programmers are diverse. Additionally, nobody really knows yet which horse is the right one to back for multicore programming, but functional certainly is a favorite.

I agree. In fact, I'd bet that imperative applications will dwindle over time because such code inherently resists parallelization. But I very much believe that there is an ongoing need for systems languages, and I can't envision a functional systems language. Such languages must allow mutable state.
 I disagree that using multiple languages for one project is a good idea, 
 unless one language is hosted by the other (like emacs/elisp). Trying to 
 get two languages produced by different vendors to consistently work 
 together across platforms and differing upgrade schedules can be a 
 prescription for a lot of extra work. Is learning two different 
 languages really easier than learning two different paradigms in the 
 same language?

It comes back to that semantic barrier I mentioned in my other post. With everything in a single language, I think in team programming it will be inevitable that imperative code will "bleed" into areas that are intended to be functional, purely as a result of the personal styles of the programmers involved. As for learning multiple languages... web development already involves a ton of different protocols, technologies, and languages, so I think there's precedent that this isn't a huge obstacle for most teams. I would personally rather have a set of specialized tools than one tool which can do everything but isn't really ideal for anything.
 Regarding the D mixed functional / imperative approach, another issue 
 I have with it is that it's exactly the reverse of the Erlang / C 
 model. While Erlang / C is functional for control structures and 
 imperative for optimization points, D looks like it will be imperative 
 for control and functional for optimization.  Plus, I really like the 
 concurrency model in Erlang.

A side note: Everyone complains about feature bloat in Microsoft Word. What the world needs is a lean, mean word processor. But the problem is, customer Bill says: "That's great, but I need feature #543. Not having it is a deal breaker for me." Customer Sue says: "I'd buy the lean & mean one, but I need feature #1678. Everything I do is based on that." And so on. Feature creep is the result of inexorable and unrelenting pressure for them.

I'd say that the word processor should be modular and that the requested features should be sold as plug-ins. Then customer A gets his lean mean word processor with exactly the features he wants, and the same for customers B and C. This obviously isn't possible with a language however, so I'm inclined to say that this is a false analogy. Sean
Jul 22 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:
 But I very much believe that there is an ongoing need for systems
 languages, and I can't envision a functional systems language.  Such
 languages must allow mutable state.

There are many functional languages that allow to mutate state. I'm sure the functional lang crowd will suggest you many functional languages that may be fitting for your requirements if you ask in the rigth places (like the Lambda the Ultimate blog). Personally I may suggest this (with a lisp-like syntax, but it's not lisp), but I have not used it yet: http://www.bitc-lang.org/ Bye, bearophile
Jul 22 2008
parent Sean Kelly <sean invisibleduck.org> writes:
bearophile wrote:
 Sean Kelly:
 But I very much believe that there is an ongoing need for systems
 languages, and I can't envision a functional systems language.  Such
 languages must allow mutable state.

There are many functional languages that allow to mutate state. I'm sure the functional lang crowd will suggest you many functional languages that may be fitting for your requirements if you ask in the rigth places (like the Lambda the Ultimate blog). Personally I may suggest this (with a lisp-like syntax, but it's not lisp), but I have not used it yet: http://www.bitc-lang.org/

Interesting. Can't say I'm crazy about the lisp-like syntax if I had to use it for systems programming, but it certainly does what you claimed. And I know that even Erlang allows mutable state--it doesn't try to obscure IO in a functionally invariant wrapper, for example--but I've always felt that the functional syntax naturally lent itself to a particular style of programming which assumes invariance. That said, I do agree that integrating multiple languages for a single application is often undesirable because the interaction points between the languages are often complex and irritating to use. This is the obvious selling point for the .NET CLI approach, and is actually why I think they created it in the first place. Regarding Erlang's interaction with C / D in particular however, because Erlang is effectively actor-based, the interaction is fairly similar to all interprocess communication in Erlang. I think this lends to creating subsystems in C / D rather than tiny optimization points, but the approach is fairly workable overall. However, I will admit that I'd occasionally like to have in-process "plugin" functions to avoid the overhead of communicating with a separate process, so I do think one could argue that the D2 approach is a good one. It's just not an argument I've fully accepted quite yet. Sean
Jul 22 2008
prev sibling next sibling parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:

 Walter Bright wrote:
 Sean Kelly wrote:
 Walter Bright wrote:
 But, you said you didn't wish to mix functional and imperative 
 programming? I don't understand.

Not in the same language. One reason being the impact it will have on managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess.

I agree that diverse paradigm support can lead to a mess. On the other hand, to be a mainstream language I think one must support diverse paradigms because programmers are diverse. Additionally, nobody really knows yet which horse is the right one to back for multicore programming, but functional certainly is a favorite.

I agree. In fact, I'd bet that imperative applications will dwindle over time because such code inherently resists parallelization.

this is a logical fallacy. you haven't shown that all or most code will need paralellization. you'd need to show that for your point to stand.
 But I 
 very much believe that there is an ongoing need for systems languages, 
 and I can't envision a functional systems language.  Such languages must 
 allow mutable state.

...on today's architectures. if hardware transactional memory makes it things will change quite a bit.
 I disagree that using multiple languages for one project is a good idea, 
 unless one language is hosted by the other (like emacs/elisp). Trying to 
 get two languages produced by different vendors to consistently work 
 together across platforms and differing upgrade schedules can be a 
 prescription for a lot of extra work. Is learning two different 
 languages really easier than learning two different paradigms in the 
 same language?

It comes back to that semantic barrier I mentioned in my other post. With everything in a single language, I think in team programming it will be inevitable that imperative code will "bleed" into areas that are intended to be functional, purely as a result of the personal styles of the programmers involved.

yeah and that will be documented in pure vs. impure functions and in invariant vs. const/mutable data. this is great. d is not a convention-based language like c++.
 As for learning multiple languages... web development already involves a 
 ton of different protocols, technologies, and languages, so I think 
 there's precedent that this isn't a huge obstacle for most teams.  I 
 would personally rather have a set of specialized tools than one tool 
 which can do everything but isn't really ideal for anything.

that again is a logical fallacy. i like messing with cars. i have an amazing 18V drill that i use for a ton of stuff - screws, bolts, holes, adjustments, rust removal, you name it. does that mean i'm only trying to use that tool for everything? sure not. but that doesn't make it less loveable.
 Regarding the D mixed functional / imperative approach, another issue 
 I have with it is that it's exactly the reverse of the Erlang / C 
 model. While Erlang / C is functional for control structures and 
 imperative for optimization points, D looks like it will be imperative 
 for control and functional for optimization.  Plus, I really like the 
 concurrency model in Erlang.

A side note: Everyone complains about feature bloat in Microsoft Word. What the world needs is a lean, mean word processor. But the problem is, customer Bill says: "That's great, but I need feature #543. Not having it is a deal breaker for me." Customer Sue says: "I'd buy the lean & mean one, but I need feature #1678. Everything I do is based on that." And so on. Feature creep is the result of inexorable and unrelenting pressure for them.

I'd say that the word processor should be modular and that the requested features should be sold as plug-ins. Then customer A gets his lean mean word processor with exactly the features he wants, and the same for customers B and C. This obviously isn't possible with a language however, so I'm inclined to say that this is a false analogy.

i agree. let's drop this word parallel.
Jul 22 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
superdan wrote:
 Sean Kelly Wrote:
 
 Walter Bright wrote:
 Sean Kelly wrote:
 Walter Bright wrote:
 But, you said you didn't wish to mix functional and imperative 
 programming? I don't understand.

managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess.

hand, to be a mainstream language I think one must support diverse paradigms because programmers are diverse. Additionally, nobody really knows yet which horse is the right one to back for multicore programming, but functional certainly is a favorite.

over time because such code inherently resists parallelization.

this is a logical fallacy. you haven't shown that all or most code will need paralellization. you'd need to show that for your point to stand.

I wasn't making a logical argument, but rather stating an opinion. The current trend indicates that we're hit a wall with performance scaling in a single CPU, and yet the demand for increased software performance continues. I know that some tasks are difficult to execute in parallel, but if increased performance is desired then something has to give. Also, many client-facing applications are already somewhat parallel because they are event-driven. Games can throw AI in one or more threads, etc. They don't have to, but it's the best way to exploit current trends in hardware performance scaling.
 But I 
 very much believe that there is an ongoing need for systems languages, 
 and I can't envision a functional systems language.  Such languages must 
 allow mutable state.

...on today's architectures. if hardware transactional memory makes it things will change quite a bit.

Hardware transactional memory is awesome. I'm not too fond of purely software transactional memory though. The overhead tends to be too great in most instances
 I disagree that using multiple languages for one project is a good idea, 
 unless one language is hosted by the other (like emacs/elisp). Trying to 
 get two languages produced by different vendors to consistently work 
 together across platforms and differing upgrade schedules can be a 
 prescription for a lot of extra work. Is learning two different 
 languages really easier than learning two different paradigms in the 
 same language?

With everything in a single language, I think in team programming it will be inevitable that imperative code will "bleed" into areas that are intended to be functional, purely as a result of the personal styles of the programmers involved.

yeah and that will be documented in pure vs. impure functions and in invariant vs. const/mutable data. this is great. d is not a convention-based language like c++.

Yeah, but to cross these barriers casting is typically required. And I hate casting :-) But you're still right.
 As for learning multiple languages... web development already involves a 
 ton of different protocols, technologies, and languages, so I think 
 there's precedent that this isn't a huge obstacle for most teams.  I 
 would personally rather have a set of specialized tools than one tool 
 which can do everything but isn't really ideal for anything.

that again is a logical fallacy. i like messing with cars. i have an amazing 18V drill that i use for a ton of stuff - screws, bolts, holes, adjustments, rust removal, you name it. does that mean i'm only trying to use that tool for everything? sure not. but that doesn't make it less loveable.

I'd argue that you're still using the drill for things it was intended to do. After all, a drill is just a portable electric engine, really.
 Regarding the D mixed functional / imperative approach, another issue 
 I have with it is that it's exactly the reverse of the Erlang / C 
 model. While Erlang / C is functional for control structures and 
 imperative for optimization points, D looks like it will be imperative 
 for control and functional for optimization.  Plus, I really like the 
 concurrency model in Erlang.

What the world needs is a lean, mean word processor. But the problem is, customer Bill says: "That's great, but I need feature #543. Not having it is a deal breaker for me." Customer Sue says: "I'd buy the lean & mean one, but I need feature #1678. Everything I do is based on that." And so on. Feature creep is the result of inexorable and unrelenting pressure for them.

features should be sold as plug-ins. Then customer A gets his lean mean word processor with exactly the features he wants, and the same for customers B and C. This obviously isn't possible with a language however, so I'm inclined to say that this is a false analogy.

i agree. let's drop this word parallel.

Works for me. Sean
Jul 22 2008
parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:
 As for learning multiple languages... web development already involves a 
 ton of different protocols, technologies, and languages, so I think 
 there's precedent that this isn't a huge obstacle for most teams.  I 
 would personally rather have a set of specialized tools than one tool 
 which can do everything but isn't really ideal for anything.

that again is a logical fallacy. i like messing with cars. i have an amazing 18V drill that i use for a ton of stuff - screws, bolts, holes, adjustments, rust removal, you name it. does that mean i'm only trying to use that tool for everything? sure not. but that doesn't make it less loveable.

I'd argue that you're still using the drill for things it was intended to do. After all, a drill is just a portable electric engine, really.

which completes my point superbly. (what a wanker word.) is a screwdriver more specialized than a drill? most likely. is a drill still better? mine is :) then it's not all a zero sum game. there are tools that are not specialized and mightily useful. i know this has a counter-point to which i could bring a counter-counter-point and so on til we have to wear diapers again. to prevent all that let me say this: human ingenuity makes the difference between solutions to problems that seem a zero-sum game. i remember from the days i was designing chips: we had to design an adc and everybody knew the relative tradeoffs of making various transistor combo designs. yet one day this guy comes and fuck me but his idea was just better than everything else in all aspects! even my boss said "such ideas are in very short supply". to bring this back to d. i couldn't design an const/invariant system to save my life from the same cannibals who ate bjarne. the space looked like a zero sum shit to me. so when i saw what walter came up with, i was rightly surprised. same goes about some shit in phobos2. it's not just yet another library. it's a fucking cool one because it's better in a new and surprising way.
Jul 22 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 i couldn't design an const/invariant system to save my life
 from the same cannibals who ate bjarne. the space looked like a zero
 sum shit to me. so when i saw what walter came up with, i was rightly
 surprised. same goes about some shit in phobos2. it's not just yet
 another library. it's a fucking cool one because it's better in a new
 and surprising way.

I cannot claim credit for it. The const/invariant design was the result of literally hundreds of hours of work (and maybe a hundred gallons of coffee) by Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the community on why our earlier efforts got it wrong. The transitivity requirement originated with Andrei, if I recall correctly.
Jul 22 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 superdan wrote:
 i couldn't design an const/invariant system to save my life
 from the same cannibals who ate bjarne. the space looked like a zero
 sum shit to me. so when i saw what walter came up with, i was rightly
 surprised. same goes about some shit in phobos2. it's not just yet
 another library. it's a fucking cool one because it's better in a new
 and surprising way.

I cannot claim credit for it. The const/invariant design was the result of literally hundreds of hours of work (and maybe a hundred gallons of coffee) by Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the community on why our earlier efforts got it wrong. The transitivity requirement originated with Andrei, if I recall correctly.

The transitivity requirement pretty much single-handedly eliminates all of my issues with C++ const. Kudos to Andrei for suggesting it. Sean
Jul 22 2008
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:
 On Wed, Jul 23, 2008 at 8:27 AM, Brad Roberts <braddr puremagic.com> wrote:
 On Tue, 22 Jul 2008, Walter Bright wrote:

 superdan wrote:
 i couldn't design an const/invariant system to save my life
 from the same cannibals who ate bjarne. the space looked like a zero
 sum shit to me. so when i saw what walter came up with, i was rightly
 surprised. same goes about some shit in phobos2. it's not just yet
 another library. it's a fucking cool one because it's better in a new
 and surprising way.

literally hundreds of hours of work (and maybe a hundred gallons of coffee) by Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the community on why our earlier efforts got it wrong. The transitivity requirement originated with Andrei, if I recall correctly.

discussions with you prior to joining the group discussions. It's my primary angst with c++ const.

By that do you mean something that's caused you actual trouble in C++ projects? Or just something that keeps you awake at night worrying about the trouble it could cause? My feeling is that C++ const does a decent job in practice of preventing programmers from doing stupid things. On the other hand, if you're trying to go out of your way to be stupid... that's another matter. But for the most part, while it may be easy to circumvent const, it's not so easy to circumvent it accidentally. Useless for making compiler optimizations, yes, but fine for documenting the intent of code.

I think one salient difference between C++ and D related to this is that objects are reference-based in D and thus would be mutable by default given the C++ const rules. One could argue that the compiler could apply the const-ness of the containing object to object members, but good sense would dictate that const-ness should apply identically to all reference-based members rather than making object members a special case. And at that point you've got transitive const :-) Sean
Jul 22 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 On Tue, 22 Jul 2008, Walter Bright wrote:
 The transitivity requirement originated with Andrei, if I recall correctly.

Quite possibly it was both of us, but I know I brought it up in discussions with you prior to joining the group discussions. It's my primary angst with c++ const.

That's entirely possible, and I apologize for the gaps in my memory.
Jul 22 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Brad Roberts wrote:
 On Tue, 22 Jul 2008, Walter Bright wrote:
 The transitivity requirement originated with Andrei, if I recall 
 correctly.

Quite possibly it was both of us, but I know I brought it up in discussions with you prior to joining the group discussions. It's my primary angst with c++ const.

That's entirely possible, and I apologize for the gaps in my memory.

There's that alzheimers coming on :) -Steve
Jul 23 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 By that do you mean something that's caused you actual trouble in C++
 projects?  Or just something that keeps you awake at night worrying
 about the trouble it could cause?  My feeling is that C++ const does a
 decent job in practice of preventing programmers from doing stupid
 things.  On the other hand, if you're trying to go out of your way to
 be stupid... that's another matter.  But for the most part, while it
 may be easy to circumvent const, it's not so easy to circumvent it
 accidentally.  Useless for making compiler optimizations, yes, but
 fine for documenting the intent of code.

It isn't that unusual for C++ programmers to rely on having a const pointer to mutable data (I know this because they tell me that their design breaks with D). C++ has no self-documenting method to distinguish transitive const from non-transitive const, yet both are used in real code. C++ const has also turned out to be of no value for writing multithreaded code. C++ const was fine for the 90's, but those days are over. C++0x has not addressed this issue, as the C++ community has not yet recognized the problem (many individual top C++ programmers do recognize it, but I've gotten the impression they see it as unimportant or hope it will just go away). I expect that it will become glaringly obvious over the next few years. The coming multicore revolution is going to cause big problems and the proposed C++0x threading model isn't going to fix it.
Jul 22 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Yep.  Thanks for sharing your experience.  I'm a researcher, so while 
 I've been at this for coding thing for 20 years too, I don't tend to 
 play around with a lot of million-line code bases written by 
 million-monkey junior programmers.  I did do a short stint for a big, 
 well-known software company once, and got my taste of million-monkey 
 code, though.  Scary stuff.  They wanted me to modify some crufty parser 
 to do some new tricks when there were absolutely no unit tests or 
 example programs or even documentation to show me what it was supposed 
 to be doing in the first place.  I'm amazed now that they didn't tell me 
 to "figure out this mess and document it first, writes some unit tests, 
 then add feature X" but instead they just wanted me to jump right in and 
 throw more gasoline into the fire.  Yikes.

Microsoft once asked me why I didn't update the MFC library that comes with DMC++. I said the problem was that MFC is a large complex system with not a single test case for it (at least one that is available to me). The existing one was tested heavily by others, and I know it works. If I recompile a new version, I have NO idea whether it compiled correctly or not. It took about a year to squeeze all the bugs out of the existing one. STLport is different, because that comes with a test suite. I can recompile it, run the test suite, and I know it works.
Jul 22 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 Yep.  Thanks for sharing your experience.  I'm a researcher, so while 
 I've been at this for coding thing for 20 years too, I don't tend to 
 play around with a lot of million-line code bases written by 
 million-monkey junior programmers.  I did do a short stint for a big, 
 well-known software company once, and got my taste of million-monkey 
 code, though.  Scary stuff.  They wanted me to modify some crufty 
 parser to do some new tricks when there were absolutely no unit tests 
 or example programs or even documentation to show me what it was 
 supposed to be doing in the first place.  I'm amazed now that they 
 didn't tell me to "figure out this mess and document it first, writes 
 some unit tests, then add feature X" but instead they just wanted me 
 to jump right in and throw more gasoline into the fire.  Yikes.

Microsoft once asked me why I didn't update the MFC library that comes with DMC++. I said the problem was that MFC is a large complex system with not a single test case for it (at least one that is available to me). The existing one was tested heavily by others, and I know it works. If I recompile a new version, I have NO idea whether it compiled correctly or not. It took about a year to squeeze all the bugs out of the existing one. STLport is different, because that comes with a test suite. I can recompile it, run the test suite, and I know it works.

To be fair, you know the features that the test cover work :-) But the point remains. With this in mind, why does contract checking still not support inheritance as described in the spec? Contracts are one feature that originally drew me to D and it's a shame that they're only half implemented. Sean
Jul 22 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 To be fair, you know the features that the test cover work :-)  But the 
 point remains.  With this in mind, why does contract checking still not 
 support inheritance as described in the spec?  Contracts are one feature 
 that originally drew me to D and it's a shame that they're only half 
 implemented.

Because the contracts haven't drawn the interest that the other features of D did that also needed work.
Jul 23 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 To be fair, you know the features that the test cover work :-)  But 
 the point remains.  With this in mind, why does contract checking 
 still not support inheritance as described in the spec?  Contracts are 
 one feature that originally drew me to D and it's a shame that they're 
 only half implemented.

Because the contracts haven't drawn the interest that the other features of D did that also needed work.

Seems I'm always in the minority :-) Sean
Jul 23 2008
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-07-24 07:43:55 +0200, Sean Kelly <sean invisibleduck.org> said:

 Walter Bright wrote:
 Sean Kelly wrote:
 To be fair, you know the features that the test cover work :-)  But the 
 point remains.  With this in mind, why does contract checking still not 
 support inheritance as described in the spec?  Contracts are one 
 feature that originally drew me to D and it's a shame that they're only 
 half implemented.

Because the contracts haven't drawn the interest that the other features of D did that also needed work.

Seems I'm always in the minority :-) Sean

For what is worth, I also like contracts :) Fawzi
Jul 23 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Simen Kjaeraas wrote:

 Fawzi Mohamed <fmohamed mac.com> wrote:
 
 On 2008-07-24 07:43:55 +0200, Sean Kelly <sean invisibleduck.org> said:

 Walter Bright wrote:
 Sean Kelly wrote:
 To be fair, you know the features that the test cover work :-)  But
 the point remains.  With this in mind, why does contract checking
 still not support inheritance as described in the spec?  Contracts
 are one feature that originally drew me to D and it's a shame that
 they're only half implemented.

features of D did that also needed work.

Sean

For what is worth, I also like contracts :) Fawzi

Thirded. -- Simen

Fourthed. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 24 2008
parent superdan <super dan.org> writes:
Lars Ivar Igesund Wrote:

 Simen Kjaeraas wrote:
 
 Fawzi Mohamed <fmohamed mac.com> wrote:
 
 On 2008-07-24 07:43:55 +0200, Sean Kelly <sean invisibleduck.org> said:

 Walter Bright wrote:
 Sean Kelly wrote:
 To be fair, you know the features that the test cover work :-)  But
 the point remains.  With this in mind, why does contract checking
 still not support inheritance as described in the spec?  Contracts
 are one feature that originally drew me to D and it's a shame that
 they're only half implemented.

features of D did that also needed work.

Sean

For what is worth, I also like contracts :) Fawzi

Thirded. -- Simen

Fourthed.

contracts are like gym memberships. most people agree they're good. many actively want them. few actually use them. i wasted a couple of hours of my miserable life reading "design by contract, explained". what a heap of shit that book is. the moron defines a stack. not even generic. a stack holding int. by the time he was done adding contracts to it, the poor stack looked like an old hooker after a gangbang. that being said, shit walter. didn't they teach you in school you either do shit well or not at all. either dump contracts or make them specifiable in interfaces. if that were the case by holy guacamole i'd use them. interfaces with contracts are about the only sensible, palatable use of contracts. why? because the only interesting shit happens when contract is separated from body. you specify some shit in a contract then force someone *else* to abide from it. contracts with body are a bit like writing a promise to yourself. (save for inheritance but i bored myself talking already.)
Jul 24 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly and others:
 For what is worth, I also like contracts :)

I too like them. At the moment in D I expecially like class contracts used as invariants. So I'd like to see the compiler manage contracts in a smarter way. Bye, bearophile
Jul 24 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 yeah and that will be documented in pure vs. impure functions and in
 invariant vs. const/mutable data. this is great. d is not a
 convention-based language like c++.

That is a point worth emphasizing. There are two phases to learning C++: 1. learn the language 2. learn the myriad of conventions that have built up over the years to ward off all the trouble (Scott Meyer's "Effective C++" series is an example) D tries to codify a lot of those conventions into the language, so the language can actually help you get it right. The const/invariant/pure is a huge step in that direction. My understanding is that much of peoples' difficulties with D's const system are the compiler catching attempts to subvert the const system. These are possible in C++ because const is a convention, but on the other hand people have terrible problems getting their multithreaded code to work properly in C++. Just look at all Herb Sutter's and Scott Meyer's articles on multithreaded C++ programming where code that looks like it should work and does compile and work most of the time, but is fundamentally broken. Language enforcement and guarantees are desperately needed.
 i like messing with cars. i have an
 amazing 18V drill that i use for a ton of stuff - screws, bolts,
 holes, adjustments, rust removal, you name it. does that mean i'm
 only trying to use that tool for everything? sure not. but that
 doesn't make it less loveable.

Me, I've never discovered a problem with my car that couldn't be solved with a hammer and a torch.
Jul 22 2008
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,


 Me, I've never discovered a problem with my car that couldn't be
 solved with a hammer and a torch.
 

if you have good insurance, you never will /j OTOH: Duct tape and WD-40: if it moves and it shouldn't, use the duct tape, if it should move and doesn't, use the WD-40.
Jul 22 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
BCS wrote:
 Reply to Walter,
 
 
 Me, I've never discovered a problem with my car that couldn't be
 solved with a hammer and a torch.

if you have good insurance, you never will /j OTOH: Duct tape and WD-40: if it moves and it shouldn't, use the duct tape, if it should move and doesn't, use the WD-40.

Strangely enough, duct tape is great except in instances where heat is involved... such as with heating ducts. Makes one wonder where the name came from :-) Sean
Jul 22 2008
parent BCS <ao pathlink.com> writes:
Reply to Sean,

 BCS wrote:
 
 Reply to Walter,
 
 Me, I've never discovered a problem with my car that couldn't be
 solved with a hammer and a torch.
 

OTOH: Duct tape and WD-40: if it moves and it shouldn't, use the duct tape, if it should move and doesn't, use the WD-40.

involved... such as with heating ducts. Makes one wonder where the name came from :-) Sean

IIRC duct cloth
Jul 22 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Sean Kelly wrote:
<snip>
 A side note: Everyone complains about feature bloat in Microsoft Word.
 What the world needs is a lean, mean word processor. But the problem
 is, customer Bill says: "That's great, but I need feature #543. Not
 having it is a deal breaker for me." Customer Sue says: "I'd buy the
 lean & mean one, but I need feature #1678. Everything I do is based on
 that." And so on. Feature creep is the result of inexorable and
 unrelenting pressure for them.

I'd say that the word processor should be modular and that the requested features should be sold as plug-ins. Then customer A gets his lean mean word processor with exactly the features he wants, and the same for customers B and C. This obviously isn't possible with a language however, so I'm inclined to say that this is a false analogy. Sean

I agree with most everything you wrote. specifically, "I would personally rather have a set of specialized tools than one tool which can do everything but isn't really ideal for anything." makes a lot of sense to me. however, I just want to point out that modular languages are possible. depending on what level of modularity you want. 1) common run-time for several languages like .net and JVM. 2) language oriented programming where you define a DSL for your problem domain and use that to solve the problem. so your project is constructed from several DSLs definitions and code written in those DSLs. look for MPS by Jetbrains for an implementation of such a system. 3) the language itself can be modular - you can either allow the programmer to define functions as new operators in the language (Scala does that). so downs for instance could use such a feature to implement his functional code without all the mixin/templates magic required by D. Or even more powerful: language extensions via AST macros, *including* syntax extensions defined by the user. see: http://nemerle.org/Syntax_extensions for a language that allows the programmer to add new syntax to the language (thus a modular language)
Jul 23 2008
prev sibling next sibling parent reply superdan <super dan.org> writes:
Walter Bright Wrote:

 Sean Kelly wrote:
 Walter Bright wrote:
 But, you said you didn't wish to mix functional and imperative 
 programming? I don't understand.

Not in the same language. One reason being the impact it will have on managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess.

I agree that diverse paradigm support can lead to a mess.

that's like agreeing that ice cream consumption can lead to auto theft. what a heap of bullshit that is. correlation is not causation. if we go by any reasonable train of thought, we'd see that c++ being multiparadigm is an advantage not an issue. people have written articles and books about how cool that is. they haven't written articles and books about what is sinking c++: the fucking syntax (bjarne is ok at a high level but he can't design syntax to save his life from a tribe of fucking horny and hungry gay cannibals); the shittiest exception model in the history of humankind (statically specified but dynamically-checked... worst of all worlds... what the fuck were they thinking about? shit); useless namespaces (what a useless pile of pigshit that whole feature is... and they can't even blame it to C... it was designed from scratch!); the template subsystem that is too much heat and smoke for the light; and a fucking million minor wounds, starting with "class" vs. "struct" shit and ending with copying at the drop of a hat.
 On the other 
 hand, to be a mainstream language I think one must support diverse 
 paradigms because programmers are diverse. Additionally, nobody really 
 knows yet which horse is the right one to back for multicore 
 programming, but functional certainly is a favorite.

absolutely.
 I disagree that using multiple languages for one project is a good idea, 
 unless one language is hosted by the other (like emacs/elisp). Trying to 
 get two languages produced by different vendors to consistently work 
 together across platforms and differing upgrade schedules can be a 
 prescription for a lot of extra work. Is learning two different 
 languages really easier than learning two different paradigms in the 
 same language?

looks like you haven't used unix much. a large project, even when developed by competent programmers acting on their free will, will inevitably use at least a few dsls (make, shell) in addition to one or more mainstream languages. why? because it's the best way. a n00b shouts foul when seeing a 5000 lines makefile or shell config or whatever. but they forget that manages a project that's a thousand times larger.
 Regarding the D mixed functional / imperative approach, another issue I 
 have with it is that it's exactly the reverse of the Erlang / C model. 
 While Erlang / C is functional for control structures and imperative for 
 optimization points, D looks like it will be imperative for control and 
 functional for optimization.  Plus, I really like the concurrency model 
 in Erlang.

A side note: Everyone complains about feature bloat in Microsoft Word. What the world needs is a lean, mean word processor. But the problem is, customer Bill says: "That's great, but I need feature #543. Not having it is a deal breaker for me." Customer Sue says: "I'd buy the lean & mean one, but I need feature #1678. Everything I do is based on that." And so on. Feature creep is the result of inexorable and unrelenting pressure for them.

as can be seen on this newsgroup.
Jul 22 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
superdan wrote:
 Walter Bright Wrote:
 
 Sean Kelly wrote:
 Walter Bright wrote:
 But, you said you didn't wish to mix functional and imperative 
 programming? I don't understand.

managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess.


that's like agreeing that ice cream consumption can lead to auto theft. what a heap of bullshit that is. correlation is not causation. if we go by any reasonable train of thought, we'd see that c++ being multiparadigm is an advantage not an issue. people have written articles and books about how cool that is. they haven't written articles and books about what is sinking c++: the fucking syntax (bjarne is ok at a high level but he can't design syntax to save his life from a tribe of fucking horny and hungry gay cannibals); the shittiest exception model in the history of humankind (statically specified but dynamically-checked... worst of all worlds... what the fuck were they thinking about? shit); useless namespaces (what a useless pile of pigshit that whole feature is... and they can't even blame it to C... it was designed from scratch!); the template subsystem that is too much heat and smoke for the light; and a fucking million minor wounds, starting with "class" vs. "struct" shit and ending with copying at the drop of a hat.

Fair enough. D supports all the same paradigms as C++ and yet I wouldn't say that it tends to produce unmaintainable code, so I agree that a lot of it does really come down to syntax. But it can still be difficult to maintain a consistent API when part of the team wants to use structs and free functions, another part wants an object hierarchy, and yet another wants templates. Tango has run into this a bit because of the varying programming styles of the people involved as well as feedback from users (some want objects, some don't, etc). The result is still far better and more maintainable than C++, but I think some of the same issues exist. Sean
Jul 22 2008
parent superdan <super dan.org> writes:
Sean Kelly Wrote:

 superdan wrote:
 Walter Bright Wrote:
 
 Sean Kelly wrote:
 Walter Bright wrote:
 But, you said you didn't wish to mix functional and imperative 
 programming? I don't understand.

managing projects in D. C++, for example, supports a sufficiently diverse set of programming methodologies that large projects in it tend to be a mess.


that's like agreeing that ice cream consumption can lead to auto theft. what a heap of bullshit that is. correlation is not causation. if we go by any reasonable train of thought, we'd see that c++ being multiparadigm is an advantage not an issue. people have written articles and books about how cool that is. they haven't written articles and books about what is sinking c++: the fucking syntax (bjarne is ok at a high level but he can't design syntax to save his life from a tribe of fucking horny and hungry gay cannibals); the shittiest exception model in the history of humankind (statically specified but dynamically-checked... worst of all worlds... what the fuck were they thinking about? shit); useless namespaces (what a useless pile of pigshit that whole feature is... and they can't even blame it to C... it was designed from scratch!); the template subsystem that is too much heat and smoke for the light; and a fucking million minor wounds, starting with "class" vs. "struct" shit and ending with copying at the drop of a hat.

Fair enough. D supports all the same paradigms as C++ and yet I wouldn't say that it tends to produce unmaintainable code, so I agree that a lot of it does really come down to syntax. But it can still be difficult to maintain a consistent API when part of the team wants to use structs and free functions, another part wants an object hierarchy, and yet another wants templates. Tango has run into this a bit because of the varying programming styles of the people involved as well as feedback from users (some want objects, some don't, etc). The result is still far better and more maintainable than C++, but I think some of the same issues exist.

agreed. lo and behold, there is agreement on the net. i must've died and made it to heaven.
Jul 22 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 Walter Bright Wrote:
 I agree that diverse paradigm support can lead to a mess.

that's like agreeing that ice cream consumption can lead to auto theft. what a heap of bullshit that is.

Sometimes having too many different ways of doing the same thing is a curse rather than a help. See my blog post on that at http://dobbscodetalk.com/index.php?option=com_myblog&show=Language-Features-for-Management.html&Itemid=29
 correlation is not causation. if we go by any reasonable train of
 thought, we'd see that c++ being multiparadigm is an advantage not an
 issue. people have written articles and books about how cool that is.

Oh, I agree, but it is also *can* be a problem. Like my Bronco, half the bolts in it are metric and the other half are standard. There doesn't even appear to be a discernible pattern as to which is which, I have to keep two tool sets at hand when working on it.
 they haven't written articles and books about what is sinking c++:
 the fucking syntax (bjarne is ok at a high level but he can't design
 syntax to save his life from a tribe of fucking horny and hungry gay
 cannibals); the shittiest exception model in the history of humankind
 (statically specified but dynamically-checked... worst of all
 worlds... what the fuck were they thinking about? shit);

I was around for the debates when exceptions were designed for C++. The reason for the mucked up design is that people at the time didn't know any better. That's not an aspersion on the C++ designers, but the fact was there wasn't much of any existing body of experience to draw upon. Nobody knew then what the right way to do it was. It's like the Wright Bros inventing wing warping. History has shown that wing warping is a crappy solution (ailerons work much better), but ailerons were a future invention, and the Wrights *did* find a solution to the problem of lateral control in a time when nobody else had a clue. There is no excuse, however, for the template < > syntax because it was well known at the time what the problems with it would be, and those predicted problems have plagued C++ ever since.
 looks like you haven't used unix much. a large project, even when
 developed by competent programmers acting on their free will, will
 inevitably use at least a few dsls (make, shell) in addition to one
 or more mainstream languages. why? because it's the best way. a n00b
 shouts foul when seeing a 5000 lines makefile or shell config or
 whatever. but they forget that manages a project that's a thousand
 times larger.

The 5000 line makefile isn't bound into the resulting app, either.
 A side note: Everyone complains about feature bloat in Microsoft
 Word. What the world needs is a lean, mean word processor. But the
 problem is, customer Bill says: "That's great, but I need feature
 #543. Not having it is a deal breaker for me." Customer Sue says:
 "I'd buy the lean & mean one, but I need feature #1678. Everything
 I do is based on that." And so on. Feature creep is the result of
 inexorable and unrelenting pressure for them.

as can be seen on this newsgroup.

Everyone has a different idea of what features should be put in D. There are proposals every day.
Jul 22 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 superdan wrote:
 Walter Bright Wrote:
 I agree that diverse paradigm support can lead to a mess.

that's like agreeing that ice cream consumption can lead to auto theft. what a heap of bullshit that is.

Sometimes having too many different ways of doing the same thing is a curse rather than a help. See my blog post on that at http://dobbscodetalk.com/index.php?option=com_myblog&show=Language-Features-for-Manag ment.html&Itemid=29

Indeed. And that's one thing I like about Java, although Java is an extreme case of such (as many people would agree, and even bash it because of that). -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 26 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Jul 23, 2008 at 9:35 AM, Brad Roberts <braddr puremagic.com> wrote:

 On Wed, 23 Jul 2008, Bill Baxter wrote:

 On Wed, Jul 23, 2008 at 8:27 AM, Brad Roberts <braddr puremagic.com>

 On Tue, 22 Jul 2008, Walter Bright wrote:

projects? Or just something that keeps you awake at night worrying about the trouble it could cause? My feeling is that C++ const does a decent job in practice of preventing programmers from doing stupid things. On the other hand, if you're trying to go out of your way to be stupid... that's another matter. But for the most part, while it may be easy to circumvent const, it's not so easy to circumvent it accidentally. Useless for making compiler optimizations, yes, but fine for documenting the intent of code. --bb

I mean has caused real trouble. I don't tend to make a lot of arguments based on theory. Primarily they're made from hard earned practice. C++ does not make it possible (possibly too strong a statement, substitute easy if you can think of a loophole) to take an existing object that is poorly implemented for const-correctness and make that a contained object in another class that wants to behave const correctly. It's way way too easy to make a mistake and have constness end without seeing it. Transitivity is what most more junior developers _expect_ from c++'s const system and it's not what they get. Secondarily, I _strongly_ value the benefit of const at the interface layer. That's even more important to me than the other half of constness. I love D's use of contracts and const (as well as in, out, and inout) playes a big role there. Yes, it's a matter of mismatched exepctations, and it is possible to use const correctly in c++, but to do so requires (like so much of c++) considerable care. To clarify, I've spent much of my 20 year career as both a maintenance programmer and as a new code developer (roughly 50/50). I tend to volunteer for the cleanup projects because no one else is willing to do it. A lot of that time has been in multi-million line code bases that have been evolved extremely rapidly and haphazardly. Yes it's the fault of the code as much as the language, but a language that gave better guarantees would have prevented problems and made ongoing maintenance easier by having a trustable const system. Make sense?

Yep. Thanks for sharing your experience. I'm a researcher, so while I've been at this for coding thing for 20 years too, I don't tend to play around with a lot of million-line code bases written by million-monkey junior programmers. I did do a short stint for a big, well-known software company once, and got my taste of million-monkey code, though. Scary stuff. They wanted me to modify some crufty parser to do some new tricks when there were absolutely no unit tests or example programs or even documentation to show me what it was supposed to be doing in the first place. I'm amazed now that they didn't tell me to "figure out this mess and document it first, writes some unit tests, then add feature X" but instead they just wanted me to jump right in and throw more gasoline into the fire. Yikes. --bb
Jul 22 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Jul 23, 2008 at 8:27 AM, Brad Roberts <braddr puremagic.com> wrote:
 On Tue, 22 Jul 2008, Walter Bright wrote:

 superdan wrote:
 i couldn't design an const/invariant system to save my life
 from the same cannibals who ate bjarne. the space looked like a zero
 sum shit to me. so when i saw what walter came up with, i was rightly
 surprised. same goes about some shit in phobos2. it's not just yet
 another library. it's a fucking cool one because it's better in a new
 and surprising way.

I cannot claim credit for it. The const/invariant design was the result of literally hundreds of hours of work (and maybe a hundred gallons of coffee) by Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the community on why our earlier efforts got it wrong. The transitivity requirement originated with Andrei, if I recall correctly.

Quite possibly it was both of us, but I know I brought it up in discussions with you prior to joining the group discussions. It's my primary angst with c++ const.

By that do you mean something that's caused you actual trouble in C++ projects? Or just something that keeps you awake at night worrying about the trouble it could cause? My feeling is that C++ const does a decent job in practice of preventing programmers from doing stupid things. On the other hand, if you're trying to go out of your way to be stupid... that's another matter. But for the most part, while it may be easy to circumvent const, it's not so easy to circumvent it accidentally. Useless for making compiler optimizations, yes, but fine for documenting the intent of code. --bb
Jul 22 2008
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On Wed, 23 Jul 2008, Bill Baxter wrote:

 On Wed, Jul 23, 2008 at 8:27 AM, Brad Roberts <braddr puremagic.com> wrote:
 On Tue, 22 Jul 2008, Walter Bright wrote:

 superdan wrote:
 i couldn't design an const/invariant system to save my life
 from the same cannibals who ate bjarne. the space looked like a zero
 sum shit to me. so when i saw what walter came up with, i was rightly
 surprised. same goes about some shit in phobos2. it's not just yet
 another library. it's a fucking cool one because it's better in a new
 and surprising way.

I cannot claim credit for it. The const/invariant design was the result of literally hundreds of hours of work (and maybe a hundred gallons of coffee) by Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the community on why our earlier efforts got it wrong. The transitivity requirement originated with Andrei, if I recall correctly.

Quite possibly it was both of us, but I know I brought it up in discussions with you prior to joining the group discussions. It's my primary angst with c++ const.

By that do you mean something that's caused you actual trouble in C++ projects? Or just something that keeps you awake at night worrying about the trouble it could cause? My feeling is that C++ const does a decent job in practice of preventing programmers from doing stupid things. On the other hand, if you're trying to go out of your way to be stupid... that's another matter. But for the most part, while it may be easy to circumvent const, it's not so easy to circumvent it accidentally. Useless for making compiler optimizations, yes, but fine for documenting the intent of code. --bb

I mean has caused real trouble. I don't tend to make a lot of arguments based on theory. Primarily they're made from hard earned practice. C++ does not make it possible (possibly too strong a statement, substitute easy if you can think of a loophole) to take an existing object that is poorly implemented for const-correctness and make that a contained object in another class that wants to behave const correctly. It's way way too easy to make a mistake and have constness end without seeing it. Transitivity is what most more junior developers _expect_ from c++'s const system and it's not what they get. Secondarily, I _strongly_ value the benefit of const at the interface layer. That's even more important to me than the other half of constness. I love D's use of contracts and const (as well as in, out, and inout) playes a big role there. Yes, it's a matter of mismatched exepctations, and it is possible to use const correctly in c++, but to do so requires (like so much of c++) considerable care. To clarify, I've spent much of my 20 year career as both a maintenance programmer and as a new code developer (roughly 50/50). I tend to volunteer for the cleanup projects because no one else is willing to do it. A lot of that time has been in multi-million line code bases that have been evolved extremely rapidly and haphazardly. Yes it's the fault of the code as much as the language, but a language that gave better guarantees would have prevented problems and made ongoing maintenance easier by having a trustable const system. Make sense? Later, Brad
Jul 22 2008
prev sibling parent "Davidson Corry" <davidsoncorry comcast.net> writes:
On Thu, 24 Jul 2008 06:59:05 -0700, superdan <super dan.org> wrote:

 Lars Ivar Igesund Wrote:

 Simen Kjaeraas wrote:

 Fawzi Mohamed <fmohamed mac.com> wrote:

 Sean Kelly <sean invisibleduck.org> said:

 Sean Kelly wrote:
 ...why does contract checking
 still not support inheritance as described in the spec?


 features of D did that also needed work.





Simen> Thirded. Lars Ivar> Fourthed. contracts are like gym memberships. most people agree they're good. many actively want them. few actually use them.

But we few rely on them utterly. And inheritance makes them much easier to use: if the author of an interface or base class has been careful to write good contracts, subclasses don't HAVE to write contracts, and they gain their benefits anyway. (Pretty much what you were saying, Superdan, ne?) I do sympathize with Atlas^H^H^H^H^HWalter carrying the weight of an entire new language on his shoulders, and he has to pick and choose what issues are important. But in my opinion, this is one. The biggest mistake most programmers make with contracts -- or simple asserts, for that matter -- is not to use them. -- Dai
Jul 25 2008
prev sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 24 Jul 2008 11:30:35 +0100, bearophile <bearophileHUGS lycos.com>  
wrote:

 Sean Kelly and others:
 For what is worth, I also like contracts :)

I too like them. At the moment in D I expecially like class contracts used as invariants. So I'd like to see the compiler manage contracts in a smarter way. Bye, bearophile

I don't normally approve of me tooing. It wastes bandwidth. But on the off chance it has any persuasive power at all. Me too. I use them extensively at work where I'm forced to use C++. They are documented using Doxygen and are used heavily to write the first set of unit tests. When fixing up legacy code one of the first things I look for are the pre-conditions the post-conditions and the invariants. These get documented. Then they get tested. This immediately picks up a lot of otherwise subtle and evil bugs. And the whole code base moves forward. They also help to expose when you have functions doing too much. If the post conditions become ridiculously complicated then its a fair bet the code has two and would benefit from some re-factoring. Maybe not a silver bullet but one of the more important tools in the arsenal. The pairing of contracts and unit tests was one of the first things that interested me in D. They deserve more attention. After all writing code is easy. Its writing clean correct code that takes more effort. Regards, Bruce.
Jul 24 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 I think part of the problem is that I simply don't agree with the mixed
 functional / imperative approach that appears to be the overarching
 direction of D.

No other language has tried such an approach before, and so we have yet to know unequivocably if it is right or not. But I'm very optimistic about it.
 And while I do quite a bit of concurrent programming,
 it's not in a way that will reap any benefit from this design.  In fact, the
 language features added to support it are more of an annoyance than
 they are an aid.  This may very well mean that D is simply not the
 language for me in the long term.  However, with C and C++ as the
 only real alternatives for systems programming, there aren't many
 other options available.

There are several different paradigms for concurrent programming. D won't be forcing one paradigm on anyone, it's sort of like oop vs free functions. They both work, and you can mix & match them as desired.
Jul 21 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 I think part of the problem is that I simply don't agree with the mixed
 functional / imperative approach that appears to be the overarching
 direction of D.

No other language has tried such an approach before, and so we have yet to know unequivocably if it is right or not. But I'm very optimistic about it.

I'm hopeful, just not optimistic :-)
 And while I do quite a bit of concurrent programming,
 it's not in a way that will reap any benefit from this design.  In 
 fact, the
 language features added to support it are more of an annoyance than
 they are an aid.  This may very well mean that D is simply not the
 language for me in the long term.  However, with C and C++ as the
 only real alternatives for systems programming, there aren't many
 other options available.

There are several different paradigms for concurrent programming. D won't be forcing one paradigm on anyone, it's sort of like oop vs free functions. They both work, and you can mix & match them as desired.

See my other post regarding managing projects in C++. Sean
Jul 21 2008
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-07-22 08:06:12 +0200, Sean Kelly <sean invisibleduck.org> said:

 Walter Bright wrote:
 Sean Kelly wrote:
 I think part of the problem is that I simply don't agree with the mixed
 functional / imperative approach that appears to be the overarching
 direction of D.

No other language has tried such an approach before, and so we have yet to know unequivocably if it is right or not. But I'm very optimistic about it.

I'm hopeful, just not optimistic :-)

There are other attempts at multi-paradigm programming languages, it is true that these are not system programming languages. Mozart/Oz http://www.mozart-oz.org/ is an interesting attempt, and the book by Van Roy and Haridi that uses it (Concepts, Techniques, and Models of Computer Programming) http://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262220695 is a very interesting read.
 And while I do quite a bit of concurrent programming,
 it's not in a way that will reap any benefit from this design.  In fact, the
 language features added to support it are more of an annoyance than
 they are an aid.  This may very well mean that D is simply not the
 language for me in the long term.  However, with C and C++ as the
 only real alternatives for systems programming, there aren't many
 other options available.



I tried to work in a mixed language approach (python/C) and my productivity went down, I even missed fortran! I think that when you have a fixed interface or a clear problem then it might be ok, but if you are developing in place where it is not so obvious where to cut things, and you switch implementation, and the "reference" implementation in the high level language is so unbearably slow that you cannot really use it even as test in the complex case, it becomes messy, and you loose a lot of time. I have only slightly brushed erlang, I didn't make any large scale projects with it, but I suspect the issues are similar. So I like very much the idea of a multi-paradigm language, if done well, and I like the idea of having a functional kernel in the language. Functional languages have to work harder to bring back some of the expression power, and the result is that they work very well when combining simpler building blocks, and are a real boon at high level, but I do not belive in "automatic" parallelization through it. Parallelization comes from the use of parallel constructs, and there are
 There are several different paradigms for concurrent programming. D 
 won't be forcing one paradigm on anyone, it's sort of like oop vs free 
 functions. They both work, and you can mix & match them as desired.

See my other post regarding managing projects in C++.

Yes having multiple paradigms can be a mess especially if the programming language is not clean and does not try to be as compact as possible and also know when to give up a little performance this is non obvious, but, I think, possible (I did large projects in C++, and I think the problem was not mutiparadigm per se, but how it is presented also due to legacy issues, and the unwillingness to make some clear choices). Also many of the things one might want can be very well implemented in libraries, and should be done like that. I have enough discipline to choose the right approach, I definitely want a language that support this, and it is one of the reasons I came to D, I think that with some work, it might support all that I want, which is templates, multithreading, so that I can set up my generic work distributing schemes, MPI if available, and Erlang actor model (which I think will become more and more important, and should be used when possible). Fawzi
Jul 22 2008
parent Fawzi Mohamed <fmohamed mac.com> writes:
rm

 Parallelization comes from the use of parallel constructs, and there are

just a bit of sentece that stayed there...
Jul 22 2008
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 And while I do quite a bit of concurrent programming,
 it's not in a way that will reap any benefit from this design.  In fact, the
 language features added to support it are more of an annoyance than
 they are an aid.  This may very well mean that D is simply not the
 language for me in the long term.  However, with C and C++ as the
 only real alternatives for systems programming, there aren't many
 other options available.

won't be forcing one paradigm on anyone, it's sort of like oop vs free functions. They both work, and you can mix & match them as desired.

I for one like the idea of a multiparadigm language. First of all, mixing languages is usually at least somewhat of a pain, so the desire to avoid this is understandable. At its lowest level(assembly language) all programming is basically imperative. A fundamental rule in designing just about any system is to avoid abstraction inversion, or the re-implementing of low-level concepts on top of high-level concepts. See http://en.wikipedia.org/wiki/Abstraction_inversion. This pretty much means, IMHO, that any properly designed programming language must have decent support for basic imperative programming. This leaves functional programming and OOP. I think we can all agree that some concepts (such as GUIs) are more naturally expressed in OOP and others (such as mathematical functions) are more naturally expressed in a functional paradigm. Therefore, a complete language should support both, and a complete programmer should be familiar with both.
Jul 22 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
dsimcha wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 And while I do quite a bit of concurrent programming,
 it's not in a way that will reap any benefit from this design.  In fact, the
 language features added to support it are more of an annoyance than
 they are an aid.  This may very well mean that D is simply not the
 language for me in the long term.  However, with C and C++ as the
 only real alternatives for systems programming, there aren't many
 other options available.

won't be forcing one paradigm on anyone, it's sort of like oop vs free functions. They both work, and you can mix & match them as desired.

I for one like the idea of a multiparadigm language. First of all, mixing languages is usually at least somewhat of a pain, so the desire to avoid this is understandable.

Agreed. For a while I was thinking I would do my work in Python for the high level with D for the low level. But debugging mixed-language projects like that is a pain. With Python basically you kill performance any time you stick in a loop over a large number of elements. So the granularity at which you start wanting to delegate to the fast language becomes very high. To me it seemed easier to just do things all in D in the end, and thereby never have to worry whether a loop was going to kill my performance.
 This leaves functional programming and OOP.  I think we can all agree that some
 concepts (such as GUIs) are more naturally expressed in OOP and others (such as
 mathematical functions) are more naturally expressed in a functional paradigm.

Well the IMGUI people might argue with you there. https://mollyrocket.com/forums/viewtopic.php?t=134&sid=fbeef82ffb9f71fe6637a7f499903841
 Therefore, a complete language should support both, and a complete programmer
 should be familiar with both.

But I agree with you anyway. Lisp advocates, on the other hand, would probably say here that you can do OOP in Lisp (and they'd probably add that it is 10x better than the OOP in C++ for some reason or other, and that they had the problem solved in the 70's before anyone even had a word for it.) --bb
Jul 22 2008
prev sibling parent reply maelp <mael.primet gmail.com> writes:
Sean Kelly wrote:
 I think part of the problem is that I simply don't agree with the mixed
 functional / imperative approach that appears to be the overarching
 direction of D.

Walter Bright replied:
 No other language has tried such an approach before, and so we have yet 
 to know unequivocably if it is right or not. But I'm very optimistic 
 about it.

Ever heard of Objective Caml? Not to be mean, but I guess it was there (and mixing functional, oop and imperative) first. Basically, I'd said functional programming in OCaml is *very* elegant and powerful, their use of functional instructions is a bit clumsy, and their oop is mostly unusable (mainly because they constantly "patch" their programming languages with new features, basically, each time there's a PhD student trying to work on functionnal programming .. ) Try to have a look at their way of mixing all this, if you haven't done that yet.. ?
Jul 22 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
maelp wrote:
 Sean Kelly wrote:
 I think part of the problem is that I simply don't agree with the mixed
 functional / imperative approach that appears to be the overarching
 direction of D.

Walter Bright replied:
 No other language has tried such an approach before, and so we have yet 
 to know unequivocably if it is right or not. But I'm very optimistic 
 about it.

Ever heard of Objective Caml? Not to be mean, but I guess it was there (and mixing functional, oop and imperative) first. Basically, I'd said functional programming in OCaml is *very* elegant and powerful, their use of functional instructions is a bit clumsy, and their oop is mostly unusable (mainly because they constantly "patch" their programming languages with new features, basically, each time there's a PhD student trying to work on functionnal programming .. ) Try to have a look at their way of mixing all this, if you haven't done that yet.. ?

That's not the same approach at all. It's more like the opposite approach -- grafting a procedural sublanguage on top of a functional language rather than what D is doing, putting a functional subset atop a procedural base. I believe Walter's premise is that most of the time people are more comfortable working in a procedural/oo style. But for certain tasks a functional approach is better. I agree. I tried to use OCaml. It sounds great on paper, and I had heard Chris Hecker singing its praises once, but like you said "their oop is mostly unusable". I figured it might eventually make sense and not seem so clumsy if I spent enough time with it, but then there was D sitting there saying "halloo! no troubles with my oo or procedural style here! You can get going right away with no steep learning curve!" So I went with D in the end. But I seriously had decided at one point that I was going to make OCaml my C++ replacer. And then I sat down to see how I would write a simple model viewer or something and was just stuck for days trying to figure out how to begin to get anything up on the screen. And the library situation didn't seem to be particularly good either, at least for Windows IIRC. So basically, I think D's approach is quite different from OCaml's, and more likely to succeed. --bb
Jul 22 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
maelp wrote:
 Sean Kelly wrote:
 I think part of the problem is that I simply don't agree with the
 mixed functional / imperative approach that appears to be the
 overarching direction of D.

Walter Bright replied:
 No other language has tried such an approach before, and so we have
 yet to know unequivocably if it is right or not. But I'm very
 optimistic about it.

Ever heard of Objective Caml?

Yes, but I know nothing about it.
 Not to be mean, but I guess it was there (and mixing functional, oop
 and imperative) first. Basically, I'd said functional programming in
 OCaml is *very* elegant and powerful, their use of functional
 instructions is a bit clumsy, and their oop is mostly unusable
 (mainly because they constantly "patch" their programming languages
 with new  features, basically, each time there's a PhD student trying
 to work on functionnal programming .. )
 
 Try to have a look at their way of mixing all this, if you haven't
 done that yet.. ?
 

Jul 22 2008
prev sibling parent maelp <mael.primet gmail.com> writes:
maelp Wrote:
 their use of functional instructions is a bit clumsy

I meant of course, "use of imperative instructions"
Jul 23 2008
prev sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Tue, 22 Jul 2008, Walter Bright wrote:

 superdan wrote:
 i couldn't design an const/invariant system to save my life
 from the same cannibals who ate bjarne. the space looked like a zero
 sum shit to me. so when i saw what walter came up with, i was rightly
 surprised. same goes about some shit in phobos2. it's not just yet
 another library. it's a fucking cool one because it's better in a new
 and surprising way.

I cannot claim credit for it. The const/invariant design was the result of literally hundreds of hours of work (and maybe a hundred gallons of coffee) by Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the community on why our earlier efforts got it wrong. The transitivity requirement originated with Andrei, if I recall correctly.

Quite possibly it was both of us, but I know I brought it up in discussions with you prior to joining the group discussions. It's my primary angst with c++ const. Later, Brad
Jul 22 2008
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Fawzi Mohamed <fmohamed mac.com> wrote:

 On 2008-07-24 07:43:55 +0200, Sean Kelly <sean invisibleduck.org> said:

 Walter Bright wrote:
 Sean Kelly wrote:
 To be fair, you know the features that the test cover work :-)  But  
 the point remains.  With this in mind, why does contract checking  
 still not support inheritance as described in the spec?  Contracts  
 are one feature that originally drew me to D and it's a shame that  
 they're only half implemented.

features of D did that also needed work.

Sean

For what is worth, I also like contracts :) Fawzi

Thirded. -- Simen
Jul 24 2008
prev sibling next sibling parent reply superdan <super dan.org> writes:
 == Quote from bearophile (bearophileHUGS lycos.co)'s article
 4tuu4k002 sneakemail.com:
 This is the monthly status for the unofficial d wish list:

It's curious to see that many or most of the top desired things don't seem among the list of the next things

unimportant things? Are the D designers smarter? Are the two groups ignoring each other? For better or worse, I don't personally feel that the D designers listen to the D community at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's just that my goals with D simply diverged beginning with 2.0.


theory come from. walter never did anything to put his integrity into question. I was bothered by the fact that some issues that many people consider bugs in D 1.0 are only being fixed in D 2.0, and I ignored my better judgement and shot my mouth off. It was a mistake.

u r a good man sean and this proves it again.
 now wuts with this walter doesn't listen shit. whining baby. i'm sayin':
walter does listen and does do great shit, the

the next. No offense, but um... speak for yourself. There are quite a few people here who are very talented and whose comments are not only consistent, but very well considered and quite well reasoned.

of course my statement needs qualification. u, steve, janice, bill, bearophile, dee and few others know their shit. and best of all they know what they don't know. but for majority of the rest, i'll take a fucking break. look at the reply from "me here". absofuckinglutely typical: overconfident, boastful, knows what's best for the fucking humankind better than fucking superman and fucking spiderman combined with batman thrown in as a freebie. the dood knows a little shit which only makes matters worse because that makes him think he knows everything. as far as that dood is concerned he has taken care of threading. in his world everything is trivially parallelizable. fuck. if half of what dood says is true, the fellas racking their brains at http://view.eecs.berkeley.edu/wiki/Main_Page and all over the fucking universe could go home. and that dood could go collect his fucking turing award. as an aside. he says functional is lame. but then i mean look at fucking haskell. it is designed to only have one user, and that with a thick manual by his side, to participate in obfuscated programming contests. yet wherever i turn nowadays, everybody and their fucking bellydancer with transparent stilettos is using haskell. why? well because threading shit has hit the fan and haskell is a handkerchief. and don't get me started on fucking erlang. look at its strings. lists with fucking 16 bytes per character. not even utf compatible. fuck. those guys thought there's not much use for strings in a fucking telephone relay haven't they. yet, fuck me but amazon uses fucking erlang. now d is poised better coz it is imperative and functional so u use what is best for each part of the app. of course that dood royally misses all that point.
 But Walter has said himself that he has difficulty working with people in
 other than a face to face setting and it shows.  Back when Andrei was still
posting here
 someone asked what one should do to have a proposal considered or at least
garner a
 response and the process was laid out very clearly.  Since then, quite a few
people have
 followed that process exactly and I can't remember any of the proposals
getting a comment
 from either Walter or Andrei.

now what the fuck is that dood's problem. somebody tell him swallow his fucking russian pride and haul his ass over here. but then what's he gonna do. argue shit with "me here" and other "doods here". contrary 2 u i think this is a problem, not a good thing: every single mofo here has 1 opinion and feels entitled to a response. but if walter takes time to explain every mofo why they're wrong, that's a fucking full time job right there. there is no filtering of value. and i dunno what the fuck is with this group. the less they know the more they think they know and the more entitled they come. like coz they're stupid they paid a tax to use d or shit.
  If a tree falls in the forest and there's no one around to hear
 it, does it make a sound?  And if a proposal is posted and it doesn't get a
single response,
 has anyone read it?  I know it's difficult to keep up with the posts in this
NG and impossible
 to actually act on all of them, but even a "thanks" goes an incredibly long
way in terms of
 making people feel like their comments matter.

wonder if "thanks 4 nothing, mofo" would qualify. coz that's closer 2 truth for most so-called proposals.
look at that list. it's a pile of shit with the most prefuckingposterous
requests in the fucking history of fucking

better and nicer and didn't need language changes. std.algorithm does vectorization? I had no idea. Don's BLADE (?) package does though and it's totally awesome and also didn't require language changes, so the point is still valid.
 When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what

 So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.

It's an interesting question, and one I've been mulling over for a few years now. My understanding is that C++ was created as a very community-driven effort right from the start while D was designed based very much on what Walter thought would be good in a language. As a result, C++ ended up bogged down with a lot of legacy C baggage that the community insisted was necessary for them to adopt C++, while D could change tracks on the designer's whim and no one could say otherwise. Generally, I think the D approach works far better so long as the designer's goals match the interests of the community, but it's a pretty risky path to follow since the designer is basically betting the farm on the hope that the community will agree with his vision. In the past I've been pretty free with my opinions about language features and I do this because I don't want to feel that I didn't try to make myself heard if I ever give up on D. At least then I can feel that I did my best to communicate to the designers what's important to me as a user of the language.


muggles there will be a committee over it like a cheap suit. I suggest reading "The Design and Evolution of C++" if you haven't already. It's pretty clear that Bjarne validated much of C++ by asking influential C users about its features.

yeah read it. good book. the bulk was bjarne's. the diff from d is that c++ got famous faster because every1 was ripe for it. nowadays market's tighter.
 so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real

listen. I've tried D2. I've read the spec as well. I simply don't like it. As for my suggestions, feel free to use the search feature in the digitalmars.com website, because many are here in this forum or D.announce. But you do have a point in that I have become quite weary of the D drama in general. I simply don't have the enthusiasm I used to, and that's entirely my own fault. This has been the longest I've ever worked on a personal programming project (at a guess, 4-5 years on Tango/Ares?) and I feel I've accomplished what I set out to do here, and that should be enough. I'll be better in the future about posting when I've had a bad day. My apologies.

better days will come that's 4 sure. thanx 4 sharing.
Jul 01 2008
parent superdan <super dan.org> writes:
superdan Wrote:

 of course my statement needs qualification. u, steve, janice, bill,
bearophile, dee and few others know their shit. 

meant to add don here 2, sorry. probably in the first slot 2.
Jul 01 2008
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Sean,

 Back when Andrei was still posting here
 someone asked what one should do to have a proposal considered or at
 least garner a
 response

<div class=joke> I remember a thread that, in jest, suggested that the best way to get a proposal into consideration involved... Beer. </div> on a slightly different topic: If Brad can't get enought people for 2 days of talks for the '08 confrence, maybe we should just go with a single day of talks and then 2 days of "chatting". If I can afford to, I'd love to hang around for that.
Jul 01 2008
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
superdan wrote:
 Sean Kelly Wrote:
 
 == Quote from bearophile (bearophileHUGS lycos.co)'s article
 4tuu4k002 sneakemail.com:
 This is the monthly status for the unofficial d wish list:

It's curious to see that many or most of the top desired things don't seem among the list of the next things

unimportant things? Are the D designers smarter? Are the two groups ignoring each other? For better or worse, I don't personally feel that the D designers listen to the D community at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's just that my goals with D simply diverged beginning with 2.0.

wut the heck is ur problem sean, u were the only sane guy left at tango. now u r coming with badmouthing n shit. recently u were like "walter is trying 2 lure people to d2. if that happens, i'm out." where the fuck did that conspiracy theory come from. walter never did anything to put his integrity into question. now wuts with this walter doesn't listen shit. whining baby. i'm sayin': walter does listen and does do great shit, the only problem is that most of us don't know what we're talking about and can't remember what we want from 1 moment 2 the next. look at that list. it's a pile of shit with the most prefuckingposterous requests in the fucking history of fucking programming languages. look at vectorization. who the fuck came with that sick idea. hell, std.algorithm does that shit better and nicer and didn't need language changes. the list is a joke. it's not even maintained, d has had tuples for months now. somehow we want progress, n new shit n all but no we want it in d1 backward compatible and with only two extra pieces of shit that vary from 1 person 2 the next and from 1 minute 2 the next. shit. if walter were 2 implement all the shitty "features" in the motherfucking list the language would become a fucking pile of dung the size of fucking china. what the fuck. walter is cranking great shit like it's goin' outta style and we throw a fit because we didn't think of it first. we only thought of shitty misfeatures like short syntax for new. now what was that mofo's problem. shit.

The list is definitely a farce. I think most everyone stopped paying attention to it long ago. I'm not sure why it still gets posted here. A cron job somewhere?
 When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what

 So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.



That's a great quote! I definitely think Walter believes he's working on the car. But Henry Ford also said: "Mark my words: A combination airplane and motorcar is coming. You may smile. But it will come." (http://en.wikiquote.org/wiki/Henry_Ford) That sounds to me like he was thinking "in our lifetime". Well it hasn't come yet, at least not in a way that I think would have satisfied Ford. It may be that Walter's working on that flying car. But I certainly don't claim to know which D will turn out to be -- the very useful car, or the pie-in-the-sky-never-to-really-pan-out combination airplane and motorcar. --bb
Jun 30 2008
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 01 Jul 2008 00:23:38 -0400, superdan wrote:

 
 wut the heck is ur problem sean ... now wuts with this walter doesn't listen
shit.
 whining baby.

ROTFLMAO!!! And who ever said that the English language is dying!? It's evolving so fast at times it's hard to keep up with. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 01 2008
parent novice2 <sorry noem.ail> writes:
Derek Parnell Wrote:

 And who ever said that the English language is dying!? It's evolving so
 fast at times it's hard to keep up with.
 

http://www.vumo.ru/humour/chan.php
Jul 01 2008
prev sibling parent "Anders Bergh" <anders1 gmail.com> writes:
On Wed, Jul 2, 2008 at 3:16 PM, Simen Kjaeraas <simen.kjaras gmail.com> wrote:
 Feel free to "fuckshit" all you want. Just don't expect people to take
 you seriously when you do.
 [...]
 -- Simen

http://enigma.dune.net/~eric/Do-not-feed-the-troll.PNG
Jul 02 2008
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Sean,

 == Quote from bearophile (bearophileHUGS lycos.co)'s article
 
 4tuu4k002 sneakemail.com:
 
 This is the monthly status for the unofficial d wish list:
 

It's curious to see that many or most of the top desired things don't seem among the list of the next things

means. Are people asking for unimportant things? Are the D designers smarter? Are the two groups ignoring each other? For better or worse, I don't personally feel that the D designers listen to the D community at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's just that my goals with D simply diverged beginning with 2.0.
 When I think about such matters I remember a quote, usually
 attributed to Henry Ford: "If I'd asked people what
 

 So maybe D programmers want faster horses, while D developers are
 inventing/providing cars :-) I don't know.
 

years now. My understanding is that C++ was created as a very community-driven effort right from the start while D was designed based very much on what Walter thought would be good in a language. As a result, C++ ended up bogged down with a lot of legacy C baggage that the community insisted was necessary for them to adopt C++, while D could change tracks on the designer's whim and no one could say otherwise. Generally, I think the D approach works far better so long as the designer's goals match the interests of the community, but it's a pretty risky path to follow since the designer is basically betting the farm on the hope that the community will agree with his vision. In the past I've been pretty free with my opinions about language features and I do this because I don't want to feel that I didn't try to make myself heard if I ever give up on D. At least then I can feel that I did my best to communicate to the designers what's important to me as a user of the language. Sean

Hi Sean, I agree with much of what you say. I have a few thoughts too (Dare I? :D). D design has actually moved into a tightly controlled group, apparently motivated by the authors desire to avoid the C++ committe process: there is no way to say this is a wrong approach (yet, it's a reactive one), although there is often an apparent lack of communication from the D designers to the community at large (However, some might argue that the core designers did try to participate here only to be "tarred and feathered" by the community). Whether this is better or worse (compared to C++) for the growth of the language is yet to be seen. I don't expect this anti-committee style to work any better in the long run than a pro-committee roadmap. But I could be wrong. Whether benevolent dictatorship, oligarchy, or design-by-committee, the problems related to language growth and design probably lie outside any one methodology (although there's likely a pinch of truth in the reasonings against certain methods). The problem doesn't lie in just the language design, but perhaps also in the organization and management of develpment -- as others have suggested repeatedly -- in additon to various judgement calls on what will most benefit the language's advancement in popularity. Should time be invested in pure language design or in updates to aging toolsets (eg let's ditch omf format and improve the win32 linker!), or in commitments to bug fixes? Naturally a community is going to be very desirous of quality working toolsets and simple installation. Meanwhile, a designer is going to be strongly tempted to "improve" language features. Does the community know best in this regard? This however is not the only problem: There a quasi effort from the designer(s) to show some magnanimity to alternative libraries (eg Tango) without any apparent commitment to what such support means for the future of D. The silence is deafening and tends to demotivate a community almost as fast as any pro-D article can pump up the language perception to the non-community public. This is a foggy spot for D's future before the eyes of the community. Is it really possible to promote a language based on two libraries with no evidence of interest, disinterest, or concern? This has been somewhat of a puzzle to me as I've watched the divergent efforts of the two libraries progress with ever more apparent impossible reconciliation. Why does this problem appear to continue to be ignored? Do the designers believe that "what will happen will happen", and therefore, "waiting and silence" is the only and inevitable solution? If so, it would at least be nice to have this stated plainly so all could understand the "why" of D's direction. Another problem is the original effort to make the language appear community driven; whether it is or not really isn't as important as being clear about intentions to the community. I think we would all agree that this language is not so community driven as we originally thought. Or, perhaps, it is better to say that it once was and now is not. Some significant elements are community driven: like gdc and Tango and various libraries. But these remain inextricably dependent on the D design timeline and bug fixes (as well as vexed by the same). And, even at that, Tango remains the most consistant community effort, while most other community efforts are prone to lag. Tango remains a solid example of a community-contributed process. This library was an attempt to turn D into a community project in direct response to a general Phobos' apathy (in terms of bug fixes and design progression). One way to look at this is to realize that Tango might not have been here if it weren't for Phobos' failure. On the other hand, perhaps we should consider what kind of library D would have engendered if Phobos had been more community driven from the start? From what I can see of Tango, it has amply proved itself: hosts of community contributions and testings with clear directions from a committed and talented core development team made Tango what it is today. I think Tango found the right balance of receptiveness vs controls for project management. (Tip of the hat to Kris, Lars, and Sean for managing to get it so far) And then there's Walter... Walter's D language design and compiler are examples of incredible contribution and effort via a different style... what appears to be an incredibly single-handed, brute-force operative method (with dogged determination!). If only such talents could merge to make a more organizationally sound process for D /and/ it's standard library. But in the end, the design of the language just becomes yet another ideological struggle of one's opinion over another's. It's inevitably, mutually political and sacred with or without a committee and is made more so as ideas collide from our varied experience and perceptions of what feels right. Walter's success with D is in largely due to his appeal to what we sense is wrong in other languages; he has managed to excite us via our dissatisfaction over past experiences (eg. Java and C++)... and that's a powerful form of influence. That is where the success of D has come whether or not we've agreed with his control structure along the way. The lead D designer has chosen his oligarchy to advance that design, and the community acts as the samplers of it; we are the measurement of potential language feature popularity and usability. And so the process continues with the next language that comes around. Indeed, the miracle is that such contributions can somehow merge at all and that people /remain/ loyal to it. But then... perhaps it's not so surprising after all. ;) -JJR
Jun 30 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Tue, 01 Jul 2008 21:58:31 +0400, Robert Fraser  
<fraserofthenight gmail.com> wrote:

 Me Here Wrote:
 Web servers and other IO-bound processes are *not* the target of
 multithreading.

How do functional programming styles apply better to I/O-bound systems? I couldn't imagine writing a query processor using monads for all I/O. Functional programming works well for a subset of applications which require concurrency. The question is: is this subset large enough to justify designing a language's concurrency support around this paradigm? Is it large enough to justify forcing additional language constructs (const) for applications that don't use this paradigm to handle their concurrency? For non-concurrent applications? Of course, there are other arguments for a const system (static checking of interfaces, etc.) But what other major new statically-typed languages (besides D) have such a system? Java mostly threw it out (there's final fields & what not). C-pound threw out even more of it. I ahve the same feelings towards const-as-interface as I do towards checked exceptions: sounds great on paper, but ends up wasting the developer's time. (apologies for the web interface; work)

No reason for apologies, it's hardly anyone would notice if you didn't stress that! And even so!
Jul 01 2008
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
superdan <super dan.org> wrote:

 Robert Fraser Wrote:

 superdan Wrote:
 in all likelihood i'm older than u but anyhow, since when was age a  

since u don't know none, u go with the age thing. got it.
 u don't like me killfile me. won't change my id.

He was trying to help you out by explaining that unless you're on an MMO or instant messenger, typing that way conveys certain assumptions. Your posts seem moderately intelligent in content, but it's difficult for many people here to take them seriously (i.e. as anything more than trolling) if you type that way. If your intent is to troll, then ignore/flame this post, but if your intent is to actually have a discussion consider reducing your use of swear words, using correct mechanics (i.e. punctuation and capitalization) and not using shortened forms of words. Otherwise, no one will see your posts as anything more than flamebait/junk, and the topics you wish to discuss will get lost.

ok will conform. what can i do? but if i can't fuckshit now and then i'm fucked. can't fuckshit at work. can't fuckshit at home. now i can't fuckshit on the internet? what's this world coming to?

Feel free to "fuckshit" all you want. Just don't expect people to take you seriously when you do.
 one more thing. could you please nicely with sugar on top explain what i  
 did to that bcs fella? thought i was trying to be nice to him.

"if u ever use wright instead of write i swear i will beat u with the heel of my shoe". I can't quite see how that's being nice. Of course, it might have been meant as a joke, but irony is easily lost in written media.
 Also, if your intent is to troll, search the archives for "Ty Tower,"  
 he was
 (a little) better at it.

never got his train of logic, if it ever left the station. that dood is due for some serious detox.

-- Simen
Jul 02 2008
parent BCS <ao pathlink.com> writes:
Reply to Simen,


 one more thing. could you please nicely with sugar on top explain
 what i  did to that bcs fella? thought i was trying to be nice to
 him.
 

heel of my shoe". I can't quite see how that's being nice. Of course, it might have been meant as a joke, but irony is easily lost in written media.

While I agree that that is an odd way of being nice, it's not that I was offended by what he said, I just decided that it isn't worth my time to read his post.
Jul 02 2008
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
 Walter Bright wrote:

 Yes, but the onus will be on you (the programmer) to prevent data races  
 and
 do proper synchronization.

In the scenario described, the main thread initialises the array of data. Then, non-overlapping slices of that are portioned out to N worker threads. Only one thread ever modifies any given segment. When the worker threads are complete, the 'results' are left in the original array available in its entirety only to the main thread.
 You have to be very wary of cache effects when
 writing data in one thread and expecting to see it in another.

Are you saying that there is some combination of OS and/or hardware L1/L2 caching that would allow one thread to read a memory location (previously) modified by another thread, and see 'old data'? Cos if you are, its a deeply serious bug that if its not already very well documented by the OS writer or hardware manufacturers, then here's your chance to get slashdotted (and diggited and redited etc. all concurrently) as the discoveerer of a fatel processor flaw.

I don't think that's exactly what he means. If I understand things correctly, if one thread is going to read something, that something might be put in cache /before/ the other thread writes its data there. So yes, it is previously written, at the time the read 'should' take place. -- Simen
Jul 03 2008
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Steven Schveighoffer <schveiguy yahoo.com> wrote:

 In fact, a pure member function would have tobe marked as:
  pure invariant void f();

While I agree a pure member function would also need to be invariant, it seems superfluous to have to write that in the function signature. It /has/ to be, so why should I need to specify it?
 As for how useful would an invariant (but not pure) function be?   
 Consider
 something like:

 class C
 {
    int x;
    invariant void printTo(stream s) { s.print(x); }
 }

Could this not just as easily have been done with a const function, as invariant is implicitly castable to const? -- Simen
Jul 23 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Wed, 23 Jul 2008 22:01:34 +0400, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 Steven Schveighoffer <schveiguy yahoo.com> wrote:

 In fact, a pure member function would have tobe marked as:
  pure invariant void f();

While I agree a pure member function would also need to be invariant, it seems superfluous to have to write that in the function signature. It /has/ to be, so why should I need to specify it?
 As for how useful would an invariant (but not pure) function be?   
 Consider
 something like:

 class C
 {
    int x;
    invariant void printTo(stream s) { s.print(x); }
 }

Could this not just as easily have been done with a const function, as invariant is implicitly castable to const? -- Simen

There might be a benefit, as it enforces stronger guaranties. Suppose that our class is large storage container and stream.print is a time-consuming process that may take signaficant amount of time. If an object is invariant then then there is a guarantee than its data won't be changed in another thread during function execution (at the very least). And given that, there is no need to synchronize data, otherwise it should be rewritten as synchronized: class C { Data data; synchronized const void printTo(stream s) { s.print(data); } invariant void printTo(stream s) { s.print(data); } // invariance } On Wed, 23 Jul 2008 04:35:16 +0400, Walter Bright <newshound1 digitalmars.com> wrote:
 5. Invariant data does not have to be synchronized to be multithread  
 accessible.

Jul 23 2008
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Jason House <jason.james.house gmail.com> wrote:

 Maybe an example will help:

 int a;
 int b;

 struct bar{
   void write(int x) invariant
   out{ assert(a==b); }
   body{
     a = x;
     b = x;
   }
 }

 The state of bar is never modified, but bar should not be used without
 synchronization.  The function's contract can be violated due to a race
 condition.  This may be an artificial example, but I hope it shows that  
 #5
 requires qualification.

You are expecting invariant member functions to not do things they can and should do. Perhaps this would be better shown with one of the proposed syntaxes for const/invariant member functions: struct bar { invariant(this) { void write(int x) {...} } } This is essentially what your example above does, and is expected to do. If it were to behave the way you seem to expect it to, it would look like this: struct bar { void write(int x) pure // int does not need to be marked invariant, // as it is passed by value. { } } This write method would of course be unable to do anything, as it returns void, and cannot change its parameters. The fact that invariant member functions require synchronization needs no debate, we all know that, and most of us expect it to be like that. The reason is that one might (for any good or bad reason) have an invariant 'bar' somewhere, and need to call its 'write' method. Seeing as this does not change the contents of 'bar', it should be a const or invariant function. If you want it to behave differently for const and invariant, there needs to be a separate function for the invariant case. The invariant object may have been created at run-time, and one might want to write it to file, and include information about its being const, mutable or invariant. This would be impossible if any and all member functions of an invariant object be required to be pure. Even if the const system was added to D only for functional programming, we might need to interface to those invariant objects in some way, and this is where invariant/const member functions come in. So, to sum it up: Invarant/const member functions exist so that one might do things with invariant/const objects, without using static functions. In nearly all cases, a const member function is what you want, but there might be some obscure reason to have an invariant member function, and I don't think D should deny you that. -- Simen
Jul 24 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Thu, 24 Jul 2008 17:14:01 +0400, Jason House  
<jason.james.house gmail.com> wrote:

 Simen Kjaeraas Wrote:
 You are expecting invariant member functions to not do things they can
 and should do.

My example was in response to Walter's statement (#5) that invariant objects can be accessed without synchronization. I was providing a simple counter example.

Yes, presicely:
 invariant objects can be accessed without synchronization.

By contrast, your example wasn't accessing invariant objects but rather executed invariant function. Don't compare soft with green. The data that was accessed wasn't invariant, it was mutable. However, if global x and y were invariant, that function would be thread-safe and woudn't require synchronization.
Jul 24 2008
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Jason House <jason.james.house gmail.com> wrote:

 Simen Kjaeraas Wrote:
 You are expecting invariant member functions to not do things they can
 and should do.

My example was in response to Walter's statement (#5) that invariant objects can be accessed without synchronization. I was providing a simple counter example.

Yes, but you still seem not to understand what an invariant function is, and why it should exist. An invariant object (read: invariant data) /can/ be accessed without syncing. An invariant method cannot. Invariant functions are not and should not be pure functions. The two are different kinds of beasts. One is functional programming, the other is not. -- Simen
Jul 24 2008
prev sibling parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
I created the wishlist to reduce the
high level of repeated postings of similar ideas,
and the community could help Walter single out the good ideas
via voting.


When new users joined the newsgroup they
had the tendency to suggest thing that have already been
discussed several times.

Also good ideas by experts which didn't have time to post much
had a tendency to drown in the "noise".

Of cause the wish list have several short comings.
Like no way to post comments and a admin which is busy with other things
e.t.c.

I had the hope that someone with time would write a good replacement.
(Like the forum used on http://labs.powerset.com/. Does anyone know
which software they use ?).

Walter have suggested that bugzilla is used for enhancement requests,
this is a very good idea, but as far as I can see it is not currently
possible to vote on the requests, or generate a list with the most voted
on enhancement requests, as the wishlist does.

Of cause I added a request for this to the wishlist
http://all-technology.com/eigenpolls/dwishlist/index.php?it=176
Jul 06 2008
next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Mon, 07 Jul 2008 00:13:05 +0400, Knud Soerensen  =

<4tuu4k002 sneakemail.com> wrote:

 I created the wishlist to reduce the
 high level of repeated postings of similar ideas,
 and the community could help Walter single out the good ideas
 via voting.


 When new users joined the newsgroup they
 had the tendency to suggest thing that have already been
 discussed several times.

 Also good ideas by experts which didn't have time to post much
 had a tendency to drown in the "noise".

 Of cause the wish list have several short comings.
 Like no way to post comments and a admin which is busy with other thin=

 e.t.c.

 I had the hope that someone with time would write a good replacement.
 (Like the forum used on http://labs.powerset.com/. Does anyone know
 which software they use ?).

 Walter have suggested that bugzilla is used for enhancement requests,
 this is a very good idea, but as far as I can see it is not currently
 possible to vote on the requests, or generate a list with the most vot=

 on enhancement requests, as the wishlist does.

 Of cause I added a request for this to the wishlist
 http://all-technology.com/eigenpolls/dwishlist/index.php?it=3D176

How about resetting wish-list votes once in a while or dropping votes th= at = are older than, say, a year? Other than that it is ok to have such poll. But its current contents should certainly be revised, since it makes = little sense to contribute to this list now that it doesn't reflect D = status anymore.
Jul 06 2008
prev sibling parent reply "Manfred_Nowak" <svv1999 hotmail.com> writes:
Knud Soerensen wrote:
 generate a list with the most voted on enhancement requests

I believe, that voting without supervision is a no-no in general and especially voting for ones own profit; even more no-no when the voting is anonymous. Voters put themselves into the shapes of beings of unlimited powers, disburdened from the need to obey to restricted resources. -manfred
Jul 07 2008
parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Manfred_Nowak wrote:
 Knud Soerensen wrote:
 generate a list with the most voted on enhancement requests

I believe, that voting without supervision is a no-no in general and especially voting for ones own profit; even more no-no when the voting is anonymous. Voters put themselves into the shapes of beings of unlimited powers, disburdened from the need to obey to restricted resources. -manfred

I believe, that newsgroup posting without supervision is a no-no in general and especially posting for ones own profit; even more no-no when the posting is anonymous. Posters put themselves into the shapes of beings of unlimited powers, disburdened from the need to obey to restricted resources. Are you using template based argumentation ?
Jul 07 2008