>> So what application logic problems aren't solved by Haskell then?
>
> Operating on mutable lists (or whatever it was you tried back then, and
> ran into a set of libraries that all did it in a different way
> unsuitable for your needs so you resorted to a rant), for instance?

Haskell's library support for mutable arrays is a mess. But we're still 
talking about bad library design, not bad language design.

>> The purpose of a library is to make stuff easy, after all...
>
> Still, not every library succeeds in that job to a degree that it can be
> called "simple and elegant". And sometimes that's not due to design
> flaws in the library, but due to the underlying language standing in the
> way.

Sure. And my argument is that if a language is designed well, you can 
use it to write powerful libraries which are simple and easy to use. 
(And if a language is designed poorly, you often can't do that.) Hence 
why good language design is so important.

>> If C is so great for writing operating systems, where are there so many
>> different, incompatible operating systems? :-P
>
> Because there's no such thing as a simple, elegant cover-it-all, maybe?

Most of this stuff is due to social, organisational, economic and other 
reasons, not language design.



Your core argument appears to be that a useful programming language 
necessarily has to be badly designed. I reject that. The fact that all 
of the widely used languages are badly designed doesn't mean that bad 
design is a necessary attribute.

Post a reply to this message

On 8/14/2012 1:06, Invisible wrote:
> My point being that everybody acts like "oh, of /course/ you can't possibly
> do that", when in fact you can.

You can't possibly do it in a language where you are actually declaring your 
types. You *can* return types that are private or anonymous. You just can't 
declare a function that returns a private type.

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

On 8/14/2012 3:17, clipka wrote:
> If you want to give such guarantees, you can't handle variables of types for
> which you have no declaration, because obviously you can't tell whether they
> can do A, B, C and D or not.

To be fair, I suspect Haskell just treats that declaration as if you're 
returning Object in C#. In other words, haskell I suspect doesn't let you 
return a value whose type you can't see, but instead of making that illegal, 
it essentially inserts a cast for you to an opaque supertype. (So to speak, 
of course, since Haskell isn't OO.)

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

On 8/14/2012 3:46, Invisible wrote:
> ...and yet, in my Haskell snippet, a type is not exported, yet still you can
> convert it to a string, because that interface is implemented.

Then you've exported the interface, not the type. C# can already do that.

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

On 8/14/2012 5:57, Invisible wrote:
> So what do you think Haskell solves inelegantly?

Does it do hierarchies of types (like windows) nicely, where you don't have 
to go back and fix every use of an object when you add another one to the 
hierarchy?

Does it interface well to low-level stuff without having to write wrappers?

Does it handle threads running on various address spaces (i.e., distributed 
processing) well?

How is it on the code generation part? Can you write programs that emit code 
that it then loads back in? Can you write programs that notice your SQL 
schema has changed and modifies the running program to account for that?

Can you compile and distribute Haskell code, let other people use it, and 
then release new object code that is compatible with the existing code 
people already wrote and compiled without breaking things? If John writes 
code and releases the object code, then Mary subclasses that, and you're 
using Mary's object code in your program, does John releasing new object 
code require you to get Mary to help you use John's new code?

How elegantly does it interface to dynamic languages like javascript?

How elegantly does it handle the types in SQL tables? Stuff like nullable 
big decimals? Strings in various locales?

How easy is it to parse and compile, such that you could do so on a 
keystroke by keystroke basis? When you make a mistake, is it easy for the 
compiler to pinpoint where you made the mistake? Is it easy for the IDE to 
know when it's safe to recompile the code or whether you're still typing?

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

Am 16.08.2012 01:00, schrieb Darren New:
> On 8/14/2012 1:06, Invisible wrote:
>> My point being that everybody acts like "oh, of /course/ you can't
>> possibly
>> do that", when in fact you can.
>
> You can't possibly do it in a language where you are actually declaring
> your types. You *can* return types that are private or anonymous. You
> just can't declare a function that returns a private type.

Or, more precisely, you can't declare a /non-private/ function that 
returns a private type.

Post a reply to this message

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

On 8/14/2012 4:19, clipka wrote:
> That's quite a stupid thing to do, because you then can't tell at
> compile-time whether some other function expecting a parameter of type "Bar"
> actually gets passed such a type when using (in C++ style pseudocode):

I think the problem is more that Haskell is functional rather than OO, so 
the stuff people do by having private classes in OO languages is stuff 
Haskell does by having opaque types. So instead of
    f.x()
accessing the private values inside f, in Haskell you write
    x(f)
at which point you want to be able to pass around an "f" without being able 
to look inside f.

So it's Andrew's category error, mapping the wrong concepts onto what he 
already knows.

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

On 8/14/2012 7:16, Invisible wrote:
> Well, you're right in that you cannot write any code which explicitly
> expects Bar. You can pass the result to any function that works with /all/
> types, or any function that works with any showable type. If the module
> exported some functions that expect Bar as input, you can pass the result to
> them. But you can't write that in a type signature, which... yeah, is a bit
> silly.

That's what I was saying. You can't return type Bar if you haven't made it 
exposed. You can declare that foo returns a Bar, but you can't actually use 
Bar. It gets the equivalent of being upcast to "object" or to whatever 
interface you've defined it to be. So the fact that you can't return an 
opaque Bar is no hinderance - declare foo to return the appropriate 
interface or Object.

> My point wasn't so much that this is a something anybody is likely to want
> to do. My point was a counter-example to the "that's obviously impossible"
> argument. It's /not/ impossible at all.

By that reasoning, it's possible to do it in C#:

return (Object) Bar;

return (Showable) Bar;

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

On 8/14/2012 1:32, Invisible wrote:
> On 14/08/2012 02:01 AM, Darren New wrote:
>> It's an excellent OO language that expects to have runtime and OS
>> support around.
>
> ...and yet, they claim it can be used for embedded systems, which don't even
> /have/ an OS?

You can use Sing#, which is apparently just like C# except with extra stuff.

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