The Nile Programming Language

Thanks for the link. I had problems understanding what Nile was all about from reading the slides, which provide very little in terms of context and explanations.

Watching that talk and hearing that Nile is a declarative streaming language from the research group where Bret Victor works, I now understand what are the practical applications of such language.

Alan Kay talks about Gezira, a library built with Nile (and the motivation for making Nile, althoug Nile is much more general purpose). There's a JS version of Nile/Gezira which was used for Brett Victor's demonstrations, which can be found here [1]

The main Nile compiler here is written in Maru, a programming language of Ian Piumata's which is another awesome project on it's own. It's essentially a Lisp where you can define how the evaluator behaves for a given type.[2] The version of Maru used is included in the Nile repo though. It can be built with GCC or MinGW. The compiler translates Nile to either Maru or C code.

There's a squeak version which can be found at [3]

And also a Haskell vector library which exposes a similar interface to Cairo, but is modeled as Gezira under the hood (used for purely functional image generation). Although this implementation is function based and doesn't really provide a proper streaming abstraction as provided by Nile. [4]

[1]: https://github.com/damelang/gezira/tree/master/js

[2]: http://piumarta.com/software/maru/

[3]: http://tinlizzie.org/updates/exploratory/packages/

[4]: https://hackage.haskell.org/package/Rasterific

> Though GH repo is not updated for more than 3 years and maybe it's just my inexperience or I am spoiled, but from lack of proper documentation I have no idea how to setup and use this language? On what platforms does it work?

Looks very interesting, it's a bit sad to see things like:

https://github.com/damelang/nile/issues/4

Mostly hanging from this summer. I would love it if more of these code dumps from research projects at least included a section on how to get the examples running (and something on requirements, such as which OS it has been tested on, even if that turns out to be "Only tested on DOS 2.1").

I think the philosophy behind it is that they (View Point Research Institute) want(ed?) to be able to create lots of domain specific programming languages easily. So being able to implement those little languages from scratch and not as part of an existing language was part of the research effort, not just the language itself.

They have created tools like OMeta2 for this purpose, because they think that this way every problem is expressed in the natural language of the problem domain. A huge compiler like GHC with its >= 100.000 lines of code runs also against the goal of creating a system that needs orders of magnitude less code (I think their initial budget was ~10000 lines of code).

A proper [e]DSL should almost always be preferred to a library. For the very obvious reasons.

Here's a small comparison of Nile and (manually translated) JS code.

Nile[1]:

    DecomposeBeziers : Bezier >> EdgeSample
        ∀ (A, B, C)
            inside = (⌊ A ⌋ = ⌊ C ⌋ ∨ ⌈ A ⌉ = ⌈ C ⌉)
            if inside.x ∧ inside.y
                P = ⌊ A ⌋ ◁ ⌊ C ⌋
                w = P.x + 1 - (C.x ~ A.x)
                h = C.y - A.y
                >> (P.x + 1/2, P.y + 1/2, w × h, h)
            else
                ABBC    = (A ~ B) ~ (B ~ C)
                min     = ⌊ ABBC ⌋
                max     = ⌈ ABBC ⌉
                nearmin = | ABBC - min | < 0.1
                nearmax = | ABBC - max | < 0.1
                M       = {min if nearmin, max if nearmax, ABBC}
                << (M, B ~ C, C) << (A, A ~ B, M)

JS[2]:

    gezira.DecomposeBezier = function(downstream) {
        return function(input) {
            var output = [];
            while (input.length) {
                var a_x = input.shift();
                var a_y = input.shift();
                var b_x = input.shift();
                var b_y = input.shift();
                var c_x = input.shift();
                var c_y = input.shift();
                var _1_x = Math.floor(a_x);
                var _1_y = Math.floor(a_y);
                var _2_x = Math.floor(c_x);
                var _2_y = Math.floor(c_y);
                var _3_x = Math.ceil(a_x);
                var _3_y = Math.ceil(a_y);
                var _4_x = Math.ceil(c_x);
                var _4_y = Math.ceil(c_y);
                var _5_0 = _1_x == _2_x;
                var _5_1 = _1_y == _2_y;
                var _6_0 = _3_x == _4_x;
                var _6_1 = _3_y == _4_y;
                var _7_0 = _5_0 || _6_0;
                var _7_1 = _5_1 || _6_1;
                var _8 = _7_0 && _7_1;
                if (_8) {
                    var p_x = _1_x < _2_x ? _1_x : _2_x;
                    var p_y = _1_y < _2_y ? _1_y : _2_y;
                    var w = p_x + 1 - ((c_x + a_x) / 2);
                    var h = c_y - a_y;
                    output.push(p_x, p_y, w, h);
                }
                else {
                    var abbc_x = (((a_x + b_x) / 2) + ((b_x + c_x) / 2)) / 2;
                    var abbc_y = (((a_y + b_y) / 2) + ((b_y + c_y) / 2)) / 2;
                    var min_x = Math.floor(abbc_x);
                    var min_y = Math.floor(abbc_y);
                    var max_x = Math.ceil(abbc_x);
                    var max_y = Math.ceil(abbc_y);
                    var _9_x = Math.abs(abbc_x - min_x);
                    var _9_y = Math.abs(abbc_y - min_y);
                    var nearmin_0 = _9_x < 0.1;
                    var nearmin_1 = _9_y < 0.1;
                    var _11_x = Math.abs(abbc_x - max_x);
                    var _11_y = Math.abs(abbc_y - max_y);
                    var nearmax_0 = _11_x < 0.1;
                    var nearmax_1 = _11_y < 0.1;
                    var m_x = nearmin_0 ? min_x : (nearmax_0 ? max_x : abbc_x);
                    var m_y = nearmin_1 ? min_y : (nearmax_1 ? max_y : abbc_y);
                    input.unshift(a_x, a_y, (a_x + b_x) / 2, (a_y + b_y) / 2, m_x, m_y,
                    m_x, m_y, (b_x + c_x) / 2, (b_y + c_y) / 2, c_x, c_y);
                }
            }
            downstream(output);
        };
    };

Should be obvious why a DSL is preferred in this case. Although there are obviously some more succinct ways one could write it in the JS version, the constraints of trying to fit it into javascript syntax are probably not worth the effort, and it's unlikely you could ever get the same amount of information per character as an eDSL.

Conventional language don't really overlook streaming because there's not really any one solution that fits all when it comes to it, so it's typically left as a library problem.

[1]:https://github.com/damelang/gezira/blob/master/nl/rasterize.... [2]:https://github.com/damelang/gezira/blob/master/js/gezira.js#...