On Wed, 27 Sep 2000, Frank Atanassow wrote:
> D. Tweed writes:
> > Unfortunately the last time I looked at CWEB it still had the same idea
> > about identifiers as WEB itself, namely that if they match textually
> > they are the same, which makes the automatic indexes produced less useful
> > for C++: I've got twelve classes all with a `read()' method plus any in
> > the standard libraries and lumping them all together is less than
> > optimal. I'd imagine the same problem would occur for haskell with type
> I see the problem for a language like C++, which has true overloading, but not
> for Haskell. In Haskell it makes sense to identify type class methods with the
> same name, since they are semantically related. You don't need to do any type
> inference to index them; that only works when the instance is statically
> decidable anyway.
I guess it's arguable; as mentioned I masacre loads of trees due to my
habit of working on printed out source code and I could argue that:
supposing I'm reading a program where == is defined for a particular
instance of class with the comment that `note the care taken to ensure
transitivity', then I may very well want to find out if == is actually
used anywhere for this type _under the assumption that it is transitive_
without having to wade through lots of == on different classes. (From
memory, I believe there's no H98 requirement == be transitive, but this is
just a contrived example anyway.) Just because type class methods _ought_
to be semantically related doesn't mean they necessarily will be.
> The problem that remains is handling scope correctly, but that must be a
> problem for C/C++ as well. Here you could make a good argument for
> language-dependent literate programming systems.
This is probably a much better reason!
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers
email: [EMAIL PROTECTED] | you have, half your time is spent
work tel: (0117) 954-5250 | waiting for compilations to finish.