 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/14/2012 4:52, clipka wrote:
> I guess you've heard of code re-use through delegation, no?
Then every type of screen item has to delegate that call to something else,
and every time the superclass adds a function, then all subclasses have to
write code to delegate it properly.
If you automate that process, guess what you just invented?
> I do agree that at least inheritance among interfaces would be nice to have,
I don't know of any language that implements inheritance and interfaces that
doesn't allow interfaces to inherit. Quite honestly, that would make almost
no sense.
--
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:15, Warp wrote:
> clipka<ano### [at] anonymous org> wrote:
>> As current widespread belief is that virtually all multiple inheritance
>> use cases can be covered with the interface approach, it seems to make
>> sense to avoid this extra overhead.
>
> Only if you don't mind the need for code repetition with interfaces.
I might have asked this before, but do you have any good (hopefully generic)
examples of where MI really helps out?
--
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:40, Invisible wrote:
> So if a class tries to implement both interfaces, it can't provide different
> implementations for these two distinct methods merely because their names
> clash?
That depends on your language. Java? I don't think so. C#? Definitely. But
then you can't invoke the interface call without specifying which one you
mean, so there's no ambiguity.
> According to the Great Language Shootout, C# Mono is 3x slower than C. (Then
> again, Haskell is 2x slower...)
So, an open source clone is slow, thus the version Microsoft uses that
compiles down to optimized native code must be also?
>>> Arguably you could have the compiler detect where dynamic binding is
>>> and is
>>> not needed. That requires whole-program analysis, however.
>>
>> That's what Eiffel does.
>
> Sure. Because Eiffel doesn't support dynamic linking.
Yep. That's what (for example) Sing# does too.
>> Sure there is, because you recompile the code while it's running.
> That sounds remarkably hard to get right...
No harder than compiling it in the first place while it's running. Why is it
harder to re-JIT than to JIT?
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
