Re: C# equivalent of some SML code
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Sat, 02 May 2009 12:00:49 -0700
On Sat, 02 May 2009 06:58:08 -0700, Jon Harrop <jon@xxxxxxxxxxxxxxxxx> wrote:
[...]
I tried defining an IQueue interface that all queues could implement in
order to expose their commonality and allow them to be interchangeable. But
the interface's members need to be parameterized over both the type of
elements and the type of queue because they have members like:
method PushBack : 'a -> 'a queue -> 'a queue
The latter cannot be expressed in terms of the former so you end up with an
ugly and inexpressive:
IQueue<ELT, QUEUE>
Why do you end up with that? What's wrong with:
class MyQueue<T> : IQueue<T>
{
MyQueue<T> PushBack() { ... }
}
interface when you really want is a recursive type parameterized *only* over
ELT:
IQueue<ELT, QUEUE> as QUEUE
Type parameters can be constrained recursively, but it's unusual to need to do so. With such a vague question, it's hard to know whether you're in a situation where you need to do that.
Furthermore, the queues provide a static value representing the polymorphic
empty queue which hits two more limitations of .NET:
. Apparently you cannot put anything static in an interface.
. .NET has some kind of value restriction that means this value must be
replaced by a function that creates empty values for each element type.
I believe I am getting closer to a working implementation of queues but it
is horrific.
How would you implement a set of compatible purely functional queue
implementations in C# such that you could parameterize other data
structures over them?
Am I correct in assuming that none of the existing collections in .NET have
members that return another collection of the same type?
No, that's not a correct assumption. See the Enumerable extension method class for one obvious example (not a collection class per se, strictly speaking, but it's the same pattern you're describing).
Also, see Eric Lippert's blog entries on immutable types, including queues and lists. I'm sure Google can find them for you as easily as it would for me.
Beyond that, your post is fairly vague and includes no actual example code to describe what you're talking about. I don't know if it's simply that you're not descriptive enough, or perhaps at least some of the statements would be less vague to someone with a strong functional language background. But either way, you need to consider your audience better if you expect to receive useful answers. There's very little in your post that seems to have a direct answer relevant to C#.
Depending on your exact needs, if you want a static member of something that's like an interface, you may be able to use an abstract class (which acts like an interface but also can provide implementation, so you can include static members).
The fact is, your requirement that the _interface_ provide a "static value representing the polymorphic empty queue" just seems wrong to me, at least in a language like C#. The strong typing in C# precludes the idea of a single instance that is compatible with arbitrary type parameters for a generic type. C# 4.0 will include some support for variance with generics, so it's possible that if you can restrict your queue type parameters, you can support a base-type implementation of the interface from which you can get such an "empty queue" instance, depending on exactly what you're trying to do.
As for ".NET has some kind of value restriction", again...without a code example, it's impossible to understand what you're talking about. What "kind of value restriction" are you referring to? Assuming you could come up with an instance that properly represents your "empty queue" value, why could you not have that instance be stored as the static value member for the value? What exactly are you trying to do, what code is working for you, and why is that code different from the code you would like to have written?
Hint: "horrific" is not a technically precise term.
Pete
.
- Follow-Ups:
- Re: C# equivalent of some SML code
- From: Jon Harrop
- Re: C# equivalent of some SML code
- References:
- C# equivalent of some SML code
- From: Jon Harrop
- C# equivalent of some SML code
- Prev by Date: Re: Newbie: how to create an object "on" another object
- Next by Date: Re: Reverse (Mirror) Binary Number
- Previous by thread: C# equivalent of some SML code
- Next by thread: Re: C# equivalent of some SML code
- Index(es):
Relevant Pages
|
Loading
