enso-org / enso

Hybrid visual and textual functional programming.

Enso.org. Get insights you can rely on. In real time.

Enso is an award-winning interactive programming language with dual visual and textual representations. It is a tool that spans the entire stack, going from high-level visualization and communication to the nitty-gritty of backend services, all in a single language. Watch the following introduction video to learn what Enso is, and how it helps companies build data workflows in minutes instead of weeks.

Enso's Features

Turning your data into knowledge is slow and error-prone. You can’t trust tools that don’t embrace best practices and provide quality assurance. Enso redefines the way you can work with your data: it is interactive, provides intelligent assistance, and was designed on a strong mathematical foundation, so you can always trust the results you get.

Intelligent suggestions of possible next steps. Build workflows in minutes instead of weeks.
Enso analyses the data, suggests possible next steps, and displays related help and examples. It lets you build dashboards, RPA workflows, and apps, with no coding required. Enso ships with a robust set of libraries, allowing you to work with local files, databases, HTTP services, and other applications in a seamless fashion.
Learn more →

Reproducible, trustworthy results.
Versioning and visual data quality management allow you to trust the results that you get.
Learn more →

A powerful, purely functional language. Both visual and textual.
Enso incorporates many recent innovations in data processing and programming language design to allow you to work interactively and trust the results that you get. It is a purely functional programming language with higher-order functions, user-defined algebraic datatypes, pattern-matching, and two equivalent representations that you can switch between on-demand.
Learn more →

Mix languages with close-to-zero interop overhead.
Import any library from Enso, Java, JavaScript, R, or Python, and use functions, callbacks, and data types without any wrappers. Enso uses GraalVM to compile them to the same instruction set with a unified memory model.
Learn more →

Fast. Up to 80x faster than Python.
It can even run other languages faster than their official runtimes. Enso-R (using FastR on the GraalVM) is 36x faster than GNU-R.
See benchmarks →

A cutting-edge visualization engine.
Enso is equipped with a highly-tailored WebGL visualization engine capable of displaying many millions of data points at 60 frames per second in a web browser. Currently, Enso includes a set of core data visualizations out of the box, and you can easily extend it with libraries such as D3.js, Three.js, Babylon.js, deck.gl, VTK.js, Potree, and many more.
Learn more →

Runs everywhere.
Enso is available on macOS, Windows, and GNU/Linux, and the Enso IDE runs on web-native technologies. In time, you'll be able to run it in the web-browser, giving even your tablet and phone access to your data.
Learn more →

Getting Started

Download Enso

• Enso Interactive Environment
• Enso Compiler (CLI, optional)

Watch Tutorials

• Enso keyboard shortcuts
• Enso 101
• Analyze trams data
• Analyze GitHub Stargazers data
• ... other tutorials

Watch Video Podcasts

• Enso Textual Language Basics
• Using Java libraries in Enso
• Custom data visualizations
• Enso vision. What is in the future?
• ... other video podcasts

Join Our Community

• Discord chat. Get help, share your use cases, meet the team behind Enso and other Enso users!

Keep Up With the Latest Updates

• Enso Development Blog
• Enso Mailing List

Enso Source Code

If you want to start using Enso, please see the download links in the getting started section above. Alternatively, you can get the IDE here. This section is intended for people interested in contributing to the development of Enso.

Enso is a community-driven open source project which is, and will always be, open and free to use. Join us, help us to build it, and spread the word!

Project Components

Enso consists of several sub projects:

• Enso Engine: The Enso Engine is the set of tools that implement the Enso language and its associated services. These include the Enso interpreter, a just-in-time compiler and runtime (both powered by GraalVM), and a language server that lets you inspect Enso code as it runs. These components can be used on their own as command line tools.

• Enso IDE: The Enso IDE is a desktop application that allows working with the visual form of Enso. It consists of an Electron application, a high performance WebGL UI framework, and the searcher which provides contextual search, hints, and documentation for all of Enso's functionality.

License

The Enso Engine is licensed under the Apache 2.0, as specified in the LICENSE file. The Enso IDE is licensed under the AGPL 3.0, as specified in the LICENSE file.

This license set was chosen to provide you with complete freedom to use Enso, create libraries, and release them under any license of your choice, while also allowing us to release commercial products on top of the platform, including Enso Cloud and Enso Enterprise server managers.

Contributing to Enso

Enso is a community-driven open source project which is and will always be open and free to use. We are committed to a fully transparent development process and highly appreciate every contribution. If you love the vision behind Enso and you want to redefine the data processing world, join us and help us track down bugs, implement new features, improve the documentation or spread the word!

If you'd like to help us make this vision a reality, please feel free to join our chat, and take a look at our development and contribution guidelines. The latter describes all the ways in which you can help out with the project, as well as provides detailed instructions for building and hacking on Enso.

If you believe that you have found a security vulnerability in Enso, or that you have a bug report that poses a security risk to Enso's users, please take a look at our security guidelines for a course of action.

Enso's Design

If you would like to gain a better understanding of the principles on which Enso is based, or just delve into the why's and what's of Enso's design, please take a look in the docs/ folder. It is split up into subfolders for each component of Enso. You can view this same documentation in a rendered form at the developer docs website.

This folder also contains a document on Enso's design philosophy, that details the thought process that we use when contemplating changes or additions to the language.

This documentation will evolve as Enso does, both to help newcomers to the project understand the reasoning behind the code, and also to act as a record of the decisions that have been made through Enso's evolution.

enso's Issues

Choosing Atom plugins and themes to be shipped with Luna Studio

Parser does not work correctly with empty string

Lately when I was developing System library error from parser have occurred with this code:

import Std.HTTP
import Std.System

def main:
    putStr "luna"
    foo = Process "ls" (Empty . prepend "/Users/LJK/Desktop/") "" . readProcessWithExitCode
    putStr foo.toText```

Console output:
```luna: unsupported
CallStack (from HasCallStack):
  error, called at src/Luna/Syntax/Text/Parser/Parsing.hs:686:30 in luna-syntax-text-parser-0.2-FmYTGPSXj6D8zT6gDdHkTj:Luna.Syntax.Text.Parser.Parsing```

Debugging shows that if third argument of `Process` is not empty string or empty string in parenthesis it works correctly.

Luna studion

[Enter steps to reproduce:]

1. Download Luna installer
2. Run installer
3. Run .luna/bin/luna-studio/current/luna-studio
4. Message says "Downloading Tutorials" but never completes
5. Expanding window to full screen reveals stack trace as below

Atom: 1.18.0 x64
Electron: 1.3.15
OS: Debian GNU/Linux
Thrown From: luna-studio package 1.0.0

Stack Trace

Uncaught TypeError: parsed.forEach is not a function

At /home/andy/.luna/config/luna-studio/1.0/atom/packages/luna-studio/lib/projects.coffee:160

TypeError: parsed.forEach is not a function
    at Request._callback (/packages/luna-studio/lib/projects.coffee:160:32)
    at Request.self.callback (/packages/settings-view/node_modules/request/request.js:186:22)
    at emitTwo (events.js:106:13)
    at Request.emit (events.js:191:7)
    at /packages/settings-view/node_modules/request/request.js:1163:10)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:188:7)
    at /packages/settings-view/node_modules/request/request.js:1085:12)
    at IncomingMessage.g (events.js:286:16)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Commands

  3x -0:37.5.0 dev-live-reload:reload-all (atom-workspace.workspace.scrollbars-visible-always)
     -0:12.6.0 tree-view:show (atom-workspace.workspace.scrollbars-visible-always.theme-luna-syntax.theme-luna-dark-ui)

Non-Core Packages

advanced-open-file 0.16.6 
busy-signal 1.4.3 
color-picker 2.2.5 
column-select 0.2.0 
cursor-history 0.11.1 
custom-window-title 1.0.4 
file-icons 2.1.11 
git-blame 1.2.2 
git-history 3.3.0 
git-log 0.4.1 
git-plus 7.9.3 
hasklig 0.4.0 
highlight-line 0.12.0 
highlight-selected 0.13.1 
intentions 1.1.5 
language-gitignore 0.3.0 
language-haskell 1.13.2 
luna-dark-ui 0.1.1 
luna-dpi 0.1.2 
luna-studio 1.0.0 
luna-syntax 0.1.0 
minimap 4.29.6 
minimap-codeglance 0.4.7 
minimap-cursorline 0.2.0 
minimap-find-and-replace 4.5.2 
minimap-git-diff 4.3.1 
minimap-highlight-selected 4.6.1 
multi-cursor 2.1.5 
sort-lines 0.14.0 
split-diff 1.5.0 
web-view 3.0.0 

Can I use luna with c9.io?

I use c9.io for my projects. And c9.io doesn't have possibility to use Luna visually.

Can I use luna compiler in terminal mode only? c9.io uses Ubuntu LTS.

Cmd arg parser

Website design

Parser error on number negation

Following code:

def main:
    powers 1 . take 100
def powers s:
    Prepend s (powers (-2*s))

Produces following error:

SomeParserException FIXME: prec not found between "#uminus#" and "*"
CallStack (from HasCallStack):
  error, called at src/Luna/Syntax/Text/Scope.hs:74:35 in luna-syntax-text-parser-0.2-EhiUrnuqfI18wmiz5Qdsxa:Luna.Syntax.Text.Scope

While this code works correctly:

def main:
    powers 1 . take 100
def powers s:
    Prepend s (powers ((-2)*s))

Parser / Lexer performance fine tuning.

Websocket server functionality

No compilation error when applying too many function arguments

this code:

def main:
    foo = newMVar 0
    putStr foo.read.toText

yields a runtime error (being unable to apply newMVar to anything), instead of detecting this when typechecking

Cleaning Prologue (making Prologue 2.0)

Generic command line settings manager

Atom plugin for GUI scaling on hi-dpi screens (mostly Linux)

Report HTTP library errors in luna

Things like HTTP timeouts, TLS errors or even invalid urls (just try Http.getJSON "someurl") are displayed in the console instead of being passed to Luna. We need them inside our own error monad.

XML/HTML library

Rudimentary – just the most common parts of spec will do for now. We need parsing and generation of these.

Installation failed [ Windows 7 ]

Graphics processing Luna library

Stdlib 1.0

This epic aims to capture all the tasks necessary to provide our users with a usable standard library.

The goals here are:

• feature completeness: we want to support a sensible set of operations on numbers, text, lists and maps, including: checking for equality, converting to text, casting (e.g. 4.toReal) and so on.
• consistency: the users have a right to expect certain consistency throughout the library, like every two objects of the same time being comparable (.equals) or show-able (within reason).
• reliability: the core StdLib should be tested and fool-proof.

Duplication of method does not result with compilation error

I've noticed that our class Maybe has two methods toText and it does not result with any errors which is not correct.

Console Luna fails silently when imported module's name is invalid.

@piotrMocz commented on Wed Sep 13 2017

Try:

import Std.Bejz

def main:
    print "Hello"

to reproduce.

CSV file parsing facilities

Websocket client functionality

proper message when luna started not in project folder

[sylwia@linux luna]$ ./dist-package/appimage/out/luna.AppImage 
Found the standard library at: /tmp/.mount_luna.AYiagHO/usr/config/env/Std
Requested module: Std.Base
Compiling module: Std.Base
Requested module: Std.HTTP
Compiling module: Std.HTTP
Requested module: Std.System
Compiling module: Std.System
Requested module: Std.Time
Compiling module: Std.Time
Requested module: Std.WebSockets
Compiling module: Std.WebSockets
/tmp/.mount_luna.AYiagHO/usr/src/: /tmp/.mount_luna.AYiagHO/usr/src/: getSymbolicLinkStatus: does not exist (No such file or directory)
Requested module: Main.Main
luna: user error (Pattern match failure in do expression at src/Luna/Shell.hs:174:5-18)

Uncaught TypeError on Opening LunaStudio

How to reproduce

1. Install LunaStudio on Mac
2. Open it for the first time and click new project

Atom: 1.18.0 x64
Electron: 1.3.15
OS: Mac OS X 10.12.6
Thrown From: luna-studio package 1.0.0

Stack Trace

Uncaught TypeError: parsed.forEach is not a function

At /Users/saltzm/.luna/config/luna-studio/1.0/atom/packages/luna-studio/lib/projects.coffee:160

TypeError: parsed.forEach is not a function
    at Request._callback (/packages/luna-studio/lib/projects.coffee:160:32)
    at Request.self.callback (/packages/settings-view/node_modules/request/request.js:186:22)
    at emitTwo (events.js:106:13)
    at Request.emit (events.js:191:7)
    at /packages/settings-view/node_modules/request/request.js:1163:10)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:188:7)
    at /packages/settings-view/node_modules/request/request.js:1085:12)
    at IncomingMessage.g (events.js:286:16)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Commands

  3x -0:46.5.0 dev-live-reload:reload-all (atom-workspace.workspace.scrollbars-visible-when-scrolling)
     -0:17 tree-view:show (atom-workspace.workspace.scrollbars-visible-when-scrolling.theme-luna-syntax.theme-luna-dark-ui)

Non-Core Packages

advanced-open-file 0.16.6 
busy-signal 1.4.3 
color-picker 2.2.5 
column-select 0.2.0 
cursor-history 0.11.1 
custom-window-title 1.0.4 
file-icons 2.1.11 
git-blame 1.2.2 
git-history 3.3.0 
git-log 0.4.1 
git-plus 7.9.3 
hasklig 0.4.0 
highlight-line 0.12.0 
highlight-selected 0.13.1 
intentions 1.1.5 
language-gitignore 0.3.0 
language-haskell 1.13.2 
luna-dark-ui 0.1.1 
luna-dpi 0.1.2 
luna-studio 1.0.0 
luna-syntax 0.1.0 
minimap 4.29.6 
minimap-codeglance 0.4.7 
minimap-cursorline 0.2.0 
minimap-find-and-replace 4.5.2 
minimap-git-diff 4.3.1 
minimap-highlight-selected 4.6.1 
multi-cursor 2.1.5 
sort-lines 0.14.0 
split-diff 1.5.0 
web-view 3.0.0 

Gray-out all successors of a modified node

After a node is edited (its expression or connections changed) all the nodes that depend on its result should also be grayed-out. Their types are most probably invalid anyway and this way we get a clear indication as to which nodes have valid results and types, and which are being recomputed.

Wrong suggestions for methods named the same as functions

How to reproduce:
Say we have a node n with an instance of a List class, which exposes the average method. Incidentally, this is also a function taking a Stream, defined in the same file (Std.Base).

Now, when we click on the node with the list and hit "Tab" -> ". average" -> "Enter" we expect the resulting expression to be n . average. However, we end up with average n, which is nonsensical type- and sematics- wise.

Broken Assumptions Resolution when Defining Methods

This is a curious case, probably resulting from broken resolution of CurrentTarget in Luna typechecker. This code:

class Complex:
    real :: Real
    imag :: Real
    def + that:
        Complex (self.real + that.real) (self.imag + that.imag)

yields compile errors whenever addition on complex numbers is used. Errors suggest that the TC is messing reals and complex numbers together. Everything works fine when the + definition is changed to explicit use of method instead of the operator wrapper:

def + that:
    Complex (self.real.+ that.real) (self.imag.+ that.imag)

Interestingly enough, this only happens when the operator used in body is the same as one currently being defined (i.e. using the operator * inside definition of + method works fine. And it breaks when using * in the definition of *, but + works fine there).

Allowing comments to be hidden in docs.

# not a docstring at all, just a comment for the devs using this private function
def _foo a b:
    a + b

I would expect code like this to work just fine: it's a comment, not a docstring (I don't want it to be one).

Implement System library

Cleaning `convert` library

Parser does not parse defs after an empty class correctly

With this code:

class Foo:
    Foo Bool

def main:
    putStr "hello world!"

the function main is parsed as a method of class Foo, not a module-level definition. This is fixed when we add any methods inside Foo – this code parses correctly:

class Foo:
    Foo Bool
    def dummy: None

def main:
    putStr "hello world!"

Finishing the implementation of Map class

We need to add balancing to the structure and other operations that are now missing (like deleting keys)

parser error at startup

[Enter steps to reproduce:]

1. Start up 1.0 beta
2. Create new private project

Atom: 1.18.0 x64
Electron: 1.3.15
OS: Mac OS X 10.13.2
Thrown From: luna-studio package 1.0.0

Stack Trace

Uncaught TypeError: parsed.forEach is not a function

At /Users/viraptor/.luna/config/luna-studio/1.0/atom/packages/luna-studio/lib/projects.coffee:160

TypeError: parsed.forEach is not a function
    at Request._callback (/packages/luna-studio/lib/projects.coffee:160:32)
    at Request.self.callback (/packages/settings-view/node_modules/request/request.js:186:22)
    at emitTwo (events.js:106:13)
    at Request.emit (events.js:191:7)
    at /packages/settings-view/node_modules/request/request.js:1163:10)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:188:7)
    at /packages/settings-view/node_modules/request/request.js:1085:12)
    at IncomingMessage.g (events.js:286:16)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Commands

  3x -3:26.6.0 dev-live-reload:reload-all (atom-workspace.workspace.scrollbars-visible-when-scrolling)
     -1:46.4.0 tree-view:show (atom-workspace.workspace.scrollbars-visible-when-scrolling.theme-luna-syntax.theme-luna-dark-ui)

Non-Core Packages

advanced-open-file 0.16.6 
busy-signal 1.4.3 
color-picker 2.2.5 
column-select 0.2.0 
cursor-history 0.11.1 
custom-window-title 1.0.4 
file-icons 2.1.11 
git-blame 1.2.2 
git-history 3.3.0 
git-log 0.4.1 
git-plus 7.9.3 
hasklig 0.4.0 
highlight-line 0.12.0 
highlight-selected 0.13.1 
intentions 1.1.5 
language-gitignore 0.3.0 
language-haskell 1.13.2 
luna-dark-ui 0.1.1 
luna-dpi 0.1.2 
luna-studio 1.0.0 
luna-syntax 0.1.0 
minimap 4.29.6 
minimap-codeglance 0.4.7 
minimap-cursorline 0.2.0 
minimap-find-and-replace 4.5.2 
minimap-git-diff 4.3.1 
minimap-highlight-selected 4.6.1 
multi-cursor 2.1.5 
sort-lines 0.14.0 
split-diff 1.5.0 
web-view 3.0.0 

IR serialization (pre-compiled libraries implementation)

Handle markers in toplevel definitions

Module processing pass ignores marked defs on toplevel. Should ignore the markers and make the function usable.

Uncaught TypeError: parsed.forEach is not a function

Steps to reproduce:

1. Download Luna installer
2. Run Luna installer
3. Run /Applications/LunaStudio.app
4. In Private section, click on plus sign to create a project

Atom: 1.18.0 x64
Electron: 1.3.15
OS: Mac OS X 10.13.1
Thrown From: luna-studio package 1.0.0

Stack Trace

Uncaught TypeError: parsed.forEach is not a function

At /Users/yigitozkavci/.luna/config/luna-studio/1.0/atom/packages/luna-studio/lib/projects.coffee:160

TypeError: parsed.forEach is not a function
    at Request._callback (/packages/luna-studio/lib/projects.coffee:160:32)
    at Request.self.callback (/packages/settings-view/node_modules/request/request.js:186:22)
    at emitTwo (events.js:106:13)
    at Request.emit (events.js:191:7)
    at /packages/settings-view/node_modules/request/request.js:1163:10)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:188:7)
    at /packages/settings-view/node_modules/request/request.js:1085:12)
    at IncomingMessage.g (events.js:286:16)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Commands

  3x -1:16.2.0 dev-live-reload:reload-all (atom-workspace.workspace.scrollbars-visible-when-scrolling)
     -0:09.9.0 tree-view:show (atom-workspace.workspace.scrollbars-visible-when-scrolling.theme-luna-syntax.theme-luna-dark-ui)

Non-Core Packages

advanced-open-file 0.16.6 
busy-signal 1.4.3 
color-picker 2.2.5 
column-select 0.2.0 
cursor-history 0.11.1 
custom-window-title 1.0.4 
file-icons 2.1.11 
git-blame 1.2.2 
git-history 3.3.0 
git-log 0.4.1 
git-plus 7.9.3 
hasklig 0.4.0 
highlight-line 0.12.0 
highlight-selected 0.13.1 
intentions 1.1.5 
language-gitignore 0.3.0 
language-haskell 1.13.2 
luna-dark-ui 0.1.1 
luna-dpi 0.1.2 
luna-studio 1.0.0 
luna-syntax 0.1.0 
minimap 4.29.6 
minimap-codeglance 0.4.7 
minimap-cursorline 0.2.0 
minimap-find-and-replace 4.5.2 
minimap-git-diff 4.3.1 
minimap-highlight-selected 4.6.1 
multi-cursor 2.1.5 
sort-lines 0.14.0 
split-diff 1.5.0 
web-view 3.0.0 

Incorrect typecheck case

I've run into this wrong typecheck:

Expected type: [Int]
Actual type: *

What is more, in function powers type is correct:

Code:

def main:
    powers 1 . take 100
def powers s:
    Prepend s (powers ((-2)*s))

Extend Pretty Printer to Differentiate Between Self and Other Arguments

With this code

a = 10
b = a . succ
c = a + a

we'd like to shorten (dotify) the a in c, and keep the one in b untouched. Current approach requires us to treat both occurences the same way, no matter their positions in the respective expressions.

Improve Time library for Luna

1. Add conversions between epoch ints and internal Time.
2. Add helper methods like Time.beginningOfDay, Time.endOfYear etc.
3. Add helpers for creating hours, days, possibly more, TimeIntervals.
4. Add printing Time with a given format.
5. The most devilish of them all: some rudimentary support for timezones is needed.

Finishing the WebSocket server library

Make Stdlib a Relocatable Package

We have it painfully copy-pasted between luna and luna-studio. It should be a separate repo used by the other 2.

Visualisations should scale with nodes

Visualisation is part of the node. The only things that behave differently are the name and expression.

Parametric Types Don't Mention Referenced Properties

Given a function which uses properties on a value:

The type doesn't mention the referenced properties:

I read the polymorphism as "forall b d" but it seems like I can't use the function for all types, I can only use the function when the value has a "mappend2" method.

Is the type I'm reading in the use of "mappend" accurate? Is it just not being printed correctly?

I see this as a big problem, because I can't determine the implementation of a function by reading the type, like I can usually do with polymorphic types. I don't know what values a function can take by looking at the type.

stack install fails on not finding visualization-api.git

Following the instructions for installation in README.md, the stack install failed with

fatal: repository 'https://github.com/luna/visualization-api.git/' not found

I think this comes from shell/stack.yaml, line 55.

location: {commit: ddfcd1e0372b93e947b380b911c123fe67227b21, git: 'https://github.com/luna/visualization-api.git'}

Use cases & documentation

Case for luna laziness problem

I have suspicion that in some cases luna is not lazy when we really need it to be. Console version of luna hangs on following code (I haven't tested it in luna studio):

import Std.Base
import Std.HTTP
import Std.System

def main:
    putStr (powers 1 . take 10 . toText)

def powers s:
    Prepend s (powers ((-2)*s))

benchmarking lexer and parser

Multiline list literals cause a parsing error

@piotrMocz commented on Sun Aug 20 2017

Say we have a datatype:

class Foo:
    a :: List Text

The following gives a parsing error:

def f:
    x = Foo [
        "ala",
        "ma",
        "kota"
    ]
    x

And the error says Unexpected token: x.

Http client drops params passed in the URI

The following code:

Http.getJSON "http://example.com?foo=bar"

results in a request with empty param list. In order to pass any query params we need to write

defaultHttpRequest "http://example.com" . setParam "foo" (Just "bar") . perform . json

but we should be handling params coming from the URI too.

Parser errors should contain line number

At the very least: Ideally they would tell you (natural language) what's wrong with the code.

Right now the numbers are very misleading: I expected them to be line/column numbers but I quickly found out they are not that :D