Sean Kelly <sean@f4.ca> wrote:

[...]
> I disagree.  DMD is a reference implementation, so where the spec is vague DMD should serve as an authoritative refernce on expected behavior.

Then: what is the bugs group for? Only for deviations of dmd to the specs?

-manfred

Regan Heath wrote:

> On Tue, 09 Aug 2005 12:06:53 +0100, Stewart Gordon <smjg_1998@yahoo.com>  wrote:
<snip>
>> Which would the < <= > >= operators use under your proposal?
> 
> opCmp
> 
>> Since this is akin to sorting, it would make sense to use opSort
> 
> I disagree. You're comparing not sorting thus opCmp makes sense.

Adding or looking up a key in an AA isn't comparing either.

Under the way I had it, one comparator is used externally and one internally.  It also remains possible to define < <= > >= to have a non-strict comparator.  (OK, so there would remain inconsistency between

    qwert <= yuiop

and

    qwert < yuiop || qwert == yuiop

but is this really an excuse?)

> More important however is _how_ you want to compare in the general case  with this special type, eg.
> 
> IChar a = 'a';
> IChar b = 'B';
> 
> if (a < b) { //true or false? }
> 
> Assume for the sake of argument:
>   'a' = 0x61 or 91 decimal
>   'B' = 0x42 or 66 decimal
> 
> Is the statement true or false?
> 
> Does the answer depend on context (if so, which is more common case or no case?) or will this type always be compared in one way?

My thought was that it will always be compared in this way.

> If you generally want to do a case-insensitive compare then you're defining an opCmp that AA's cannot use.
> If you want to do case-sensitive compare generally then you're defining an opCmp that AA's can use.
> 
> I suspect you want the former, right?
<snip>

The idea of my example is that they rank case-insensitively but match case-sensitively.

Stewart.

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

Sean Kelly wrote:

> In article <dda28h$21m5$1@digitaldaemon.com>, Stewart Gordon says...
> 
>>Sean Kelly wrote:
>>
>>>But it looks like the
>>>point you were trying to make is that 'C' and 'c' are considered equivalent
>>>keys, which I would consider correct behavior given the current implementation.
>>
>>Correct behaviour is determined by the spec, not by some implementaion.
> 
> I disagree.  DMD is a reference implementation, so where the spec is vague DMD
> should serve as an authoritative refernce on expected behavior.

This would mean that:

1. All undefined testcases in DStress should be either pass or xfail, defeating the point.

2. If some undefined code crashes the compiler, then crashing the compiler is correct behaviour.

3. Third-party compiler writers would have to hop back and forth between the spec and the reference implementation.

This strikes me as absurd.  A language should be implementable from the spec alone.

Stewart.

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

In article <ddajcc$2p86$1@digitaldaemon.com>, Manfred Nowak says...
>
>Sean Kelly <sean@f4.ca> wrote:
>
>[...]
>> I disagree.  DMD is a reference implementation, so where the spec is vague DMD should serve as an authoritative refernce on expected behavior.
>
>Then: what is the bugs group for? Only for deviations of dmd to the specs?

Mostly, yes.  Though I've posted things there in the past that were more of a feature change request than a bug report.  Thing is, Walter is not a tech writer, and he tends to spend time on compiler changes over documentation.  So in instances where the spec is unclear or just plain doesn't say anything, you have to make an educated guess about what's intended, and DMD is a useful reference for this.  As far as this hash issue is concerned--I consider the use of opCmp to be a requirement simply because a program wouldn't be portable between compilers if one were implemented using opEquals and the other were implemented using opCmp, and DMD uses opCmp.


Sean

In article <ddal12$2sda$1@digitaldaemon.com>, Stewart Gordon says...
>
>Sean Kelly wrote:
>
>> In article <dda28h$21m5$1@digitaldaemon.com>, Stewart Gordon says...
>> 
>>>Sean Kelly wrote:
>>>
>>>>But it looks like the
>>>>point you were trying to make is that 'C' and 'c' are considered equivalent
>>>>keys, which I would consider correct behavior given the current implementation.
>>>
>>>Correct behaviour is determined by the spec, not by some implementaion.
>> 
>> I disagree.  DMD is a reference implementation, so where the spec is vague DMD should serve as an authoritative refernce on expected behavior.
>
>This would mean that:
>
>1. All undefined testcases in DStress should be either pass or xfail, defeating the point.
>
>2. If some undefined code crashes the compiler, then crashing the compiler is correct behaviour.

See my other post for clarification.  I didn't mean to imply that DMD should be law so much as a reference for intended behavior when the spec is lacking.  But some extrapolation is required as well.

>3. Third-party compiler writers would have to hop back and forth between the spec and the reference implementation.
>
>This strikes me as absurd.  A language should be implementable from the spec alone.

I agree completely.  But at the moment, the spec is a bit sparse.  In some respects, I rather like this, as it makes me feel like some features I don't like aren't yet set in stone.


Sean

On Tue, 9 Aug 2005 15:50:36 +0000 (UTC), Manfred Nowak wrote:

> Sean Kelly <sean@f4.ca> wrote:
> 
> [...]
>> I disagree.  DMD is a reference implementation, so where the spec is vague DMD should serve as an authoritative refernce on expected behavior.
> 
> Then: what is the bugs group for? Only for deviations of dmd to the specs?

Do you try to be thick?

DMD is not perfect - it has mistakes that even we simpletons can see. And in spite of that, it is still further along the track than the official documentation. This is not how it should be, I know, but that's the reality we have to put up with. And complaining about that aspect has got even less chance of an improvement than some of the weirdo things on our wishlists. Its simply not Walter's development methodology to document before coding.

-- 
Derek Parnell
Melbourne, Australia
10/08/2005 7:46:42 AM

On Tue, 09 Aug 2005 17:20:07 +0100, Stewart Gordon wrote:

> Sean Kelly wrote:
> 
>> In article <dda28h$21m5$1@digitaldaemon.com>, Stewart Gordon says...
>> 
>>>Sean Kelly wrote:
>>>
>>>>But it looks like the
>>>>point you were trying to make is that 'C' and 'c' are considered equivalent
>>>>keys, which I would consider correct behavior given the current implementation.
>>>
>>>Correct behaviour is determined by the spec, not by some implementaion.
>> 
>> I disagree.  DMD is a reference implementation, so where the spec is vague DMD should serve as an authoritative refernce on expected behavior.
> 
> This would mean that:
> 
> 1. All undefined testcases in DStress should be either pass or xfail, defeating the point.
> 
> 2. If some undefined code crashes the compiler, then crashing the compiler is correct behaviour.
> 
> 3. Third-party compiler writers would have to hop back and forth between the spec and the reference implementation.
> 
> This strikes me as absurd.  A language should be implementable from the spec alone.

Absolutely true!

But that's not how it is. Reality supersedes theory.

DMD is both the best reference we have to date and it is not complete. It contains mistakes and 'prototype' code. The official D Language specification is not as up-to-date as the implementation of Walter's ideas - DMD.

Walter does not follow best practices when it comes to software development; get over it.

-- 
Derek Parnell
Melbourne, Australia
10/08/2005 7:54:39 AM

On Tue, 09 Aug 2005 17:14:42 +0100, Stewart Gordon <smjg_1998@yahoo.com> wrote:
>> On Tue, 09 Aug 2005 12:06:53 +0100, Stewart Gordon <smjg_1998@yahoo.com>  wrote:
> <snip>
>>> Which would the < <= > >= operators use under your proposal?
>>  opCmp
>>
>>> Since this is akin to sorting, it would make sense to use opSort
>>  I disagree. You're comparing not sorting thus opCmp makes sense.
>
> Adding or looking up a key in an AA isn't comparing either.

In which case it should use opRank or opSort, no? (if it exists)

Comparing is required for sorting, but not vice-versa.
What AA's do is akin to sorting, not comparing.
Right?

> Under the way I had it, one comparator is used externally and one internally.

externally: case-insensitive  (opCmp)
internally: case-sensitive    (opRank/opSort/opAA ..)

Right?

>> More important however is _how_ you want to compare in the general case  with this special type, eg.
>>  IChar a = 'a';
>> IChar b = 'B';
>>  if (a < b) { //true or false? }
>>  Assume for the sake of argument:
>>   'a' = 0x61 or 91 decimal
>>   'B' = 0x42 or 66 decimal
>>  Is the statement true or false?
>>  Does the answer depend on context (if so, which is more common case or no case?) or will this type always be compared in one way?
>
> My thought was that it will always be compared in this way.

Always compared in a case insensitive fashion?
Except.. when compared during sorting/ranking.

>> If you generally want to do a case-insensitive compare then you're defining an opCmp that AA's cannot use.
>> If you want to do case-sensitive compare generally then you're defining an opCmp that AA's can use.
>>  I suspect you want the former, right?
> <snip>
>
> The idea of my example is that they rank case-insensitively but match case-sensitively.

By 'match' do you mean only '==' or '<' '<=' etc as well?

Regan

Regan Heath wrote:
> On Tue, 09 Aug 2005 17:14:42 +0100, Stewart Gordon <smjg_1998@yahoo.com>  wrote:
<snip>
[Regan:]
>>> I disagree. You're comparing not sorting thus opCmp makes sense.
>>
>> Adding or looking up a key in an AA isn't comparing either.
> 
> In which case it should use opRank or opSort, no? (if it exists)
> 
> Comparing is required for sorting, but not vice-versa.
> What AA's do is akin to sorting, not comparing.
> Right?

Yes, except that an AA is sorted only internally.  OTOH array.sort is external sorting, i.e. the application, and possibly even the user, concerns him/her/itself with the order generated by array.sort.

<snip>
>> The idea of my example is that they rank case-insensitively but match  case-sensitively.
> 
> By 'match' do you mean only '==' or '<' '<=' etc as well?

By 'rank' I mean what < <= > >= do - maybe 'order' is a better word.  By 'match' I mean ==, and hence what one would naturally expect of AA key matching.

Stewart.

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

On Wed, 10 Aug 2005 18:12:48 +0100, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> Regan Heath wrote:
>> On Tue, 09 Aug 2005 17:14:42 +0100, Stewart Gordon <smjg_1998@yahoo.com>  wrote:
> <snip>
> [Regan:]
>>>> I disagree. You're comparing not sorting thus opCmp makes sense.
>>>
>>> Adding or looking up a key in an AA isn't comparing either.
>>  In which case it should use opRank or opSort, no? (if it exists)
>>  Comparing is required for sorting, but not vice-versa.
>> What AA's do is akin to sorting, not comparing.
>> Right?
>
> Yes, except that an AA is sorted only internally.  OTOH array.sort is external sorting, i.e. the application, and possibly even the user, concerns him/her/itself with the order generated by array.sort.

Sure.

It doesn't matter how the AA's sort works provided it does not call two unequal items equal (the problem with your special type and it's opCmp operator).

Whereas the array.sort matters, and the user may want to change/define it differently in each call of array.sort.

> <snip>
>>> The idea of my example is that they rank case-insensitively but match  case-sensitively.
>>  By 'match' do you mean only '==' or '<' '<=' etc as well?
>
> By 'rank' I mean what < <= > >= do - maybe 'order' is a better word.  By 'match' I mean ==, and hence what one would naturally expect of AA key matching.

I would have said that < <= etc "compare" not "rank" or "order", and == was "compare" also, but perhaps "match". Basically, in my head < <= etc and = are all "compare" operations.

To "rank" or "order" you need some sort of context. i.e. inside an AA or when calling array.sort. You can "compare" any 2 items, you can "rank" or "order" a set of x (where x is > 1), ranking 2 items is the same as comparing, to decide which you need the context.

Anyway..

I think the solution is another operator which you can define for your types and is magically found and used by the AA implementation. So you'd have:

class IChar
{
  char data;

  int opCmp(IChar rhs)
  {
    return toupper(data) - toupper(rhs.data);
  }

  int opEquals(IChar rhs)
  {
    return data == rhs.data;
  }

  int opAA(IChar rhs)
  {
    return data - rhs.data;
  }
}

Giving you a type that you can compare with < <= etc (opCmp), compare with = (opEquals) and store in an AA (opAA - or whatever we want to call it)

The AA implementation needs only one minor change, the ability to find and use the opAA operator. Essentially instead of calling opCmp it has a delegate which it assigns upon creation to opAA or opCmp then uses for all it's internal workings.

Regan