In article <cs89af$1v8p$1@digitaldaemon.com>, Stewart Gordon says...
>
>Andy Friesen wrote:
>> Stewart Gordon wrote:
>> 
>>> But if a language is supposed to be portable, then individual compiler writers can't just adjust the language to the formations they personally find questionable.  This is probably where a lot of the warnings in C(++) compilers came from - their developers finding questionable 'features' of the language.
>> 
>> Of course, but Walter is in a position to change both.  If he so decrees, a questionable formation can cease to be legal D.
>
>Of course, but what makes you think Walter is the only person in the world who will ever write a D compiler?
>

Am I understanding you correctly, Stewart?

In the first paragraph you argue for resolving 'questionable features' so that a standard set of D features will be implemented by anyone developing a D compiler.

In the third, you seemingly imply that other D compiler implementers may deviate from the reference compiler wrt 'questionable features'.

If that's the case, then (obviously), let's stay off of that slippery slope.. Andy is correct - certainly Walter should be the final arbiter on these matters.

Implementing a D compiler with one of the purposes being changing features of the language would (again, obviously) be disastrous for everyone.

I'm sure we'ed all rather have every compiler working the same way for the relatively few features we don't like than have one or more forks of the language (once again, obviously).

If I'm misunderstanding where you were heading with the 3rd paragraph, please correct me.

- Dave

Stewart Gordon wrote:
> Andy Friesen wrote:
> 
>> Stewart Gordon wrote:
>>
>>> But if a language is supposed to be portable, then individual compiler writers can't just adjust the language to the formations they personally find questionable.  This is probably where a lot of the warnings in C(++) compilers came from - their developers finding questionable 'features' of the language.
>>
>> Of course, but Walter is in a position to change both.  If he so decrees, a questionable formation can cease to be legal D.
> 
> Of course, but what makes you think Walter is the only person in the world who will ever write a D compiler?

I'm sorry, I think I misunderstood you.  What I meant was that it's possible for a lot of frequent warnings to be obliviated by the language designer.

>>> I had no idea that local variables could be final.  What does it mean, exactly?
>>
>> I don't think they can.  What it would mean is that it would be an error to assign to a final variable after initialization.
> 
> It's called const.  Though I forget the extent to which such things have to be compile-time constants as it currently stands.

const values are restricted to those which can be completely evaluated by the compiler.  "const int x = rand();" won't work, whereas "final int x = rand();" would.  Hypothetically, anyway; this is a C#/Java concept, not a D concept.

> And you're still not telling me anything about how moving it from builtin to the library will be either necessary or sufficient to overcome the dependence on Object.opCmp.  Moreover, many builtins are already implemented in terms of library functions (mostly in the internal package), and that includes sort.  As such, the implementation options are pretty much the same in either case.

I'm primarily thinking about the amount of work it would take to adjust DMD.  As far as I can tell, array.sort isn't dealt with until late in compilation, in the bits whose source code we are not privy to.  I don't know how much renovating would be needed to change that to a template instantiation/invocation, but it seems logical that removing it completely would be straightforward enough.  This would be the only part of DMD itself which would need to change at all: the rest is all Phobos.

 -- andy

Norbert Nemec wrote:
> Andy Friesen wrote:
> 
>>Of course, but Walter is in a position to change both.  If he so
>>decrees, a questionable formation can cease to be legal D.
> 
> I don't know whether it is a good idea to illegalize things that cannot be
> checked in every case. IMO, the compiler should be able to give a definite
> answer as to whether some code is legal or not. Furthermore, illegalizing
> always means adding a rule to the language specifications. If you add a
> special rule for every questionable case, the language specs will get
> really ugly.

Right.  I was thinking about more subtle methods, like making assignment a statement so it cannot be a loop condition.

Of course, there's no guarantee that such a solution is apparent, in which case a warning is really all that can be done.

 -- andy

Dave wrote:
<snip>
> Am I understanding you correctly, Stewart?
> 
> In the first paragraph you argue for resolving 'questionable features' so that a standard set of D features will be implemented by anyone developing a D compiler.
> 
> In the third, you seemingly imply that other D compiler implementers may deviate from the reference compiler wrt 'questionable features'.

Depends on what you mean.  If you mean deviate in terms of what they'll accept as a valid program, then of course not.  If you mean deviate in terms of whether to issue warnings and what warnings to issue, then they ought to have every right to.

<snip>
> If I'm misunderstanding where you were heading with the 3rd paragraph, please correct me.

Your whole comment seems written around the pretence that there is no such thing as a warning.

My point is that, while Walter can indeed change D so that more and more questionable features are eliminated, third-party compiler writers cannot.  Hence they are going to want to help coders avoid common mistakes that aren't errors by the language spec.  The usual way to do this, implemented by generations of C(++) compilers, is by issuing warnings.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

Andy Friesen wrote:
<snip>
> I'm primarily thinking about the amount of work it would take to adjust DMD.  As far as I can tell, array.sort isn't dealt with until late in compilation, in the bits whose source code we are not privy to. 

Even if it's in the middle-end, there's nothing to say it can't be moved to the front-end.

> I don't know how much renovating would be needed to change that to a template instantiation/invocation,
<snip>

It would be a simple matter of writing sort as a template function, maybe internal.qsort.sort(T), and then mapping

    array.sort;

to

    internal.qsort.sort!(T)(array);

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <cs92bh$2s2n$1@digitaldaemon.com>, Stewart Gordon says...
>
>Dave wrote:
><snip>
>> Am I understanding you correctly, Stewart?
>> 
>> In the first paragraph you argue for resolving 'questionable features' so that a standard set of D features will be implemented by anyone developing a D compiler.
>> 
>> In the third, you seemingly imply that other D compiler implementers may deviate from the reference compiler wrt 'questionable features'.
>
>Depends on what you mean.  If you mean deviate in terms of what they'll accept as a valid program, then of course not.  If you mean deviate in terms of whether to issue warnings and what warnings to issue, then they ought to have every right to.

That different compilers not deviate on what is acceptable (and how it actually executes) is what I was driving at and I guess you were too - I just couldn't tell from the post and it's context.

Absolutely, different warning mechanisms intended to help the developer with common pitfalls and such are a good thing for compilers to compete over.

- Dave

99% of the time is spent making the test case to spew the access violation--once it's there fixing it is trivial.

This should really be turned into a static type checking problem... 99% of
blahobject == null
mistakes will happen because the user is testing equality against the null token... thus checking it in the compiler will prevent the problem 99% of the time before it needs to be reproduced...

This is a feature that I expect for 1.0 because in no case will that test do what the user desired...
because if the user desires the function call against null they will and can write blahobject.opCmp(null);
The dot syntax makes it extraordinarily clear that unless opCmp is a static function (we know it is not from the spec) then it will be an access violation if blahobject is null



Walter wrote:
> "h3r3tic" <foo@bar.baz> wrote in message
> news:crv8pk$2jcu$1@digitaldaemon.com...
> 
>>//! My 2 bits
>>I'd have a different proposal... What might be done, is some more
>>checking in the debug build. I'd say this is almost like array bounds
>>checking, the null-ness check might be done for the == (and the rest of
>>opCmp-defined) operators in debug, but removed in the release build. I'd
>>prefer to see a 'nice' error with full info instead of an Access
>>Violation. Something like the ArrayBoundsError would be just fine for me.
> 
> 
> The null check is being done. It's just being done "for free" by the
> hardware. You can also catch access violation exceptions just like any other
> exception. There really isn't anything added by doing a redundant check in
> software, other than bloat.
> 
> P.S. If you compile with -g, and run the program under the debugger, the
> debugger will display the location of the access violation and the call
> stack leading up to it. I use this capability regularly. It works like a
> champ!
> 
> 

I second this completely, do away with it , give us sort's with user defined sorting .

If only we could get Walter to here us ;).

Charlie


"Kris" <Kris_member@pathlink.com> wrote in message news:cs3sfd$2mer$1@digitaldaemon.com...
> In article <cs3p07$2gn6$1@digitaldaemon.com>, Andy Friesen says...
> >Here's a question: How many would be willing to give up the array.sort property in exchange for disallowing x==y? (*)
> >
> >Removing opCmp from Object would achieve precisely this, and it would not require much change to the compiler itself.  The sort function could be moved to the standard library easily enough, requiring only minor adjustments to existing code, while still succeeding in making it harder to write bad code that looks good.
>
> Oh, if only Walter would agree!
>
> The .sort property was in place long before either Template or Interface
were
> added. Since that time, the argument for having .sort as part of the
language
> spec is (IMO) seriously weakened; particularly so since it is the prime
(and
> only?) reason for the awkward opCmp within Object. Either of Template or Interface could do the job just as effectively, and be user-replaceable (alternate sorting mechanisms, anyone?) if the functionality were moved to
a
> library instead.
>
> There's been a whole lot of discussion on this before, and it really
seemed as
> though there was a reasonable concensus on the issue. But ... nothing
changed.
>
> Heck, I recall Walter noting he would /definately/ remove the usage of
printf()
> from Object (to reduce the minimal footprint: all that FP support dragged
along
> for no legitimate reason) -- that he "just had to get around to it". That
was
> the middle of last year; Ben even posted the small list of changes needed
in
> Phobos (all within debug code, I vaguely recall).
>
> Tightening up the language spec appears to be the lowest priority.
>
> If I come across as being somewhat dejected, it's not because D isn't a
fine
> language ... it's because it could be made a whole lot better through just
a few
> tweaks here and there (such as the removal of opCmp in Object, or making
the
> usage of 'override' mandatory).
>
> Sure, such changes may break some existing code! Better now than after
v1.0,
> right? I'd be happy to spend the time editing the ~100,000 lines I've
written if
> it meant the language was tighter, leaner, and ultimately less prone to
user
> error.
>
> <sigh>
>
>

> Or perhaps "aint".

Yes! lol

"Anders F Björklund" <afb@algonet.se> wrote in message news:cs2uaf$18nj$1@digitaldaemon.com...
> Daniel Horn wrote:
>
> > I guess we *could* have a lint program do this for us--but if/when this magical lint program gets made...and decides NOT to spit a billion warnings out for otherwise-working projects is a mystery.
>
> D should have all "warnings" enabled by default, as part of the design.
>
> http://www.digitalmars.com/d/overview.html:
> > No Warnings
> > D compilers will not generate warnings for questionable code.
> > Code will either be acceptable to the compiler or it will not be.
> > This will eliminate any debate about which warnings are valid
> > errors and which are not, and any debate about what to do with them.
> > The need for compiler warnings is symptomatic of poor language design.
>
> So all warnings and lint should be enabled by default, and give errors.
>
> > two equals signs is already a hack--but 3...c'mon! that's making 3 separate operators consisting of various numbers of the same char... 2 already cause a great number of errors amongst C and C++ newbies from all backgrounds.
>
> I thought that "===" was deprecated in favor of "is" ? (for TOKidentity) http://www.digitalmars.com/d/expression.html#EqualExpression
>
> But I also think that the compiler should be able to catch "foo == null"
> I mean, it already catches the "if (a = b)" typo? (not a boolean result)
>
> --anders
>
> PS. The only problem was there isn't such a token for TOKnotidentity.
>      But something like "isnt" should do, I suppose ? Or perhaps "aint".
>      Or one of the syntactically horrible "is not" or "isn't" (not alnum)
>      The current workaround is to use: !(a is b), which of course works.