Walter wrote:
<snip>
> 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!

What is _the_ debugger?  Where's it found?

Stewart.

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

Stewart Gordon wrote:
| Anders F Björklund wrote:
|
|> Stewart Gordon wrote:
|>
|>>> If James Gosling can overload "plus" (+) to mean string concat,
|>>
|>>
|>> James Gosling was by no means the first to do it.  But whether it was
|>> John Kemeny/Thomas Kurtz or if it caught on since their time isn't
|>> clear from my sources.
|>
|>
|> :-) (I bow to your "Oak" knowledge)
|
|
| What is "Oak"?

Just guessing:
Your knowledge reaches as far back as that of an old holm oak/ilex.


Thomas

Andy Friesen wrote:
> parabolis wrote:
> 
>> Andy Friesen wrote:
>>
>>>
>>> An easier way is to adjust ti_C.d to use Object.toHash() instead of opCmp and opEquals.  This preserves existing AA behaviour without requiring the definition of comparison operators.
>>
>>
>> I think the opCmp and opEquals are used in AAs to deal with hash  collisions.
> 
> 
> gah.  You're right.
> 
> This would almost work as-is, because an object instance's hash code is (unless overridden) its address, but that's not exactly a good longterm solution.  Without some way to order objects that has nothing to do with hash codes, the AA implementation would have to resort to a linear search when digging out keys with a particular hash value.
> 
> So much for the trivial fix. :\

Maybe. I have been wondering whether it would be an improvement to eliminate Object as the default base class. Doing so would mean the comparison operators would not work on objects and classes would have to use .equals and .compareTo member functions instead. It would also mean redesigning the guarantee that an object has the .equals, .compareTo and .toHash functions via interfaces:
----------------------------------------------------------------
Interface Comparable {
  int compareTo();
}

Interface Equatable {
  bit equals();
}

Interface Hashable : Comparable, Equatable {
  int toHash();
}
----------------------------------------------------------------

In article <g5eib2-qu3.ln1@lnews.kuehne.cn>, Thomas Kuehne says...
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Stewart Gordon wrote:
>| Anders F Björklund wrote:
>|
>|> Stewart Gordon wrote:
>|>
>|>>> If James Gosling can overload "plus" (+) to mean string concat,
>|>>
>|>>
>|>> James Gosling was by no means the first to do it.  But whether it was
>|>> John Kemeny/Thomas Kurtz or if it caught on since their time isn't
>|>> clear from my sources.
>|>
>|>
>|> :-) (I bow to your "Oak" knowledge)
>|
>|
>| What is "Oak"?
>
>Just guessing:
>Your knowledge reaches as far back as that of an old holm oak/ilex.
>
>

or

"[java] originally called OAK. " http://hopl.murdoch.edu.au/showlanguage.prx?exp=2131

Ant

Thomas Kuehne wrote:

> |>> James Gosling was by no means the first to do it.  But whether it was
> |>> John Kemeny/Thomas Kurtz or if it caught on since their time isn't
> |>> clear from my sources.
> |>
> |> :-) (I bow to your "Oak" knowledge)
> |
> | What is "Oak"?
> 
> Just guessing:
> Your knowledge reaches as far back as that of an old holm oak/ilex.

Not really, I meant as in the programming language...

See http://java.sun.com/features/1998/05/birthday.html

> The reason *7 was able to control a wide range of entertainment
> platforms and appliances -- while displaying animation -- is that
> it ran on an entirely new, processor-independent language.
> 
> The language itself was created by Green Team member James Gosling
> specifically for *7. Gosling called the new language "Oak,"
> after the tree outside his window.

And http://www.ibiblio.org/javafaq/javafaq.html

> The name "Oak" was later dismissed due to a patent search which
> determined that the name was copyrighted and used for another
> programming language. According to Gosling, "the Java development team
> discovered that Oak was the name of a programming language that predated
> Sun's language, so another name had to be chosen."

As of lately, Sun have begun calling *everything* "Java" :

languages, virtual machines, whole server software families,
operating systems, hardware, floor wax, dessert topping ...

--anders


PS. Then I read upon who John Kemeny/Thomas Kurtz were...
    Apparently they discovered the abomination BASIC.
    I somehow thought they were related to Java. :-)

Stewart Gordon wrote:

>> Just seems that every language needs to use it's own character...
>>
>> Java: "+", D: "~", Perl: ".", Basic: "&",
> 
> Every BASIC I've used has "+" here.  Though Visual Basic has "&" as an alternative.

Fortunately, I haven't had to use BASIC, Fortran, or COBOL... :-)

I thought Pascal was bad enough.

--anders

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cs6016$2ih2$2@digitaldaemon.com...
> Walter wrote:
> <snip>
> > 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!
>
> What is _the_ debugger?  Where's it found?

You can use gdb under linux, and any codeview compatible debugger (such as DMC++'s debugger or Windbg.exe) under Windows.

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.

>> I had no idea that was legal.  The behaviour seems perfectly logical to me, but I can understand how that might be misleading.
> 
> What is perfectly logical about being able to declare something if it's obvious there and then that you'll never be able to do anything with it without causing an AV?

Perhaps its behaviour is not so obvious, then. :)  I had assumed that it could be assigned a value later on, which would then be disposed of when the auto variable falls out of scope.  eg

    auto File f;
    if (reading) f = new File("foo.txt", FileMode.In);
    else         f = new File("foo.txt", FileMode.OutNew);

>> Perhaps auto references should also be final.
> 
> 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.

>>> What would be the point of moving sort to the standard library?
>>
>> "x==y" is only legal because Object[].sort depends on Object.opCmp. Removing Object[].sort means that Object.opCmp can be removed,
> 
> So can other approaches, such as reimplementing it using templates, or as described here:
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/10558

That would also work, though reserving a vtable slot for opCmp feels a bit rickety to me.  How would you do this:

   interface I { int opCmp(I rhs); }
   interface J { int opCmp(J rhs); }

   class C : I, J { .... }

   I[] is = { new C(), .... };
   J[] js = { new C(), .... };

   is.sort;
   js.sort;

That being said, the ends are more interesting to me than the means. :)

>> which in turn means that "x==y" becomes a compile-time error.
> 
> == depends on opEquals, not opCmp.

Right, sorry.  In an ideal world, both would get the axe.

>> D has very nice template support now, so there's no reason not to make sorting a standard library function instead of a language builtin. Doing this allows us to turn a very common mistake with subtle consequences into one that is easy to find and fix.
> 
> At the moment, I still don't see what turning it into a library function has to do with fixing this wart.

Array.sort is the only place, as far as I have been able to tell, that can't do without opCmp without losing functionality.  (AAs may be a hair slower in the case of hash clashes, but they will still associate just fine)

 -- andy

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.

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?

<snip>
>>> Perhaps auto references should also be final.
>> 
>> 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.

But indeed, it is specifically stated:

http://www.digitalmars.com/d/attribute.html#auto

"Assignment to an auto, other than initialization, is not allowed."

<snip>
> That would also work, though reserving a vtable slot for opCmp feels a bit rickety to me.  How would you do this:
> 
>    interface I { int opCmp(I rhs); }
>    interface J { int opCmp(J rhs); }
> 
>    class C : I, J { .... }

I guess that the reserved slot would only be filled if C defines opCmp(C) as well as opCmp(I) and opCmp(J).  Otherwise, comparing a C with a C would be ambiguous and therefore an error.

Of course, the interface vtbls (if there's a such a thing) would have opCmp(I) and opCmp(J) in those slots respectively.

<snip>
>> At the moment, I still don't see what turning it into a library function has to do with fixing this wart.
> 
> Array.sort is the only place, as far as I have been able to tell, that can't do without opCmp without losing functionality. 
<snip>

Indeed.  But that doesn't mean it can't do without _Object_.opCmp.

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.

Stewart.

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