Re: mandatory newbie musings

[Quinn Dunkan]

Oops... I sent this to nobbi instead of the list.  Sorry!  (Bad MH!  Bad!)

> On Sun, Oct 01, 2000 at 03:13:57AM -0700, Quinn Dunkan wrote:
> > These are stdlib questions, so if the stdlib is undergoing a redesign, perh
> aps
> > they're out of date.  Still, I hope maybe my questions bear some relevance.
> > Since there appears to be no stdlib documentation, I've just been reading t
> he
> > source.  I must say that it is very clear and well-commented (looks like it
> 's
> > supposed to be used with a semi-literate document-generation system).  I ha
> ve
> > respect for a language who I can learn by reading the source after skimming
> > the tutorial once :)  The primary hairball is the whole type-safe overloade
> d
> > methods thing, which I hopefully won't have to deal with since I don't plan
>  on
> > using many overloaded methods.
> 
> Actually, that's one of the qualities of Sather: co- and contravariance 
> actually is a matter that affects any language that knows inheritance. 
> Anyway: Sather is the only language where that is really thought 
> through and well-defined.

Hmm... well, I'm not used to it because it doesn't show up in dynamically
typed languages, and the issue hasn't really come up in haskell.  Classes in
haskell define a collection of functions over a type variable.  Then an
instance of that class is a specific type and defines how its class's
functions behave this type.  You specify inheritance by restricting the type
variable of the class to be in another class, but there is no code inclusion
involved and you can't redefine the interface.  So they bear a similarity to
sather classes in that they specify only interface, and no code, but in
sather, classes and types are bundled into one concept, where they are
seperate in haskell.  One type can be an instance of several classes.  So
maybe haskell is invariant?  Dunno...  I know there are type-unification rules
for overloaded functions, but they're not very complicated.

class Food t where
    ;
class (Food t) => Plant t where
    ;

class Animal t where
    eat :: Food u => t -> u -> String
class (Animal t) => Herbivore t where
    ; -- can't redefine the type of 'eat' here

So does that mean haskell is invariant?  It doesn't become an issue in haskell
I guess because haskell uses classes for different things than sather or
eiffel.  I guess there's basically no concept of "subtyping" in haskell, just
overloaded functions that work on a certain set of types.  Inheritance just
selects within that set.

I wonder if it would be possible to use that simpler notion in an imperative
language before the FP people ruin it by fully generalizing it into a complete
type calculus with higher-order type lambdas and Rank-n polymorphism and...

My head hurts...

> Don't worry: after working with Sather for a while, you'll understand 
> what it means without really thinking about it. (Maybe not in the terms 
> of co- and contravariance, but you'll understand the concept behind it 
> - it's just natural...)

Well, I do agree that if your definition of "a is more general than b" means
"a can do whatever b can" then "the interface of a should be more general than
the interface of b" follows naturally.  But that sounds like co-variance,
since a -> b and the interfaces of a -> b are varying in the same direction,
they both get more general.

Of course, then you have to define what "more general" maps to in terms of
types... so maybe contravariance says "a subtype is more general" while
covariance says "a subtype is more specific".

But wait, now they're still both varying in the same direction, just the
inheritance trees are upside down.  I thought I understood this stuff...

Errgg... now my head *really* hurts.

My intuition tells me that any attempt to organize types into a DAG of
generality vs. specificity and maintain correctness is inherently doomed
because there is nothing in the real world from preventing as-a relationships
from going in circles.

If so, the mathematicians must have given up on it a long time ago...

> > Firstly, I had a bit of trouble compiling 'sacomp'.  First of all, the
> > documentation is a bit inaccurate (it says the default make rule makes
> > optionals, which it doesn't, and it seems to want to bootstrap even if you
> > already have Boot/sacomp.code/), although it does warn about "outdated" :)
> 
> Sorry - still trying hard to get that straight... :-(

It's ok, I worked it out.  If it's any comfort, my initial attempts to compile
SmallEiffel resulted in parse errors on the generated C, which later
disappeared for absolutely no reason.  At least I understand why sacomp broke
:)  And SmallEiffel has this wacky non-standard build process that makes it
more difficult to track down what's actually *happening*.

> Correct: gcc optimization is buggy. I don't know where the bug is 
> located and which versions show it. Just today, I worked ~2 two hours 
> on a bug before I realized that it was caused by just the same thing 
> again. -O is the best workaround known...

Don't you just hate that...  the first thing I do with a mysterious segfault
is compile with -g.  And then it goes away!  Arrrghhh.  Maybe if I decide life
has gotten too sane one weekend I'll try to track down which generated source
file it lives in, if it indeed lives in one file, and not the magic
combination of them all (more likely).  And first go download the latest gcc
snapshot and see if it's still there :)

> Guess it's covered by the new library. Look somewhere at
> 
>     ftp://alpha.gnu.org/gnu/sather
>     
> for the 1.3-beta-2 version. Don't know whether it compiles, but at 
> least you can look at the code. 1.3-beta-3 is just idling around on my 
> machine here. I hope to get it to compile soon to get it uploaded.
> 
> It the issues are not covered there, go discuss it with Keith Hopper, 
> the main author of the new library.

I'm looking now and I still have questions... does he read this list?  Keith,
are you there? :)  If not, and if he's the *only* person working on the
library, I'll just email him.