Rename the "Enqueue Element At Opposite End" Queue primitive as "Enqueue Element At The Front"

[parthabe]

The title says it!

It is often confusing "Which is the opposite end in a queue?/What does opposite end mean?", esp for new user of LabVIEW. 

Seems here, even the author of the LV Queue primitives was not able to recollect its name correctly. 

Also, please see below from the LV Help. 

[AristosQueue (NI)]

> the absence of a true deque implementation.

Why do you need a deque? What algorithm uses that? I'm honestly interested. I've never seen an algorithm that calls for it.

The old queue API, the VI-based API that the primitives replaced, had that function. That was *deliberately* left out of the primitive API. That function had the major downside of hurting performance of the entire implementation because of the wake up overhead on both ends of the queue, and it just created confusion among users when some framework shared a queue refnum about whether it was supposed to be used forward or backward. (That isn't a problem with the single enqueue at opposite because stacks aren't typically used for communication... they're isolated within the function that created them.) I didn't push back on it because I had never seen the use case for a deque. Still haven't -- you're the first person that I can remember in 15 years to request that feature (maybe someone requested it early on when we removed the old API, but if so, I don't recall).

[Baji]

Good catch Partha.

[altenbach]

> My suggestion would be "Queue (F)/Stack (T)", where Stack means insert (add) element at the front (today's Eneuque at the Opposite End).

The queue/stack distinction is a combination of insertion and removal (FIFO vs. LIFO) so it cannot be attached to only one of the operations (typically, the dequeue does not know how the removed element was added, causing ambiguities).

We are dealing with "QUEUE" primitives, so anything outside the norm (e.g. opposite end) should be the rare exception.

One possibility would be to create a new set of primitives that operate as a Stack (=LIFO Queue)  (i.e. a seperate "Stack operations" palette), but I am not sure where this is useful except for RPN math and such. 😉

I see the point of abusing "opposite end" as priority. Personally, I have never used it.

[drjdpowell]

Queuing things that should really be stacked seems to me to be a common design flaw in many LabVIEW arcitectures (including NI ones).  Having the concept of a "stack" be more visible to LabVIEW programmers might be a good idea.

[parthabe]

drjdpowell - "Having the concept of a "stack" be more visible to LabVIEW programmers might be a good idea."

Yes! Especially, when you start designing Undo-Redo like features for our customers. 

[AristosQueue (NI)]

> drjdpowell - "Having the concept of a "stack" be more visible to LabVIEW programmers might be a good idea."

I agree. We should have a by-value array with polymorphic "push" and "pop" nodes that add and remove from the ends of the array, distinct from Build Array and Delete From Array, ideally wrapped inside a class in order to have amortized growth of the array stack and prevent operations on the middle of the stack entirely.

In fact, it should look just about exactly like this did:

http://forums.ni.com/t5/NI-Labs/Welcome-to-quot-LabVIEW-Generic-Container-Map-quot/td-p/557928

Unfortunately, the download attachment is lost. If anyone knows where to download it, that would be lovely. I lost my personal copy and the author left the company. Silly me for relying upon the cloud. *rolls eyes*

[Manzolli]

I'm a non native English speaker. For me the name is fine, easy to understand. The only problem is the length, if this is a real problem.