Lazy Lists in Labview

[valarauca]

Attached is a very basic Lazy List implementation in Labview. It also includes a very basic Option type (on which it requires).

 

The general idea with Lazy Lists is their contains functions are not called until consumed. This permits programmers to build massively recursive and infinite data structures. It also means if you do 15+20 operations on a list, but only inspect 4-5 elements out of say 1,000,000 then only those 4-5 elements are processed.

 

I'm likely adding on more functionality as time goes on. If your interested let me know.

 

https://github.com/valarauca/LLL

Edited November 16, 2015 by valarauca

[Yair]

For those of us not fluent in functional programming, can you expand on the thinking behind this and how you implemented this?

 

Looking at the iterator example, I understand the syntax of "map the filter function over the list", but my limited understanding is that some of the advantage of how functional language manage these data types will be mitigated by you having to go through all the variants and the VI calls, so the question is whether the syntax is worth it?

 

Some specific comments:

1. The OptionType class wire is killing me. It looks like it's broken or the screen is broken or something is broken.
2. Don't hide the examples in internal levels of the hierarchy.
3. More documentation is useful for examples where the syntax is different from what people are used to.

[valarauca]

>so the question is whether the syntax is worth it?

I understand your core complaint and share it. I'm stilling working on a generalized generic system for LV since typing metadata is technically exposed from variants themselves it *should* be possible, the problem is I don't know an easy way to do this without writing a polymorphic VI that covers _all_ LV types, which would be exhausting.

Really this is a question for each individual not myself. I enjoying using this, I find it greatly reduces what I have to think about when working on arrays. The idea of just writing a single function, and testing that out makes life a bit easier then writing to write out a long chain of for loops, or nesting 5-6 case statements deep (which I see a lot in LV codes bases).

The other suggestions will likely be done. I didn't know what the community considers _normal_ for example placement. It seemed logical to include the example with the class.

Edited November 16, 2015 by valarauca

[hooovahh]

It seemed logical to include the example with the class.

To me I don't think it does.  Being part of the class may give the VI special privileges that otherwise you wouldn't have.  Being a member might allow you to have access to private data, where you could be doing things that a user of your toolkit wouldn't be able to do, unless they modify the class.  If you have a project you don't have to have the folder structure in it, mirror you files on disk.  So some people place an examples folder in the project, which can then link to files deep in other folders.  So this is another option.  I'd suggest looking at other toolkits and code posted to get a feel for how the community organizes code and examples.

 

In LabVIEW there are about 3 or 4 ways to sorta get around the stict-ness of the language, but none of them are satisfying.  Polymorphics, generics, VI Macro, XNodes, variants all could work with varying levels of success.

 

I don't see the purpose of the OptionType class at all.  It takes a variant and turns it into a cluster of a string and an array of words, and can then reverse this...isn't this what the to variant and from variant does for you?  Your unwrap also just clears the error and doesn't pass it out.  What if there was a problem with conversion?  How will I know from using the API?

 

To help with the variants you can get the type of variant, and other information, using some OpenG functions, or the native ones in VI.lib.  Install Hidden Gems, or use 2015 which have them on the variant palette.  I suspect this can eliminate the OptionType class all together.