"R. A. Harmon" wrote:
> 
> At 01:40 AM 4/16/00 +0200, Stephan Rudlof wrote:
> >Dear Squeakers,
> >
> >currently (2.7) we have
> >       'foo' = #foo -> true
> >       #foo = 'foo' -> false
> >.
> >Last suggestions of me and Dan ensure symmetry for comparison of Symbols
> >and Strings, but not ANSI compliance.
> >Symmetry is a must, IMNSHO. What about ANSI compliance?
> >

> >I think this is a serious compatibility problem, not just an academic
> >discussion.

!!

> >
> >To make String and Symbol ANSI compliant
> >========================================
> >
> >First variant:
> >------------------
> >
> >(1) make
> >       'foo' = #foo -> false
> >(symmetry leads to same result for #foo = 'foo' automagically then) by
> >
> >- changing SequenceableCollection>>= to be conformant to protocol
> ><sequencedReadableCollection>,
> >- removing #= from String (semantically, means it has to be the same
> >result as SequenceableCollection>>=).

Emphasis on *semantically*, this says nothing about implementation
details (like e.g. a primitive in String);

> An error on my part.  Change species to class instead.

out of this view there is no error, just a description of semantic
protocol conformance.

> >
> >Both changes were suggested by Richard.
> >
> >
> >(2) check code for all potential (!) occurences of the case
> >       'foo' = #foo
> >(true so far, but not after ANSI) then and rework it -> difficult for
> >vars!

This has to be done. Probably it is the best to make these changes after
the next official 2.8 release in the next test pilot image (2.9alpha),
to have enough time for error reports and removals.

> >
> >
> >
> >Second variant:
> >-------------------
> >
> >Changing the ANSI standard: it is a draft! Or is it official now?
> 
> It is official now.

Ok. Good to know.
BTW: I know, that it is almost impossible to change such a standard; but
if their were really good reasons against relevant parts of it (to avoid
misunderstandings: I don't know any so far), it would be necessary to
ignore it and to make it better.

> Change the standard might be a tough sell as my
> proposed changes do bring the following Squeak results in line with those of
> Dolphin 3.0 and VWNC 3.0:
> 
>         'abc' sameAs: 'ABC'             "-> true"
>         'abc' = 'ABC'                   "-> false"
>         #'abc' = 'abc'                  "-> false"
>         'abc' = #'abc'                  "-> false"
>         'abc' sameAs: #'abc'            "-> true"
>         #'abc' sameAs: 'abc'            "-> true"
> 
>         *** Note I used the ANSI syntax for symbol literal #'aSymbol'
>                 not the ANSI syntax for selector literal #aSelector
> 
> >Do we want to have ANSI compliance at all?
> 
> My selfish answer?  YES!!!!!
> 
> I think there is a long list of advantages ANSI compliance would bring to
> Squeak.
> 
> >Do we want to have ANSI compliance here?
> [snip]
> 
> I think the choice of sort of ANSI compliance is problematic.  What is
> compliant enough?  I guess I think of it as ANSI compliant or not.  I'm not
> sure what sort of buys you.

I second the goal of reaching ANSI compliance!
This is especially true for this important kernel ST part of Symbols and
Strings!

There may be some parts where it is annoying to reach it, but this is no
argument against.
There may be some exceptional cases, too, though, where it isn't so
important (cause nobody cares) to be fully compliant.

It shouldn't be forbidden to experiment with new ideas outside such a
standard, but currently I see no problems here. But I don't know the
standard well, I've just read the parts needed for this concrete issue.
And I don't know all ideas which could perhaps (?) come in conflict with
this standard. This was another reason, why I posted my mail.

I just wanted to have a discussion about and to be sure with these
points. Last suggestions before ANSI have reached very fast - in
performance - symmetry of #= for Symbol and String, whithout being
afraid of much code to be broken and better than the status - asymmetry
- before.
But the ANSI compliance changes could break some more code: I wanted to
make more *visible* this problem. We cannot change such a very important
part of Squeak without assuming that there have to be found some bugs
then.
Not so long time ago Andreas Raab told me, that Symbols are treated as
Strings in Squeak (I think the question was, if there are constraints
how to give String-like parameters to primitives).

It is important to keep possible sources for errors in mind and to avoid
frustrations for so called 'end users'.


Greetings and happy changing,

Stephan

> 
> --
> Richard A. Harmon          "The only good zombie is a dead zombie"
> harmonra at webname.com           E. G. McCarthy
> Spencer, Iowa

P.S.: I think the zombie should be dead now...  ;-)

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3