On 8/14/2012 1:31, Invisible wrote:
> So what happens if you say "override" on a method that isn't virtual?

I suspect it's a compile-time error.

> Heh. And I thought Haskell was the only language stupid enough to claim that
> the reading the formal language specification is a good way to learn how to
> program with it...

Most languages lack a formal spec. C# gets close. Hermes actually generates 
the compiler based on the formal spec, so yeah.

>> Sure. When you load the subclass, it just re-JITs the superclass.
> It actually does that?

It would have to, if it noticed the call isn't actually virtual. Some JITs 
do it, some don't.

>> Basically, subclasses or anything compiled at the same time as this class.
> I guess it makes sense once you realise it means OR, not AND.

Yep.

>>>> Yes. Well, what would you expect? A public method that returns a value
>>>> of a type you can't see the declaration of?
>>>
>>> Haskell lets you do exactly that, yes.
>>
>> No it doesn't.
>
> O RLY?

So show me a function that returns a value of a type I can't see.

>
>> It probably lets you return an opaque reference to
>> something you can't see the type of, but I doubt it lets you return a
>> type that you can't see.
>
> module Foobar (Foo (..), foobar) where
>
> data Foo = Foo Int deriving Show
> data Bar = Bar Int deriving Show
>
> foobar :: Foo -> Bar
> foobar (Foo x) = Bar x
>
> Notice how Bar is not exported, yet foobar is exported, and its return type
> is Bar.

So you declare foobar returning an interface that support Show, which is 
what you've done.

> Remember, Haskell functions deal with known types ALL THE TIME. Any time you
> call id :: x -> x, it takes a value of unknown type, and returns it
> unchanged. So for Haskell, having some data of a type that you can't "see"
> is no big deal at all. (With the minor detail that you now can't declare
> anything as returning Bar as its result, because that name is not in scope.)
>
Well, I'm not sure how this differs from C#. Declare it returning Object, 
and you're done. That's basically what you're doing. You're saying "here's 
something, I don't know what it is, so you don't get to use it as that type, 
but as some more abstract type.

>>> I guess I'm just spoiled. In Haskell, there are precisely 2 sorts of
>>> type;
>>> everything is either an algebraic data type or a function type. C# has
>>> 5 of
>>> fundamentally different sorts of type, all with different semantics.
>>
>> Well, actually, everything's an object.
>
> Except that no, no it isn't. Apparently only values of reference types are
> considered "objects". :-P

Uhhhh, no. Everything is an object. Really. Some classes are value classes, 
and some classes are reference classes, but every value is an object.

>
> You could /almost/ say "everything's a class", except that no, we have enums
> and stuff which aren't considered "classes".

Of course they're classes. If you want, you can even look up what their 
superclass is. For example, 23 is of class System.Integer32 or some such.

>>> I especially love how enumerations are a different type but no, not
>>> really, because obviously they're actually just integers...
>>
>> No they aren't. Especially not the way Haskell defined "type". :-)
>
> Right. So enumerations aren't integers, and that's why you define the
> corresponding integer value of each case right there in the definition? :-P

They correspond to integers. They aren't integers.  I *do* think Java did 
that one much better.

> If you have real enumerations, why do you need a special-case for bool?

Because you have syntax in the language that uses specific types, like "if" 
statements. Having bool being a special enumeration is no more odd than 
having a function that accepts one specific enumeration type as an argument 
and not any generic enumeration.

> (The same argument applies to Haskell: Why the HELL did they special-case
> the list type, when you can trivially define it manually? What there they
> thinking??)

They were thinking you needed special syntax.

Hermes, for example, does not have a string type. But if you have an enum 
where each name is one character long, you can make an array of that value 
by sticking it inside quotes. Which I thought was kind of cute.

> OK, whatever. I haven't really explored it all that much yet, but it doesn't
> appear to compare well to Eiffel.


What doesn't, C#?  There are various things Eiffel does theoretically 
better, if they're actually implemented.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message