parabolis wrote:

> I see what you mean. I am just sorry D's character could not have been better. Perhaps a better character (for concat) would have been '·' (html entity '·').

Seems to be hard enough to get people to type a ~ character...

http://www.digitalmars.com/d/faq.html#keys

And that's even before going into non-ASCII characters like ∪.

--anders

Anders F Björklund wrote:
> parabolis wrote:
> 
>> I see what you mean. I am just sorry D's character could not have been better. Perhaps a better character (for concat) would have been '·' (html entity '·').
> 
> 
> Seems to be hard enough to get people to type a ~ character...
> 
> http://www.digitalmars.com/d/faq.html#keys
> 
> And that's even before going into non-ASCII characters like ∪.
> 
> --anders

http://www.digitalmars.com/d/html.html

Not hard at all if you just type the html entity for the char you want. So '˜' should also work - as would '·'.

parabolis wrote:
| Anders F Björklund wrote:
|
|> parabolis wrote:
|>
|>> I see what you mean. I am just sorry D's character could not have
|>> been better. Perhaps a better character (for concat) would have been
|>> '·' (html entity '·').
|>
|> Seems to be hard enough to get people to type a ~ character...
|>
|> http://www.digitalmars.com/d/faq.html#keys
|>
|> And that's even before going into non-ASCII characters like ∪.
|
| http://www.digitalmars.com/d/html.html
|
| Not hard at all if you just type the html entity for the char you want.
| So '˜' should also work - as would '·'.

DMD's HTML code is buggy, works with GDC though ;)

Thomas

Ben Hinkle wrote:
>>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.
>>
>>(*) x==y would be legal only if type(x) defines opEquals or opCmp, which
>>should be a small minority of cases.
> 
> opEquals and opCmp are used by the TypeInfo for Objects (see
> src/phobos/std/typeinfo/ti_C.d). And the compare function in the TypeInfo is
> used by associative arrays lookup. So removing opCmp would impact more than
> sort - it would impact AA's and TypeInfo's (which are also used by MinTL
> containers). So any proposal about removing opEquals and opCmp need to talk
> about what to do about TypeInfos and how they would work for Objects.

Right.  That's the easy part.

TypeInfo.compare can be removed easily enough: it is only used in a handful of places, and those cases are, as far as I can tell, exclusively limited to the AA code. (and MinTL, evidently)  It should be easy enough to modify these classes to use TypeInfo.getHash() instead.

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.  This bugs me, though, as we're left with a TypeInfo.compare method which compares objects by effectively meaningless criteria, whether or not a more meaningful comparison is available. (I have tried this myself.  Everything seems to work okay, but I haven't tested it very thoroughly yet)

 -- andy

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.

"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!

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. :\

 -- andy

On Wed, 12 Jan 2005 17:10:23 -0500, parabolis <parabolis@softhome.net> wrote:

> Anders F Björklund wrote:
>
>> Just seems that every language needs to use it's own character...
>>  Java: "+", D: "~", Perl: ".", Basic: "&", and so on, and so on ?
>
> I see what you mean. I am just sorry D's character could not have been better. Perhaps a better character (for concat) would have been '·' (html entity '&middot;').

is that · or ‧? Some fonts they are identical :D

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Andy Friesen wrote:
> Stewart Gordon wrote:
<snip>
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5403
> 
> Basically, it boils down to the idea that the weakness lies in the fact that these questionable formations are possible at all.
<snip>
> I'll readily agree that a warning is better than nothing at all, but a lot of the warnings C and C++ compilers issue could be obliviated by adjusting the language.

Indeed.  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.

<snip>
>> Indeed.  Similarly with allowing auto references to be declared without initialisation.
> 
> 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 auto references should also be final.

I had no idea that local variables could be final.  What does it mean, exactly?

>> 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

> which in turn means that "x==y" becomes a compile-time error.

== depends on opEquals, not opCmp.

> 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.

Stewart.

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

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 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.

But even a few BASIC manuals that predate VB have conversion guides that mention changing "&" to "+", so obviously VB wasn't a first here.  But did these others have "&" instead of, or as an alternative to, "+"?

(And apparently some BASICs had "\" as a statement separator instead of ":".  Does anyone know about this?)

> and so on, and so on ?

Yes.  Fortran: "//"

Stewart.

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