6

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

gnat
  • 21,442
  • 29
  • 112
  • 288
TimothyP
  • 233
  • 3
  • 8

3 Answers3

5

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

Pete
  • 8,916
  • 3
  • 41
  • 53
  • 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. –  Jan 02 '13 at 11:09
  • 3
    @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 02 '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 02 '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 02 '13 at 15:25
  • Eric Lippert has an [article](http://blogs.msdn.com/b/ericlippert/archive/2007/12/10/immutability-in-c-part-four-an-immutable-queue.aspx) 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 02 '13 at 22:37
  • 1
    For reference, the book that is being referred to: http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf – TimothyP Jan 03 '13 at 15:38
  • 2
    I disagree with the advice that C# should be used over F# in case of falling back on oop and mutations. F# is way more concise and readable even for oop, and you can still do the 'dirty' oop stuff in one isolated part of your code and then code the rest in FP style.. That is the beauty of F# imo. – Michelrandahl May 10 '16 at 15:41
5

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

Jimmy Hoffa
  • 16,039
  • 3
  • 69
  • 80
  • 1
    Both answers have helped me understand the issue, but sadly I can only mark one as the answer, so +1 and thnx! – TimothyP Jan 03 '13 at 07:33
2

If you use a native queue, you can wrap it inside a MailboxProcessor, so that mutation will be synchronized across threads, without needing locks.

Dax Fohl
  • 251
  • 2
  • 5
  • I'm an idiot! I somehow missed that we were talking about data storage queues and not message queues! Good suggestion. – PhilT Feb 01 '23 at 10:17