To get:
git clone git://github.com/timthelion/gridhaskell-haskarrow.git
cd gridhaskell-haskarrow/

To compile grid_edit:
$ghc grid_edit.lhs -threaded

To compile gridPrecompiler:
$ghc gridPrecompiler.lhs -XDeriveDataTypeable

To generate an example grid:
$./gridPrecompiler -e

To run grid_edit with example grid:
$./grid_edit examplegrid.grid-haskell

To precompile your grid:
$./gridPrecompiler -i examplegrid.grid-haskell -o examplegrid.hs

To compile your grid:
$ghc examplegrid.hs

This is FNF software.  What does that mean?  I am not the maintainer.

What does FNF stand for?

Take these usage cases:

Sally: I found a bug in your software, please fix it.

Me: Ok, great, fnf and I'll pull from you when you're done.

  - fnf = fork it and fix it
  
Olga: I wana redo the Haskarrow IDE in 3D!

ME: Ok, fnf!

  - fnf = fork it and have fun
  
Joe: You use VI hotkeys for navigation.  Emacs FTW, your software sux!!!111

Me:  If you don't like it, fnf.

  - fnf = fork it and fuck off
  
Tom:  Hey, I have a great idea, lets reimplement your backend with plug in support for lua.

Me: Hey, it's free software, fnf! :D

  - fnf = fork it and fap

FNF software often seems to the newbie or the non programer to be a hostile environment.  It is not intended this way.  The reason why the FNF model is chosen, is not out of hostility or hatered of newbies.  It's out of the desire to provide the user with a level of freedom not provided by the classical maintainer based development model.  Haskarrow land is not a dictatorship, and I am not the dictator here.  We are on equal footing.

I have seen to many large open source projects get bogged down in politics and beurocracy.  It's a tragedy to see that a patch won't go through due to the whim of some long term dev.  As much as FNF may be hostile to the newbie, maintainership is hostile to the programers who develop and promote FOSS.

FNF doesn't mean I won't help you, give you advice, show you how my code works.  It means I won't do it for you.  The last example I provide for you in my definition of FNF is this:

Jessica:  Look, now you can get the Haskarrow IDE in hot pink and perrywinkle blue... WITH UNICORNS!  FNF!!! :D

  - fnf = freedom never fades  

***

FNF is the most extreme version of the Bazaar model of software development coined by Eric S. Raymond.  There is no Cathedral, no bazaar, just freedom and chaos!

***

Despite the freedom of the fnf model being claimed throughout much of the open source world, I beleive that the fnf model cannot work in traditional programming environments when applied to applications of greater than trivial complexity.

The Haskarrow model has some destinct advantages.  Being based on the purely functional programming language, Haskell, there will be no "side effects" caused by much of the code base.  There is always the risk, when editing a C program, that you will mutate some part of the global state which you shouldn't have mutated, and the result will be errors occuring elsewhere in the program.  For fnf to work, a person must be able to modify a small part of a code base without needing to understand the entirety of the application.

The copy/paste ability of code is excedingly important to fnf.  Being able to copy a function from a fork, place it into my own code, and have it work, is essencial to making fnf work.  If the forks cannot "merge/pull from eachother" relatively painlessly, then a lot of duplicate effor will end up taking place.

A great example of copy paste style FNF is the development of elisp modules for GNU Emacs.  You'd be amazed at the kind of software development that goes on through people simple copy pasting bits of other people's .emacs files.  GNU Emacs is the test case that PROVES fnf can work on a large scale.  In many ways, Haskarrow is my own personal responce to the limitations of ELisp.  That is limited domain(can pretty much be used only for programs that manipulate text.) Clutter, unrelated tasks get pulled together into Emacs rather than becoming their own programs.  Difficulty of distribution(this is reltated to the clutter) because you can't easilly isolate a single component of the program.  Performance, due to clutter and the lack of performance potential of Elisp.

Copying whole functions is already quite easy in a strictly typed language such as Haskell.  You place it in a hole with the same type, and you KNOW it fits.  I have tried to make it even easier with my ThreadObject model by making those holes easy to create/manage.  One of the major unsolved challenges of fnf is that of data-type compatibility.  If two forks use a slightly different data-type, then there will have to exist a cast, in order for new features from one fork, to be imported into the other.   This is an argument for good practices:

a) Data abstraction:  If your data is a Tree, use Tree.  Don't make ever more complicated monolithic structures(I am guilty of this in my own implimentation of haskarrow). Rather build more complicated structures out of simpler ones.

b) Type standardization:  This will happen in a darwinistic fashion.  When a type is a well designed one, more functions will get written arround it.  As more functions are written arround it and floating in haskarrow verse, it is more likely a developer will use that type.

c) Record syntax:  For the most part, we can make functions seamlessly handle changes in data's, if we use proper record syntax rather than positional reference.

Another advantage of Haskarrow for fnf, is that of code orientation and readability.  The single most important design goal of using a visual language is to improve readability and orientation.  The time it takes to understand how a third party application works, so that the user can add a feature or fix a bug is the critical breaking point for fnf.  If I cannot figure out how the application works in a reasonable time frame, I cannot contribute to the project.

One of the key things that I have learned from my work in Braille, is that orientatiting oneself in a data set and data intake are two very different processes.  A blind person, can take in data at roughly the same rate as a sighted person, yet they preform basic tasks on the computer as much as 16 times slower than the sighted individual!  Imagine a blind person is on a web page and they want to read a news article.  Their screen reader starts from the top of the page, going through advertisements and navigational links. On a web page that they do not know, they will spend minutes finding the text content that they wanted!

Programmers today, face a task similar to that of the blind individual, when attempting to learn a new code base.  For the most part, we have to read, line by line, through files, at random, in order to get a clue as to what is going on.  Most open source programs I have looked at, don't even include a table of contents or some README-FOR-DEVS that might tell me which files and functions are interesting/important and which are not.

One of the problems with including such a README-FOR-DEVS, is that as code bases change, the README becomes out of date.  This is why it is better, if such a structure is built into the code base fundimentally.

Orientation is a task that the visual centers of our brain do excedingly well.  We can look at a diagram and pick out a word or pattern that we were looking for, far faster than we could read every title of every cell.  Time will tell, but I beleive that this model is fundimentally better than the plain text one.

If visual programming is so better, why hasn't it taken off long ago?

The UI's of the diagram editors I have used to date, have all be excedingly uncomfortable to use.  They have all used the same model. Point and click/drag and drop, and then type.  Editing a diagram using such a method is slow and cumbersome.  The table based model has a higher learning curve, but you will see for yourself that it is MUCH more convienient.  

Visual programming langauges today fall into 4 categories.

1) Archaic and API limited languages such a Drakon: Do not provide the tools that we need to write modern applications.  Drakon is a language that lives in all of our subconcousnesses, whether we know about computer programming or not.  Even though most people have never heard of the Drakon language, almost everyone has seen a Drakon, or Drakon derived diagram/flow chart.

2) Esoteric languages such as Befunged:  Befunged is the language that sparked me to write grid haskell.  The grid based model for editing, and the cleaver looping mechanism both intrigued me.  I have been wanting to write a Visual Programming language for many years, but it wasn't untill I saw Befunged that I knew how.  Befunged is an essoteric language though.  It is not usefull.  There are many essoteric visual programing languages.  You should go on Wikipedia and check them out!

3) Wrappers that generate code of a traditional plain text language:  Technically speaking, Haskarrow falls into this category.  At least for now.  Though Haskarrow can(and should) be compiled directly to binarry. The open source Drakon editor<http://drakon-editor.sourceforge.net/> can edit several traditional languages Java, C#, C/C++, Python, Tcl, Javascript and Erlang to be exact.  While I don't see their implementation as being bad, there is a lack of abstraction necessary to making it work well.  the Drakon editor lets you write Java, visually, or C visually.  But Java is not a visual programming language.  Haskarrow and Grid haskell are a significant abstractions from Haskell.  In no way, does the automatically generated code resemble typical Haskell code.

4) Domain specific languages:  Visual domain specific languages are actually quite popular and widespread.  They probably outnumber and outreach the non visual domain specific languages.  One of the reasons for this, is that textual algorithms tend to be abstract, while visual paradigms have the tendency to be concrete.  If you want a programming language that will describe a work flow in a factory, you don't need the power of C.  Pictures have to jump through the hoops of flow logic in order to be imperitive.  They have a much greater declarative value than text however.  A great example of a popular visual programming language is that of gtk's xmlbuilder and glade, or Microsoft's XAML.  You may have never thought of these as being programming languages, since you aren't telling the computer HOW to do something, but rather WHAT to do.  That said, you probably find defining a user interface to be easier in gtk builder or XAML than in C++.

Imediately, however, we come across the great limitation of declaritive visual languages.  The gui for Haskarrow IDE was not written using a gtkbuilder file.  This is because I wanted to use a GUI component(the grid based diagrams) which doesn't exist in gtkbuilder xml.  There is a fundimental lack of logic in the statically declarative visual language, that limits it unacceptably.

Haskarrow's use of contexts is my attempt to get arround this limitation.

***

A network based programming language

To the extent that the Haskarrow IDE is an IDE, it is also a web browser.  Almost every cell of a Haskarrow or Grid Haskell program is a hyperlink to another place in th Haskarrow verse.  This is fundimentally different from any other programming language you have ever used.  It creates destinct challenges of it's own.

In the traditional method of software development there are two types of packaged software.  An application, and a library.  Libraries provide general functionality, while applications preform specific tasks.

The traditional model has some dissadvantages.

1) There is no clear line, between which functions are "general" and which "specific".  In purely functional languages, this line becomes even harder to find.  Almost every pure function is general and can be used in many places.  This is a big advantage to using a purely functional programming language, it would be a pitty to let it slip away.

2) Libraries have versions, and don't always provide backwards compatibility.  This means, that old but good code becomes painfully obsolete :(

3) Libraries are monolithic.  If I want to use 200 functions, from 200 libraries, I need 200 dependencies.

I use an entirely different model.  When you browse the Haskarrow/gridHaskell web and you come across a function that you want to use, you press the "copy locally" button, and you use that function in your program.  The "copy locally" button downloads, that function, and all the other functions and data types which it relies upon, to your local Haskarrow web.  Each new copy includes a link going back to the online version.  You have just forked this function.  There is no need to wory that your program will break when the original author changes something, because you have your own static copy.  At the same time, you can still enjoy the benefit of updates to said function.  The Haskarrow IDE can simply follow the link back link every now and then, to see if anything has changed.  If so, you can look at the canges, decide if they are right for you, and accept them or decline them.  If you find a bug in the function, you can make a change upload it to github or wherever you are hosting your own personal Haskarrow web, and send a link to your new function to the author of the old.

When you publish an application, all of the functions in your personal Haskarrow web go online.  Since the user who then downloads the source to your program is getting your own personal copies of all the functions used, the user will never experience dependency hell.

This model has several chalenges of it's own.  

- The first is legal.

Our current Copyright system is fundimentally incompatible with the laws of informatics.  Information is not merely fundimentally easy to copy, information, by being expressed necessarilly leaves an impression.  My mind, is full of copyright works, which I "cannot unsee."  Even without wanting to, riding the tram to school, I see hundreds of copyright advertisements, the designs of buildings, I hear copyright music.  According to current copyright law, my very dreams are a massive infringement.  And "I cannot help but dream," as a copyrighted work by Evanecance flashes into my mind.  I cannot even help but think(and infringe)!

Since the networked Haskarrow development model relies on the ability to copy, the ability to copy must be a guaranteed right. For this reason, all Haskarrow applications must be GPLed.  To prevent people from parasitically leaching off of the Haskarrow verse, I release all of my own haskarrow and grid haskell files under the GPL.

The LGPL does not suffice for the haskarrow model.  Since we are trading individual functions, rather than packaged libraries, there would be no difference between LGPL and public domain.  A company could use any number of LGPL licenced haskarrow files in their project, claiming them to be libraries, without having to realease ANY of their own source code!

I strongly discurrage you from using LGPL, and must note that with my version of the Haskarrow IDE, all haskarrow applications that you write MUST be licenced under the GPL, as ThreadedObject and other core API components are GPLed.

One might complain that the GPL doesn't allow one to create comercial software.  We all need to eat.  I understand.  When I was a teen, I planned out my entire life arround being a citizen of free culture.  I planned to be a teacher, to put food on the table, and yet have enough time to devote to my work.  I also considered being a long haul truck driver and doing my software development by voice.  Or a garbage man.  Perhaps I should have chosen the later.  In school, all I hear about, is that teachers have no time, because they are bogged down with paperwork.

I know there are people who want to make a career of software engineering, or already have.  I don't have a problem with loving software, and wishing to devote your life to it.  But I also understand that our copyright/patent system is fundumentally flawed.  One answer I have for you, is in the past.  In the so called dark ages intelectual work was preformed by monks of the Roman Catholic church.  Today, a similar roll is filled by a certain sector called Accedamia.  This is a serious method of intelectual creation.  Right now, accedemia is severly flawed, and in the US, moving in the wrong direction.  It's moving to be more and more proprietary and corporate sponsored.  The universities do not have a right to sell out their soles to corporate funders.  They are non comercial institutions(and taxed as such!).  They have enjoyed hundreds of years of donations from alumni and the benevolent rich.  These funders have intended their money to go towards the advancement of human knowledge.  University study belongs in the public domain.  I have noticed, lately that some universities are moving in the right direction.  They are posting their studies freely online, rather than publishing in closed off and expensive journals.  Academia is certainly a place where you can seriously consider writting FOSS for a living.

Beside the "hippy extremist" such as myself, and the member of academia, there are many other ways to put food on the table and write code.  The key to making honest money, is in providing value to your costomer.  The value you provide as a programer, is not in selling a copy of your software, but in writing software which does not yet exist.  If I want to have a solution to a hard and unsolved problem, then I must pay a computer programmer to do so.  The place a programmer can provide the most value to a company is at the frontiers of computer science.  This makes computer science a constantly relevant, profitable, but mainly, exciting feild.  If someone needs to analize DNA or complex protines, control a satelite, improve the robotics in their factory, better controll their agricultural practices, ect. they need NEW code.  NEW code can be free code, and yet still of comercial value.  And as we all know, writting NEW code is the most fulfilling thing a person can do!

Here are some ways that a software developer can provide real value to their customers while still being compatible with free culture:

a) Write NEW code for hire... and give away the results!!
b) Provide customization of existing code
A lot of people seem to think that you cannot make any money writing custom code.  That it's a "fringe case".  They don't realise, that most code(in terms of lines of code) is custom code.  Furthermore, I've read concerns that you cannot make a business writting open-source custom code.  But every line of java-script ever deployed has been "open source" in a way.  The criticizms of this model seem rather silly in face of the overwhelming facts.

c) Provide customer support.
d) Provide warantees, guarantees, code audits.
   This last option is actually strongly promoted by the fnf model.  Without a maintainer, how can a company know that a peice of software is going to work correctly?  I can imagine a theoretical company like IBM providing a hypothetical service, lets call it "Enterprise Software Assurance Checking."  What is ESAC?  ESAC is when a company goes to IBM with a peice of fnf software and asks IBM to make sure that peice of software works, does not have any security flaws, and if it does, to fix them.  IBM would then give the software back including modified sorce code.  But that in no way would undermine IBM's buisness model.  In todays market, software is rapidly developing, rapidly changing.  In order to stay on the edge, a firm using fnf would need to constantly employ a company like IBM to provide ESAC on updates to their software.  Even just navigating the wide array of forks availible in an FNF model is a daunting task for non technical firms.  FNF makes ESAC and other types of quality assurance and software consulting essencial!  FNF is good for comercial software firms!  The more rapidly evolving, chaotic, hard to navigate, the FNF world is, the more work there will be for ESAC consultants even giving those same people all the more reason to freely contribute to FNF software. (Appologies to IBM.  I believe IBM is a registered trademark. I am not trying to insult or lible IBM in any way by making this statement :)

  There are some ways it which I have desinged the Haskarrow IDE so that it will work well with ESAC for FNF.  The source code of haskarrow/grid haskell modules is GPL. When you "export" a program from the FNF verse and give it to someone, you MUST! give them the rights that the GPL provides.  HOWEVER, the way the Haskarrow IDE works, over time a user develops a personal web of grid haskell modules that they have downloaded, read, and decided to "trust".  This is how we can manage security in an FNF development environment.  Since a software consultant is not forced to share the list of modules he trusts, this gives him/or her a kind of capital which he/she can sell.  If a client comes to the consultant with a request for a specific peice of software, the consultant can quickly throw it together from his set of trusted modules.  The consultant is thus providing the value of trust and warantee to the client, and putting food on the table, while at the same time remaining true to open source fillosophy.  Trust is owned by the trusted individual, while ideas are shared by the humanity from which they sprung.
  
  In order to better understand this concept of "sale of trust", take Wikipedia(one of the main influences on FNF).  Wiki style editing is a great way to amass large amounts of data quickly and efficiently.  It is not, however a very good way of creating a base of trustworthy information.  Imagine a comercial service "wikiverify.com" which would try to solve this problem.  Employees at wikiverify would do the hard work of following citation links, going to the library, ect.  in order to verify that the information in an article is true.  They would then create their own list of trusted wikipedia articles.  When a person wanted to then find out if the facts in a Wikipedia article were correct, rather than having to go and find the works cited, themselves, they could send wikiverify.com a URL to the article in question.  Wikiverify.com would then either appologise that they had yet to verify the information on that page, or tell them the facts in the article had been verified by experts, or tell them that a previous version of the article had been verified(all this for a small fee of course.)  Wikiverify.com is not in the buisness of selling information.  Information is free(Of course, while our highly unatural copyright laws take away our freedoms, they don't change that fact.).  Wikiverify.com sells trustworthiness, and that's an entirely different product.

If you want to think about sale of trust vs sale of licences to copyrighted content in terms of "natural laws" rather than "moral ones", think about this.  I can copy paste a file, but I cannot copy paste the trustworthiness of a files contents.  If someone were to hack into wikiverify.com and steal their list of trusted articles, then post it on a torrent site, little would be lost.  Since one isn't exactly about to trust the hacker to not have changed the list in some way.

There is however an "open source" buisness model which is NOT compatible with FNF.  That is the model where a company maintains a project, keeping an open source version and a proprietary version.  This cannot happen, since a project has no maintainer, and copy right is accumulative rather than convergant.  A file may be copyrighted by the 30 different individuals who improved it.  If a person then wanted to get a proprietary licence to that file, they would have to come to an agreement with all 30 of the individuals!

- The seccond great challenge is that of personal web clutter.  You could end up with many duplicate/similar functions in your web.  You might not know, what will happen if you edit one function that is used in many places arround your web.  I'm not sure what the solutions to this problem will be.  I need to finish writting the IDE so that I can better understand the problem.

One must, is a feature that shows you where in your personal web a given function is used.  And another needed feature, is that upon "copy local" the haskarrow IDE would determine if an identical function already exists in the local web, and thus be able to ask the user what to do.

- The third great challenge is that of security.  With networked FNF you will be constantly running new untrusted code on your system (See ESAC).  Purely functional programming comes to your advantage!  Pure functions are guaranteed to have no side effects(when compiled correctly so as to ban unsafePreformIO).  This still doesn't mean that they are 110% safe.  For example, imagine a pure function that would return the file name to write to, that changed that file name to something destructive.  But these pure functions are 99% safe.

***

One last note.

Computer programming isn't easy.  When one works on a large and complex project, simply holding everything in our heads can strech the limits of our working memory capacity.  I hope that the visual programming paradigm will make programming less stressfull, and make programming require less working memory.  The great demand on the programmer to hold large amounts of API information in working memory is not healthy.  It leads us computer programmers to hyperfocus, which has negative impacts on our ability to cook, eat, sleep, bath, do the laundry, excersize regularly, interact socially.  We're not all a bunch of autistics though.  We're more like drug adicts, getting high on light night screen light and dubstep.  I hope that by making it easier to orient ones self in a computer program, hyperfocus will become a less vital part of computer programming.  This will make us all a bit healthier.  Furthermore, I beleive that women are less willing to reduce themselves to the level of the stinky hungry and yet highly successfull nerd.  Perhaps, if computer programming was a healthier activity, more women would enjoy doing it.

This written from bed at 1pm, after a (till 4 o'clock in the morning) hacking session.

----

README Copyright. Timothy Hobbs 2012.  CC-BY

You are free to copy and distribute this README under the terms of the Creative Commons - Attribution licence 3.0 or later.

----

FNF is anarchy, FNF is the furious nameles fire which corporate America so much fears!


PS:  FNF is not intended to be a method for creating "end user" accessible software.  See my note about ESAC above.  I hope that it will form an environment that supports extremely rapid development.  I hope that programs will appear in the FNF verse, and people will like them, vet them for security, and then package them normally.