> I didn't like some of its design choices, e.g. how iteration and conditional statements are done is overly complex. There are natural ways of doing these in dataflow which LabVIEW doesn't use.
would you mind elaborating? i would be interested to see what you mean. if you are thinking of more functional ways like maps, filters, folds, and the like, i have done that in labview. there is limited support though since labview doesn't have lambdas, but you can pass around functions. however, that being said, i don't really see a problem with the for and while loops in labview, and i can't see how they are overly complex. they are about as simple as it gets. condition structures could be improved, but i also don't quite see a vastly different way to do it but rather tweaks that could be made.
> Also, type inference is actually simpler to implement in visual dataflow than it is in text-based languages, yet LabVIEW lacks it
i am not for sure what you mean here by saying labview doesn't have type inference. labview is constantly running a type propagation algorithm that checks whether all the types are hooked up correctly. additionally, labview has malleable VIs, which is even more advanced. you can develop functions that are polymorphic across types. you could do this before malleable VIs using polymorphic VIs, but you had to manually create them. now, when wiring a type to a malleable VI, labview will dynamically (at edit time) adapt the malleable VI's types, primitives, and subVIs to adopt the new type. if it can't, it will warn you. you can also wrap code with a type structure such that different code is tried depending upon the type. again, it will check if a wired up type has a given structure case that fits. it is similar to pattern matching on types.
> Finally, every dataflow program is a directed graph, which is the most general data structure there is, so it really ought to be a fundamental data type - like Lisp's S-expressions are.
i agree that there should be a more fundamental type. i am not aware of any language that does so, and even in the text-based world, lisp and scheme stand alone in this feature (not surprising i like those languages as well).
The pages are incomplete as I've since added new functionality to the language. I'm working alone, and have other commitments, so progress is quite slow. It's a research project, and I'm not planning any release until I'm happy with the language, and enough other people are sufficiently interested.
For iteration and conditional statements, FMJ doesn't require any separate constructs or use syntactic sugar. Iteration is done by feedback, when and unless by conditionally outputting other inputs depending on the value of the first input.
My aim was to build a language capable of running directly on hypothetical dataflow hardware, with the minimum of syntactic sugar, and I've mostly achieved that. I'm now looking at problems for which dataflow machines would be better suited for than conventional hardware, and by implication that dataflow languages are better suited for than conventional languages. I'm also looking for ways of reducing clutter (edges crossing), which is a problem with graphical languages.
Regarding directed graphs as a fundamental data type, I haven't done much in that regard yet, but it's high on my list of priorities.
would you mind elaborating? i would be interested to see what you mean. if you are thinking of more functional ways like maps, filters, folds, and the like, i have done that in labview. there is limited support though since labview doesn't have lambdas, but you can pass around functions. however, that being said, i don't really see a problem with the for and while loops in labview, and i can't see how they are overly complex. they are about as simple as it gets. condition structures could be improved, but i also don't quite see a vastly different way to do it but rather tweaks that could be made.
> Also, type inference is actually simpler to implement in visual dataflow than it is in text-based languages, yet LabVIEW lacks it
i am not for sure what you mean here by saying labview doesn't have type inference. labview is constantly running a type propagation algorithm that checks whether all the types are hooked up correctly. additionally, labview has malleable VIs, which is even more advanced. you can develop functions that are polymorphic across types. you could do this before malleable VIs using polymorphic VIs, but you had to manually create them. now, when wiring a type to a malleable VI, labview will dynamically (at edit time) adapt the malleable VI's types, primitives, and subVIs to adopt the new type. if it can't, it will warn you. you can also wrap code with a type structure such that different code is tried depending upon the type. again, it will check if a wired up type has a given structure case that fits. it is similar to pattern matching on types.
> Finally, every dataflow program is a directed graph, which is the most general data structure there is, so it really ought to be a fundamental data type - like Lisp's S-expressions are.
i agree that there should be a more fundamental type. i am not aware of any language that does so, and even in the text-based world, lisp and scheme stand alone in this feature (not surprising i like those languages as well).