May 30, 2007
Jarrett Billingsley wrote:
> Walter also seems to be influenced by certain people more than others, which is more than a little disturbing. 

That's one reason why we'll be having the D conference in August. I'll be there, so will Andrei, and I think David, too. You'll be able to bend all our ears. I'm looking forward to it!
May 30, 2007
On Wed, 30 May 2007 15:09:48 -0700, Walter Bright wrote:

> You'll be able to bend all our ears. I'm looking forward to it!

You say that now ... <G>

Damn I wish I could be there.
-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
May 31, 2007
Sean Kelly wrote:
> [...]
> Personally, when writing libraries if I discover that feature X would really simplify things then I'll post an abstract argument on the topic. 
>  I think this is generally a better way to do things because it separates the discussion from any particular use case and allows the feature to be evaluated on its own terms.  That said, those posts have often gone completely unanswered so perhaps I'm going about it the wrong way.
> [...]

The problem with talking about features abstractly is that it's hard to judge how necessary or compelling the feature is without the context of real examples.  Motivating use cases give hints as to whether the feature will only be used in obscure code, whether the feature could be easily simulated with an alternative, or whether it's something that you could imagine lots of other people running into.  So even though academically, it is better to reason about things abstractly, compiler design is not an academic pursuit; it's an engineering one.  And engineers are better off seeing how a bridge sways in the wind or under the feet of pedestrians than modeling it and theorizing about its properties abstractly.  When they stick with the abstract, they are often surprised by the details of reality.

Dave
May 31, 2007
David B. Held wrote:
> 
> The problem with talking about features abstractly is that it's hard to judge how necessary or compelling the feature is without the context of real examples.  Motivating use cases give hints as to whether the feature will only be used in obscure code, whether the feature could be easily simulated with an alternative, or whether it's something that you could imagine lots of other people running into.  So even though academically, it is better to reason about things abstractly, compiler design is not an academic pursuit; it's an engineering one.  And engineers are better off seeing how a bridge sways in the wind or under the feet of pedestrians than modeling it and theorizing about its properties abstractly.  When they stick with the abstract, they are often surprised by the details of reality.

Bah.  The Tacoma Narrows Bridge was a fluke ;-)


Sean
May 31, 2007
"Derek Parnell" <derek@psych.ward> wrote in message news:w6lhuw2k8eeu$.1b5hdec4p7dxw$.dlg@40tude.net...
> On Wed, 30 May 2007 15:09:48 -0700, Walter Bright wrote:
>
>> You'll be able to bend all our ears. I'm looking forward to it!
>
> You say that now ... <G>
>
> Damn I wish I could be there.

And so do I :S


June 01, 2007
David B. Held wrote:
> What Andrei brings to the table, which might surprise you, is a solid practicality about features.  While D users typically ask for features that require significant amounts of work, Andrei first argues for features that would improve language consistency, which is building a better foundation for the future than just trying to get everything you want right away.  Another important point to make is that the so-called "Inner Circle" is often as concerned as the D community as a whole about many important features like reflection, macros, etc. 

I must contend against that. I would say most of D users (on the NG at least), myself included, argue about languages changes (some of them trivial to implement) to existing features, and not about new features.
If you check my D wiki page ( http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D ) you'll see I keep track of issues I have looked into and think should be changed one way or the other. All of them except two ("Copy Operator", "Ctors as regular functions") are trivial or easy changes to existing features, they are not new features. (I won't get started on what I think of AST macros)

>(and remember that 
> Walter is a part of the "Inner Circle").
>

Of course he is, he's the center of it! Duuh :P

> Bruno Medeiros wrote:
>> [...]
>> Nice post, I agree. However I also think that some language issues
>> cannot be trivially shown to Walter to be inadequate or suboptimal
>> (like the Andrei allocator example). In fact probably *most* language
>> design issues are like that (the allocator example wasn't even a
>> design issue, but rather an implementation one, right?), because their
>> effects, in terms of code productivity or cleanliness, despite being
>> considerable, are also subtle and amortized accross large amounts of
>> code and development time. This is especially true of small, but
>> important, details, and it makes it very hard, if not impossible, to
>> show hard examples of why something should be changed. Instead,
>> arguing is the only option left, but which often is inneffective
>> against Walter, especially to those outside the D "Inner Circle". :7
>
> I think if you have actual code where you can point to it and say: "In
> 34 places I write this bit of code which would be improved by feature
> X", and Walter says: "Overall, I think your code is cool and I want to
> help it along", you have as much chance as anybody to get your wish.
> Here's a real-life example: Andrei *really* hates having to write
> ..length for all his array references.  He would much rather have
> array.$ or something.  So he went through his code and found that he had
> to say array.length like 300+ times in a few thousand lines of code, and
> made the point that while this is a very minor feature, it impacts the
> readability of a lot of code.
>
> The main problem is that a lot of people make *abstract* arguments about
> the pros and cons of various features or lack thereof (with, perhaps a
> code snippet to illustrate the point).  That is what rarely gets any
> mileage.  On the other hand, when people build actual libraries and say:
> "Look, I spent a bunch of time building this awesome library, and I can
> tell you from first-hand experience that feature Y would really make my
> life easier", Walter looks at the library and goes "Eh" or "Man, that's
> a cool library, I really want to polish it up by providing features that
> will make it even better".  And I can tell you from direct observation
> that not only does this happen, but Andrei is not the majority
> beneficiary of such feature determinations.
>

Yes, but some people do not have the time or inclination to write large amounts of D code just to prove a point. And it really should not be necessary, as one's previous experience (with other languages or D itself) should be enough to extrapolate and make a valid argument about a given language issue.
Furthermore, some issues may be subtle or specific enough that building exemplifying code won't really help much than an argument.

Let me give you an example. One of my first "big" posts here in the NG was about entity/symbol visibility issues ("Entity naming revised" http://www.digitalmars.com/d/archives/digitalmars/D/28423.html). It discussed and argued for four separate(as in orthogonal) proposals. Two of them (FQN import, and private import by default) were accepted into D, but only *one year later*, when, Kris, the developer of Mango (a large D library), complain about it, referring actual annoyances in his Mango development experience.
Now, was my "abstract" argument not valid then just because I didn't have D code experience to back it up? I don't think so. I indeed did not have any D code experience on it, but I had experience on other medium-large code in other languages (both *having* and *not having* FQN import), from which I (and anyone else with a typical development experience) could clearly extrapolate that not having FQN import in D would suck.
(And on a side note, I think proposal 3 will also be placed into effect eventually, even if "only" at the IDE level)

Another example is the "Is Type Expression trickyness" issue (please read on it on my wiki page, it's just one paragraph). Now, I stumbled on that very bug (a typo) myself when writing a small experimental D template code. It took me a while to find the bug (about 5 minutes), whereas it would be instantly found if the Is-Type expression would not accept semantic errors. Now, how much D code would I have to write, and then stumble on that bug, to show to Walter that that aspect should change? Why isn't an argument that extrapolates from a singular experience enough?


> To be perfectly honest, what Walter does with his colleagues on a regular basis would probably be considered rather boring by most people: he sits down and hashes out the tedious minutiae of implementing a particular feature, no matter how small or insignificant it might be. Considering that each feature has the potential to impact lots of aspects of the language, this isn't the exciting "We're designing a rocket ship" aspect of PL design that perhaps many people think it is. It's slow, frustrating, and sometimes difficult work.  If you don't believe me, pick your favorite feature, and try to write up a document that describes how it interacts with every major part of the language.
> 
> This is what the community sees: "I want feature X, because it's cool!" 
>  This is what Walter sees: "That feature will take 40 hours of bickering, arguing and fist-fighting to get just a few people to agree on how it should be implemented and what it should mean in every possible context in which it could appear."  The fact of the matter is, most of the time is *not* spent picking and choosing features like the Illuminati deciding the fate of the world.  It is more like construction workers building a railroad.  Everyone points to the map and says where they want the railroad to go and says how glorious it would be if it got there, but only a few people are picking up hammers and blasting mountains and building bridges and doing the not-very-glamaorous work of just putting another mile on the track.
> 
> So when people bicker about not being in the "Inner Circle", I find it fairly amusing, because if they only knew what a bunch of drudge work it is, they would be much more grateful when a new feature magically pops out of the next version of dmd.  Anyone who wants to be a part of the "Inner Circle" effectively can be by A) writing a compelling library to motivate the need for certain features, or B) writing a compelling feature proposal with enough detail to actually implement it.  If you're wondering how much detail that is, browse the C++ proposals, and consider that probably 80% of them are not detailed enough to be fully useful to a compiler writer.

I also contend against that. First, not all changes require examining large "minutiae" to make them work, namely for minor changes to existing features where the greatest issue is not *how* the change should be made, but whether *should* the change be made or not. One example is the "Entity Naming Revised" post I mentioned above. It was a big post but the core of it was about *why* should the changed be made, and not *how*, since the changes and syntax themselves where very trivial.
Second, as for the big languages changes, yes, they do require thinking about all possible interactions and a lot of details, and sometimes people don't do that when arguing about features, but *I* actually do that (when actually arguing about it, at least). You mentioned writing a detailed proposal. That's quite a timing, since I actually did that recently, sparked by Andrei's intellectual challenges and increased involvement in NG interaction. It's about the frontline const/immutability issue
(http://www.digitalmars.com/d/archives/digitalmars/D/Extended_Type_Design._50225.html#N50476)
and it details what I believe is a complete, working and very near compiler-implementable const set of features. And more significantly, I must say the same cannot be said about Andrei/Walter's design, at least in what has been posted in the NG. For example, in their proposal, I still don't what is the typeof(fooptr) as in the code below:
  final foo;
  auto fooptr = &foo;
even though I asked 2 or 3 times now. And there also has not yet been any mention of how const/final/etc. will work in regards of template specialization (how to specialize on const, etc.). Do they even have a complete design? I don't know. Maybe it is just the case that they do, and have not posted all their new info in the NG (specially since Andrei is now away). In any case, my point is just to disprove your point :) . I.e., that people here (not just me) usually do think in detail about what they are proposing. (not like: HAI THAR GUYS, CAN I HAVE REFLEXION AND MACROS PLZ?? KTHXBYE!!1) :P

> 
> It's one thing to say: "It would be cool if my code could look like this", and quite another to say: "...and this is how we could get there."
> 
> Dave

Just to finish off, this post is not meant to be in a bicker tone. I also am not bicker about Walter mostly only listening to the small Inner Circle, as I do agree that this is best than design by committee, or than design by popular vote, or similar stuff, like you mentioned. My point is that
a) this approach (one man design) does still have some disadvantages which we should be aware of. Particularly since I believe Walter has a very atypical programming experience, making it hard to present some otherwise IMO obvious points (which is why I looked with good eyes to the increased involvement of Inner Circle member Andrei in the NG, I hope he comes back).
b) "abstract" arguments should not be discarded, for the reasons mentioned above.
c) I like the term "Inner Circle" :P

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
June 02, 2007
Bruno Medeiros wrote:
> For example, in their proposal, I still don't what is the typeof(fooptr) as in the code below:
>   final foo;
>   auto fooptr = &foo;
> even though I asked 2 or 3 times now.

It'll be an error, since there's no way to deduce the type of foo. But let's rewrite it as:
	final int foo;
	auto fooptr = &foo;
Since foo cannot change its value, then fooptr must be an invariant(int)*.


> And there also has not yet been any mention of how const/final/etc. will work in regards of template specialization (how to specialize on const, etc.).

It's written on paper, but not implemented. Designs have a way of morphing when they are actually implemented.
June 02, 2007
Walter Bright wrote:
> Bruno Medeiros wrote:
>> For example, in their proposal, I still don't what is the typeof(fooptr) as in the code below:
>>   final foo;
>>   auto fooptr = &foo;
>> even though I asked 2 or 3 times now.
> 
> It'll be an error, since there's no way to deduce the type of foo. But let's rewrite it as:
>     final int foo;
>     auto fooptr = &foo;
> Since foo cannot change its value, then fooptr must be an invariant(int)*.
> 
> 

Duh, yes, I forgot the type.
Anyways, you've said before that invariant, like const, only applies to referenced data, and not to the immediate value. Such that const or invariant on primitive types has no effect:
  const int a;  // no effect, same as a normal int.
If that is the case, then do invariant(int) and invariant(const), as in the fooptr example above, have different semantics? Do they apply to the immediate value when used with that parenthesis syntax? Meaning that the following two vars would have different constraints? :
  invariant(int) i1;
  invariant int  i2;

Second, let's change the first example, let's have a Foo instead of an int:
   final Foo foo;
   auto fooptr = &foo;
What would be the type of fooptr?  Would it also be invariant(Foo)* ?
What would be the type of *fooptr? Would it be invariant(Foo) ?
If so, would that mean that the following would not be allowed:
  (*fooptr).membervar = 42 ;
even though this is:
  foo.membervar = 42;
?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
June 02, 2007
Bruno Medeiros wrote:
> Walter Bright wrote:
>> [...]
>> It'll be an error, since there's no way to deduce the type of foo. But let's rewrite it as:
>>     final int foo;
>>     auto fooptr = &foo;
>> Since foo cannot change its value, then fooptr must be an invariant(int)*.
> 
> [...]
> Second, let's change the first example, let's have a Foo instead of an int:
>    final Foo foo;
>    auto fooptr = &foo;
> What would be the type of fooptr?  Would it also be invariant(Foo)* ?
> What would be the type of *fooptr? Would it be invariant(Foo) ?
> If so, would that mean that the following would not be allowed:
>   (*fooptr).membervar = 42 ;
> even though this is:
>   foo.membervar = 42;
> ?

I think that Walter's scenario must type to const(int)*, for consistency, even though const(int)* and invariant(int)* are equivalent, given that int is an elementary value type.  This leads to the proper conclusion that typeof(fooptr) == const(Foo)*, typeof(*fooptr) == const(Foo).

Dave
June 02, 2007
David B. Held wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> [...]
>>> It'll be an error, since there's no way to deduce the type of foo. But let's rewrite it as:
>>>     final int foo;
>>>     auto fooptr = &foo;
>>> Since foo cannot change its value, then fooptr must be an invariant(int)*.
>>
>> [...]
>> Second, let's change the first example, let's have a Foo instead of an int:
>>    final Foo foo;
>>    auto fooptr = &foo;
>> What would be the type of fooptr?  Would it also be invariant(Foo)* ?
>> What would be the type of *fooptr? Would it be invariant(Foo) ?
>> If so, would that mean that the following would not be allowed:
>>   (*fooptr).membervar = 42 ;
>> even though this is:
>>   foo.membervar = 42;
>> ?
> 
> I think that Walter's scenario must type to const(int)*, for consistency, even though const(int)* and invariant(int)* are equivalent, given that int is an elementary value type.  This leads to the proper conclusion that typeof(fooptr) == const(Foo)*, typeof(*fooptr) == const(Foo).
> 
> Dave

Hum, you're right, it should type to const instead of invariant, I totally missed that. However I missed because I'm trying to look into another issue, what I really want to know is if the full type of (*(&foo)) will be the same as (foo), and so far it seems not, according to what Walter's said. So
  typeof(foo) is:  final Foo
but
  typeof(*(&foo)) is:  const(Foo)
which seems a breach in orthogonality, and meaning that this won't be allowed:
  (*(&foo)).membervar = 42;

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
1 2 3 4
Top | Discussion index | About this forum | D home