View mode: basic / threaded / horizontal-split · Log in · Help
May 30, 2007
Re: iterators again
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
Re: iterators again
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
Re: iterators again
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
Re: iterators again
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
Re: iterators again
"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
Re: iterators again
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
Re: iterators again
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
Re: iterators again
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
Re: iterators again
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
Re: iterators again
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