>> 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.

C# is supposedly an ISO standard, so there must be a published 
specification for it. However, while the spec is the thing you want to 
read if you're building a new implementation (e.g., Mono), it's usually 
an utterly lousy way to learn how to actually /use/ a programming language.

(Although, as I discovered, the C# "spec" actually reads more like a 
tutorial, so...)

> So show me a function that returns a value of a type I 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.

It still works if you take Show out. (Although in that case it becomes 
even more pointless.)

My point isn't that this is a useful thing to do. It's just that it 
doesn't necessarily /have/ to be impossible. C# /chose/ to make it 
impossible - a not unreasonable choice, but not the /only/ choice.

>>> 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.
>
>> 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.

According to the spec document, any value of a value type is not 
formally referred to as an "object"; that term is reserved for values of 
reference type. Similarly, the term "class" is reserved to refer to 
types declared with the "class" keyword.

Of course, with the C# unified type system, all types /behave/ as 
classes in the usual OO sense (which is the point you're making). It's 
just that the C# language spec does not /call/ then classes.

>> 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.

What, by not having enumerations at all?

>> 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.

Haskell has special if syntax, and yet Bool is defined in library code.

>> (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.

You need special syntax for integers, and yet anybody that wants to can 
define a new integer type. (E.g., I wrote a library that lets you deal 
with "half integers" - numbers which are integers when multiplied by 2.)

What they /should/ have done is let you use what is now "list literal 
syntax" for /any/ suitable container type. Unfortunately, they didn't.

And what's with [Int], anyway? Would List Int just be too readable?

> 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.

Nice. :-S

>> 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.

I doubt Eiffel has half as many libraries as C# though. Like most 
well-designed languages, it never really took off.

(I'm guessing C# took off because it's explicitly designed to look like 
one of the other badly-designed languages which is already wildly 
popular...)

Post a reply to this message