Re: C# equivalent of some SML code
- From: Jon Harrop <jon@xxxxxxxxxxxxxxxxx>
- Date: Sun, 03 May 2009 22:21:51 +0100
Peter Duniho wrote:
On Sun, 03 May 2009 12:15:06 -0700, Jon Harrop <jon@xxxxxxxxxxxxxxxxx>
wrote:
Peter Duniho wrote:
On Sat, 02 May 2009 06:58:08 -0700, Jon Harrop <jon@xxxxxxxxxxxxxxxxx>
wrote:
IQueue<ELT, QUEUE>
Why do you end up with that? What's wrong with:
class MyQueue<T> : IQueue<T>
{
MyQueue<T> PushBack() { ... }
}
The PushBack member should come from the (abstract) IQueue interface in
which case it cannot have a (concrete) return type like MyQueue. If it
did,
all concrete queue implementations would have to return objects of the
class MyQueue which is obviously not the desired behaviour.
Fine. Make the return type IQueue<T> instead and put the method in the
interface.
In fact, that mistake hits upon the core of this problem and I have now
resolved it.
What mistake?
Putting MyQueue as the return type (which is what we want but .NET cannot
express).
Essentially, .NET is incapable of expressing the compile-time
techniques that the SML code relies upon.
Such as?
The ability to express this factoring without incurring dynamic (run-time)
overheads.
The only alternative is to move
everything to run time and that injects a lot of unnecessary checks and
dispatches. I now have a working translation but it is 5x slower on .NET
compared to OCaml (and MLton is probably much faster still).
C# is a strongly, statically typed language. If you have techniques that
rely on dynamic techniques, then yes...C# isn't going to be appropriate
for you. What a surprise.
This is a limitation of .NET's type system that C# inherited. The only known
workaround in .NET languages today is to resort to dynamic techniques that
are slow and fragile. I don't want to do that for obvious reasons.
Hint: "horrific" is not a technically precise term.
100 lines of SML code becomes over 600 lines of F# code and runs 5x
slower.
Why is F# relevant here? This is a C# newsgroup.
For the purposes of this discussion, there is no difference between C# and
F# because they both inherited this same limitation from .NET's type
system. If anything, a C# solution would be even longer than the F# and
just as slow.
This was actually a very educational exercise and I'd recommend trying to
translate Okasaki's code for anyone who wants to learn about the
limitations of OOP.
The fact that you use the word "limitations" simply proves your bias.
This is a known limitation of the .NET type system according to the people
who designed it. That is a fact, not a bias.
Assuming there is some difference you're unable to resolve (which frankly,
has not been demonstrated here yet), it's not so much a "limitation" as
simply a different way of approaching the problem. Each language and
programming paradigm has different things it supports and things it
doesn't.
Other languages can solve this statically with no run-time overhead
whatsoever. C# and F# cannot solve it statically at all and force the
programmer to resort to dynamic techniques with run-time overheads
everywhere instead.
Frankly, so far all I see in this thread from you is the same troll-like
behavior you've engaged in in the past. Lots of vague statements about
how .NET and C# are inferior, without any specifics to support the
statements, never mind anything that approximates an actual on-topic
discussion.
More recent posts from you in various forums had led me to believe that
you'd toned down your attitude and that you were more willing to engage in
productive discussions. I admit, after this exchange I'm not sure I was
right about that.
Please don't bother replying to any of my posts again, including this one.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
.
- Follow-Ups:
- Re: C# equivalent of some SML code
- From: Peter Duniho
- Re: C# equivalent of some SML code
- References:
- C# equivalent of some SML code
- From: Jon Harrop
- Re: C# equivalent of some SML code
- From: Peter Duniho
- Re: C# equivalent of some SML code
- From: Jon Harrop
- Re: C# equivalent of some SML code
- From: Peter Duniho
- C# equivalent of some SML code
- Prev by Date: Re: Do I have to check RowState Detached
- Next by Date: Re: Invoking method with generic parameters
- Previous by thread: Re: C# equivalent of some SML code
- Next by thread: Re: C# equivalent of some SML code
- Index(es):
Relevant Pages
|
