Talk:Cvlemar

Non-textual?

I'm not sure this language should be classified as non-textual. It looks to me like the graph is created from a text source file, but I could be wrong. Hopefully Zzo38 can clarify. --Rune 19:59, 15 Sep 2005 (GMT)

In what manner do you suggest a graph be represented? XML? An opaque binary format? NULL programs are stored in "text source files", but the language is still non-textual. --Graue 00:05, 16 Sep 2005 (GMT)

The Category:Non-textual description is Languages where the source code is not in the form of a text file. The NULL spec doesn't say anything about text files, only that the program is a number. But if the source files of Cvlemar are text files I don't think it should be in this category. How the program is represented internally in the interpreter is not relevant IMHO. --Rune 01:19, 16 Sep 2005 (GMT)

Yes, the graph is created from a text source file. Of course it could be something else, but in my original description the graph is put in a text file with lines in the format '(in node) (out node) (command) (parameter)'. --Zzo38 01:57, 16 Sep 2005 (GMT)

I went ahead and removed the category reference. --Calamari 21:19, 16 Sep 2005 (GMT)

You guys are so efficient it's startling. I still, personally, think the fact that a program is a graph is more interesting than that the graphs just happen to be represented textually. Anything can be represented textually, but these programs are graphs. --Graue 23:40, 16 Sep 2005 (GMT)

You have a point, but I don't think this is the right category for it. If we use your interpretation of this category, most of the languages in it already wont fit in, as they are simply a regular esolang (mostly BF-deriavtives) where the source code happens to be an image. I think we should stick with this category dealing with the source code format, and instead add a new category for languages with this kind of topology. Cvlemar doesn't really fit in with the 1D, 2D and multi-D categories which deals with the topology of the language.--Rune 01:31, 17 Sep 2005 (GMT)

Circuit/dataflow paradigm?

This language reminds me of electric circuits, or those visual dataflow languages where data flows in and out of nodes, but more imperative. The behaviour is a bit underspecified. How are signals synchronized - is there a specified ordering that signals must follow to avoid incorrect intermediate signals? Rdococ (talk) 11:51, 26 December 2022 (UTC)