NPL : Some Assumptions

These are some assumptions while designing the NPL language:

• Creating a Connect is cheap.
• Sending a Signal is cheap,quick and is reliable.
• The garbage collection algorithm is effective and efficient.
• An individual connect spends negligible amount of time per input signal compared to the total execution time of the program.
• Performance hit within tolerable limits is acceptable.

Some assumptions regarding NPL UI:

• Everything you know about your program is inside the source code in some form or will manifest itself at runtime.
• The NPL UI has read access to the internals of signals and connects inside the interpreter.
• The user can inspect and modify the signals and connects inside the interpreter via the NPL UI.

Assumption common to all:

• The NPL Language, NPL Interpreter and the NPL UI all will be modified in a coherent manner.
• NPL Language, NPL Interpreter and the UI will be based on COP.

Traits of a Framework for Software Visualisation

Here are the few traits that a framework used by a good visualisation environment would need:

• It should have good support for primitive graphics, 3D models and images.
• It should also have good support for primitive 2D shapes and 2D GUI widgets.
• It should be scriptable.
• Good support for displaying and handling text.
• Primitive shapes (2D and 3D) should be easy to create.
• Ability for Zoom in and Zoom out.
• Basic support for sound.
• Basic networking support.
• Ability to talk to an external environment.
• Should be lightweight.

Probable Candidates:

• A custom visualisation framework built on OpenGL. (A a futile excercise IMO).
• A framework built on Java Swing or something similar.. (This is also a futile exercise and may not be very flexible ).
• A 3D editing program like Blender. (Not sufficient)
• Any self-respecting game engine provides most of these facilities. They usually have bad support for 2D and primitive objects. (Not sufficient)
• An environment like blender with support for text(inside the scene) and 2D widgets.
• A Game engine modified for inbuilt 2D capabilities and text handling with some shortcuts for primitives thrown in to the mix.

“Pay as you Go” model for Visualisation

One of the complaints we hear about visualisation systems is that they are unintuitive. Most of them are unintuitive because, they are built for specialised applications. There are no general purpose visualisation systems.

NPL is also haunted by these concerns. Many do not like the NPL UI(at the moment) because it produces canned visualisations which are not always suitable to the way a person thinks. Hence, people need to have control over the visualisation. But the mechansim provided to customise the visualisation will ultimately decide the fate of a visualisation system. Here I introduce the "pay as you go" model for building visualisations which suits well with the way we develop software.

"Pay as you go" Model:

Instead of spending huge resources(or taking huge losses) upfront for a visualisation system, in this model the resources spent will be directly proportional to the intuitiveness of the visualisation. In this model, the basic features of the visualisation system will be free, where as the higher level views can be customised by a little effort from the user.

The effort can be minimised and returns maximised when

• The lower bound is free and acceptable for day to day chores.
• The resources needed to get better visualisations are little.
• The upper bound is(seems) achievable by(to) a average joe.

This model has the potential to make visualisation mainstream.

The Plan:

Though this model looks simple and straight forward, achieving them is no easy task. Here are some techniques i think will make this model work.

• The lower bound can be achieved by the following tasks:
  • Designing the language to suit visualisation.
  • Using designs which are easy to visualise.
  • Good basic visualisation.
  • Modifying Visualisation based on static and runtime anyalsis of programs.
  • Custom look and feel for standard libraries.
• The incremental changes to visualisation can be provided by:
  • A meta language which is turing complete and is similar to/same as the language we are coding in.
  • Providing default visalisations which the users can use.
  • Providing inspection of language structures in the meta-language.
  • A declarative language, for making chores easy and quick. (Can this be same as the meta language?)
• The upper bound should not be too high, so that it is daunting for a programmer to even attempt for a perfect visualisation. The upper bound can be kept under check by:
  • Providing mechnisms for customising visualisations rather than policies. This aids in keeping the number of visualisation primitives low.
  • Providing tools.

Order of evaluation of expressions effects Visualisation

Initially, i did not see much difference between any other language and a language designed for visualisation (NPL). Almost all of it is the same until i saw an example.

First lets understand how a function call works in NPL.

• Whenever a signal with the name of the function and its arguments is raised, it creates a GenericConnect.
• This GenericConnect looks at the symbol table for the function definition. If it is present, it proceeds furthur, else it gives an error.
• Next, it evaluates the expressions passed as arguments to the function to get the value of their arguments.
• Once the arguments are evaluated, it creates a BlockConnect which represents the function definition and sends in these arguments which are local values in that scope.
• Once the BlockConnect starts execution, it stores these values in the local symbol table and goes on to execute the function.
• Once the execution of the function is complete, it returns the return value to the GenericConnect.

This is the typical implementation of a function call mechanism in NPL. This model of execution is good as long as the function call does not have nested arguments and the function is recursive in nature. So, a (fact 5) seems to provide the right data for visualisation.

But when the function call has arguments which are themselves function calls, the visualisation is unintuitive when it is based on the exact execution shown above. For example, consider the expression, a function call

(func1 (func2 2) (func3 3))

Intuitively, we would think about this as func1 being called with the values of func2 and func3. We assme, that func2 and func3 are evaluated by func1(or after calling func1 but before executing func1 ). When the interpreter evaluates this expression, func2 and func3 are evaluated before the func1 is called. The visualisation also shows the evaluation in the same order. This kills the intuitiveness of the visualisation compared to the textual form. Though this difference seems trivial it makes big impact on the quality of visualisation since i was completely clueless of what was happening when i saw the visualisation of the above expression for the first time.

Solutions:

So there are 2 solutions to the above problem.

1. Make modifictions to the visualisation system such that we show that the evaluation of func1 starts the evaluation of func2 and func3. This is plausible for small changes, but is difficult when the functions are deeply nested. It is also computationally intensive as it involves lot of tree rewriting in the UI.
2. Change the function call mechanism in the interpreter such that the evaluation of the arguments of the function takes place after function is called, but before the function starts execution. This seems easier to implement, but is slightly complex because, the arguments now need to be passed as closures.

I prefer solution 2 because it is more elegant and passing arguments is less computationally intensive. This is the reason, why i feel we need a seperate language designed for visualisation. Another example is the implementation of GenericConnect which is the topic for another day.