nicolas-p / skov

A visual programming environment.

Skov

Skov is a visual programming environment based on Factor.

A functional program can be thought of as a tree (actually a graph) in which functions are connected together on several levels. Commonly used programming languages have to make more or less compromises to represent this tree as a one-dimensional stream of text. Skov uses a visual, two-dimensional representation to display the tree direcly. This makes the program easier to read and to reason about and reduces the risk of making mistakes. Skov lets you see a functional program as it really is.

Skov means forest in Danish because Skov contains a lot of trees.

More information on the website.

Building Skov from Factor

• Download this repository
• Download a Factor binary package from the Factor website
• Extract the factor directory from the package (if you were already using Factor, don't use the factor directory you already had, make a new one)
• Move or copy all the contents from the Skov repository into the factor directory
• Drag and drop the make-skov.factor script onto the Factor application

Binary downloads

Binary downloads are available in Releases.

Typeface

Skov uses the Linux Biolinum typeface. On Windows and Linux you will need to install it on your system. You will find it in this repository under misc/fonts.

skov's Issues

Cannot export code

The answer to the last "FAQ" question "How can I share ...?", says "If you press Ctrl-D, Skov will export ...". I have tried both Ctrl-D and Cmd-D on my Mac, but nothing gets exported into the work folder. I hope this can be fixed, as it is quite critical.

Interfacing directly with the compiler

Oh shit!

I've just discovered that the tree representation I've created recently to export/import code is almost exactly the same as the one Slava created for the Factor compiler.

Take this bit of Skov code:

I export it as:

{ word-definition "test" {
    { definition-input "seq" {
        { output "seq" 0 }
    } }
    { word "reverse" "sequences" {
        { input "seq" 0 }
        { output "newseq" 1 }
    } }
    { word "suffix" "sequences" {
        { input "seq" 1 }
        { input "elt" 2 }
        { output "newseq" 3 }
    } }
    { word "5" f {
        { output "number" 2 }
        { special-input "invisible connector" f }
    } }
    { definition-output "seq" {
        { input "seq" 3 }
    } }
} }

And typing this in Factor:

[ reverse 5 suffix ] build-tree .

gives:

V{
    T{ #introduce { out-d { 8105341 } } }
    T{ #call
        { word reverse }
        { in-d V{ 8105341 } }
        { out-d { 8105342 } }
    }
    T{ #push { literal 5 } { out-d { 8105343 } } }
    T{ #call
        { word suffix }
        { in-d V{ 8105342 8105343 } }
        { out-d { 8105344 } }
    }
    T{ #return { in-d V{ 8105344 } } }
}

So definition-input is called #introduce, definition-output is called #return, input is called in-d and ouput is called out-d but it's almost exactly the same structure, with numbers given to inputs and outputs to know how they are connected.

I've just reinvented the same thing! *

Currently, to run Skov code, I generate a line of Factor code like this:

FROM: sequences => reverse ; FROM: sequences => suffix ; USE: locals 
IN: scratchpad 
:: test ( seq -- seq ) seq :> #0 #0 reverse :> #1 5 :> #2 #1 #2 suffix :> #3 #3 ;

which is then parsed by Factor and turned into the tree shown above.

So I have a nice tree, I convert each element to text, I concatenate everything, then Factor parses that, several things happen, the initial tree is re-built and the compiler compiles it. I think I could factor several of these steps out.

The only problem I see at the moment is lambdas. If I run build-tree on something that has a lambda in it, it gives me a horrible thing. I guess there is a simpler representation at some point, though.

But really, if Skov code could be fed almost directly to the compiler, this would be a super clean implementation.

---

* By the way, I've had another brilliant idea! What about a round piece of wood that would be installed by pair under a carriage so you can move it more easily? I'll work on that...

subseq? not swap subseq?

Hi,

I pushed a (breaking) change to the development branch of Factor that swaps the arguments for start, start*, and subseq?. You have a couple swap subseq? that should just be subseq? now.

It's more natural, but it does create a backwards compatibility problem in a relatively common word.

Thanks,

Error horizontal-scroller-left.tiff

In windows 7 with factor-windows-x86-64-0.98, there is error:
horizontal-scroller-left.tiff

Introducing New Skov

I spent the last three months doing massive changes in Skov.

One of my original principles was that it should be as easy to reuse a result several times as it is to use it only once, hence the use of the common 'nodes-and-wires' approach. If you want to connect the output from one node to the input of another node, you draw one wire; if you want to connect the output to two different inputs, you just draw two wires.

I progressively realised that this is bad for two reasons:

• it is super hard to place the nodes automatically when they can have wires going to any other node anywhere in the graph (the graph layout algorithm has been by far the hardest thing to program in Skov)
• when you start to have two or three nodes that are each connected to two or three other nodes elsewhere in the graph, it becomes hard to read, you have to follow the wires to understand what the code is doing

So now one node can send its data to one other node only. To reuse a result in several places, you have to name it, and use the name in several places (what almost every programming language is doing). This is a betrayal of my original principle that I mentioned above but the benefits are huge. We don't have a graph structure anymore but a tree structure. Instead of being very hard to layout automatically, it becomes trivial. Everything becomes simpler to manage, including import/export to text files.

New Skov looks like this:

I will publish a new binary release very soon. In the meantime you can build Skov from Factor yourself by following the instructions in README.

Two features that were present in Old Skov have yet to be re-implemented:

• word completion: pressing TAB to complete a word will not do anything, and if two words in the system have the same name, you won't be able to choose which one you want
• objects: it's impossible to define your own objects, or to use constructors, accessors and mutators

These will have to wait for the next release.

Skov is not a signed app on macOS

This happens when I try to open the Skov.app by double tapping.

“Skov.app” is damaged and can’t be opened. You should move it to the Trash

macOS 10.12.1 (Sierra)
Skov.app bundle version is 2016-11-25

---

I found skov via this reddit post. It looks awesome.

Visual programming languages interests me a lot. I'm the author of a somewhat different language homepage.

Introducing Skov

@mrjbq7, @erg, @bjourne,

I am starting a new project based on Factor. Skov is a visual (or graphical) programming system where programs are represented by graphs. It can be thought of as a visual Lisp.

I had been thinking of a visual Lisp for some time because Lisp programs are trees and I thought that trees could be displayed better in a graphical form rather than as text. At the time, I hadn't understood all the advantages of this so I didn't pursue the idea.

In early August, I realised that Lisp, Factor and Rebol, three very powerful languages, are all solving problems present in the other two while introducing new problems. They are sort of circling around an ideal without being able to get there. Lisp explicitely shows the structure of the program, at the cost of lots of parentheses. Factor and Rebol don't need the parentheses but the structure of the code is lost. The structure has to be recreated by the compiler and by the programmer's brain. Each word has to take a fixed number of arguments and the compiler and the programmer have to know the number of arguments taken by each one. Factor is written in the order of execution, which allows it to pass data between words without the need for named arguments. The drawback of this is the profusion of maddening stack sufflers. Lisp and Rebol don't need stack shufflers but they require the programmer to give names to everything. This prevents fine-grained refactoring, which is also limited in Factor by the need to write stack effects. What prevents Lisp, Factor and Rebol from reaching the ideal is text-based input.

I realised that it is not possible to have a text-based language where code is easy to write, easy to read, program structure is explicit, refactoring is unlimited, results can be easily used in several places, data can be passed around easily, and where the programmer doesn't have to remember anything other than function names.

Consider what a visual system allows us to get rid of: let expressions, parentheses, stack shufflers, positional arguments, all syntax.

I researched the field of visual languages, which was mostly unknown to me. In most systems, the programmer has to move blocks or nodes around to draw his program, almost spending more time doing interior decoration than actual programming. In Skov, the user doesn't have any control over the appearance of the program. The graph is automatically layed out.

On the question of productivity, I would argue that programming in Skov may actually be faster than in text-based languages. You enter all the words you will be needing with your keyboard, in the order in which they come to mind, not in an order imposed by the system. Then you take your mouse and simply draw all the connections between the words.

Factor was the best possible base for Skov because it is a powerful language, it has a lot of vocabularies, words have good names, it has image-based persistance and an OpenGL user interface, it works the same on the three common platforms and it is entirely contained in one directory.

The Skov project currently contains about 800 lines of Factor code, which is amazingly little.

At the moment, it is possible to create vocabularies and words, to use words in other words, to execute words and see the results. It is possible to use words that take quotations like map, filter or if. You can save the image so that your work will still be there the next time you open Skov.

In the future, I imagine there could be a system image that the user wouldn't modify and several user-created images that would contain the Skov code. These images could be sent to other people to share code. I would also like Skov to be homoiconic, not in the sense of code and data having the same appearance, but in the sense of them being processed by similar tools.

Here is what the interface looks like:

I would be happy to read your comments on this project.

Gitter forum

Maybe it's time to establish a forum like https://gitter.im/nicolas-p/skov ..?

Cannot enter '>upper' word

I'm not sure this is the right place to report errors in the tutorial.

But as I tried following along the steps here and entered the >upper word, it just disappeared. I couldn't make it work in any way.

I use the latest Windows version.

No skov.image

In windows 7 with factor-windows-x86-64-0.98, following the procedure in the file README.md, the skov.image is not generated.

Hidden or overlapping elements.

When following the tutorial (eg. distance between two points) and creating 'point A' with destructor, then 'point B' with destructor, and start to wire them up, 'point B' suddenly jumps on top of (obscures) 'point A'.

Is there a way to re-position them so that they are not completely overlapping each other?

(so far i'm only able to build the distance object if i wire them at different steps to have enough mismatching overlap to be able to continue the construction)

Running time

I see here http://rosettacode.org/wiki/Time_a_function#Factor that Factor has a time word that can tell the running time (and more) of an expression. How can one do this in Skov? When I entered the time word in Skov, I could see no output connector.