Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I need something that represents a queue in F#.

The queue will be filled with items once, and (as the application progresses) items will be taken from this queue and moved to other lists.

Should I use the Queue class in .NET, or should I avoid it, and use the native lists in F# instead? Is there a better solution?

Why should I use one, or the other, in a functional language such as F#?

share|improve this question
1  
System.Collections.Generic.Queue<T> is mutable. Your application does not append to it. Do you have other reasons to use it? –  bytebuster Jan 2 '13 at 10:00
    
No, have no reason at all... it's a purely theoretical question –  TimothyP Jan 2 '13 at 12:44

2 Answers 2

up vote 4 down vote accepted

If you are creating a class library to be shared with other .NET applications, and this is part of the public interface, then you should stick with normal .NET class library types.

If you are sticking solely to the F# domain, or this is part of the private implementation details, I would prefer to use native F# types.

In your case however, the F# list does not correspond to a Queue, at least not a FIFO queue (first in, first out). The F# list corresponds to a stack (last in, first out).

I'm not aware of a native F# data type providing that functionality, and in fact, the the queue data type does not sit well with the purely functional programming paradigm (I'm not an expert on functional programming so perhaps someone will prove this statement wrong).

So the big question on how to solve the problem is really, is your problem well suited to the functional programming paradigm? If so, you should avoid using imperative data types such as queues, and try to solve the problem using purely functional data types.

If your problem on the other hand is not well suited to a functional programming paradigm, perhaps you should not use F# at all, but use a more object-oriented programming paradigm. Not that F# cannot do object oriented programming, because it can. But if that it is the general programming paradigm, it is IMHO easier to use e.g. C#.

share|improve this answer
3  
RE sitting well with purely functional programming: There are multiple persistent queues that perform reasonably well (cf. Okasaki's Purely Functional Data Structures). They're not trivial to implement and understand though. –  delnan Jan 2 '13 at 11:09
1  
@delnan Persistent queues are indeed complicated. But if all you want is a non-persistent queue with amortized O(1) operations, that's quite simple to do: Have an input list and an output list. If you're trying to take from the output list and it's empty, reverse the input list and use that. (And yes, the various approaches are explained in detail in Okasaki's book.) –  svick Jan 2 '13 at 12:24
    
There's no real application involved, just playing to learn. In this case I'm writing a little game which greatly benefits from distinct unions and pattern matching... would be a huge pain to write it in c#. Let's say the queue contains something like cards, but where there are a lot more variations than 52 cards. –  TimothyP Jan 2 '13 at 12:42
    
@delnan Thinking of Okasaki's when I read this answer made me agree with Pete. Okasaki's is in my mind, proof to Pete's point that the queue data type isn't exactly native to functional programming in the same way a binary tree, a stack, or a tuple is etc. –  Jimmy Hoffa Jan 2 '13 at 15:25
    
Eric Lippert has an article describing how to implement an immutable queue in c#. I am unsure how much effort it would take to convert this algorithm to f#. However, I think his implementation strategy is somewhat in line with F# style code. –  Brian Jan 2 '13 at 22:37

@bytebuster made a comment above that got me to thinking.

The .NET's Queue<T> is mutable, and undoubtedly has a standard OO implementation which has guaranteed O(1) for enqueue and dequeue.

Okasaki's being the standard best-performance immutable functional version of a Queue and not having the same guarantee, perhaps you could apply this rule to your usage in F#:

If the correct data structure is a Queue for your problem, and performance is important (though if it's not for you, it may be important for your consumers, so worth thinking about then as well), stick with the .NET mutable Queue.

Also however I agree with the other answer here, if it's a method signature to be used by other .NET languages, use the common .NET Queue<T>

If performance is irrelevant and it's not to be used by other .NET languages, I guess it would be safe to say it's up to you whether or not you want to implement a functional Queue in F# to use or just stick with the .NET implementation.

share|improve this answer
    
Both answers have helped me understand the issue, but sadly I can only mark one as the answer, so +1 and thnx! –  TimothyP Jan 3 '13 at 7:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.