Nested asynchronous objects are a problem with Promises/A+, since you can't nest promises.
Compare Data.Task:
function AsyncMap() {
this.data = {}
}
// :: String, a -> Task<b, Unit>
AsyncMap.prototype.set = function(key, value) {
Nested asynchronous objects are a problem with Promises/A+, since you can't nest promises.
Compare Data.Task:
function AsyncMap() {
this.data = {}
}
// :: String, a -> Task<b, Unit>
AsyncMap.prototype.set = function(key, value) {
uses html; | |
uses prelude; | |
let style-sheets { |...xs| | |
map xs { |x| link href: x/url rel: x/kind type: "text/css" }; | |
}; | |
let search-panel { | |
uses jumper-skirt as jsk; |
On module systems in general, and AMD/CommonJS in particular: simplicity, community, etc.
On the performance implications of real-world applications with Promises/A+ for abstracting over asynchronous computations.
How command line interfaces usually suck beyond anything, and what we could do to get back the UNIX philosophy and more simplicity.
A short introduction to programming language theory and programming language design. Parsing, semantics, formal syntaxes, interpreters, optimizers and compilers.
[ | |
a: 1 | |
, b: 2 | |
, c: 3 | |
] | |
[ a: 1 | |
, b: 2 | |
, c: 3 | |
] |
# will suspend on every function call (very proof of concept, | |
# it will be really easy to get access to local variables, a | |
# full stack, and even live evaluate within any closure) | |
% node test.out.js | |
[suspended] foo() | |
> c | |
[suspended] bar(x) | |
> c | |
[suspended] bar(i - 1) |
function attributes(xs, name) { | |
return is_element(xs)? xs.getAttribute(name) | |
: is_array(xs)? xs.map(attributes) | |
: is_sequence(xs)? map(xs, attributes) | |
: /* otherwise */ raise(TypeError('Not supported.')) | |
} | |
// vs | |
function attributes(xs, name) { |
A delayed computation is a function that will do some computation when called. Because of the delayed nature the computation may be asynchronous so the function takes a callback.
Note: the term "delayed computation" is just a temporary name so we can talk about this idea, I do not recommend using this name as it's a) confusing and b) this concept is hard to name.
The Racket platform provides a robust set of tools for developing languages, mostly centered around the macro system and the #lang
protocol, which allows providing arbitrary readers to convert text input to syntax objects representing Racket modules. The REPL is a bit more complicated, however, because it has different rules—each expression needs to be dynamically read, assigned lexical context, expanded, compiled, evaluated, and printed, all in real time. (In that sense, perhaps the phrase “REPL” oversimplifies what Racket is doing, but that’s a separate conversation.)
So how does Racket accommodate this in the face of completely arbitrary user-defined languages, some of which may not even support interactive evaluation in a traditional sense? Racket mostly solves this problem by having a related but distinct set of protocols for managing runtime interactions that operates alongside #lang
.
Racket’s evaluation model divides pretty much ev
// data comes from here http://stat-computing.org/dataexpo/2009/the-data.html | |
// download 1994.csv.bz2 and unpack by running: cat 1994.csv.bz2 | bzip2 -d > 1994.csv | |
// 1994.csv should be ~5.2 million lines and 500MB | |
// importing all rows into leveldb took ~50 seconds on my machine | |
// there are two main techniques at work here: | |
// 1: never create JS objects, leave the data as binary the entire time (binary-split does this) | |
// 2: group lines into 16 MB batches, to take advantage of leveldbs batch API (byte-stream does this) | |
var level = require('level') |