View Source Document


(Note, some of these are possibly long-term plans.)


Just as we have defined fun in terms of fexprs, we can define macro in terms of fexprs. (It is expected to return a literal chunk of program, which we then evaluate.)

It would just be a fexpr that evaluates (in the calling environment) what the body evaluates to.

Disjointness of types

Insofar as the types of Robin are disjoint, we can have a typeof intrinsic which returns a literal symbol such as number, list, and so forth, instead of n predicates. In practice the predicates are useful, and would be retained in the stdlib. But this could make the set of intrinsics smaller.

Opaque type

Values of "opaque" type. Intrinsics wrap and unwrap. But note that only the functions implementing the ADT are guaranteed to be able to unwrap an opaque value, and those functions might be implemented natively, rather than as Robin code that uses wrap and unwrap.

Then, can we provide environments as an abstract type? We would also provide env->alist and alist->env so they can be worked with easily. But they could be used natively to support symbol lookup, and if they are implemented as trees or hash tables, this might have performance benefits. (Or perhaps not.)

Opaque type might also be useful for internals, e.g. signaling to runtime system that an error occurred.


(compose f1 f2) to compose two operators.

(modulo x y) which is always positive, change remainder to be sign of divisor (like R6RS.)

let and choose follow the same pattern. Consider a general chain combinator such that (chain bind (...) ...) is let and (chain if (...) ...) is choose.

Other libs

lispish lib, that just gives you all the old jargon-y names as aliases.


rename form.


Some way to make it easier to test reactive programs, i.e. some way to provide mock facilities. (Actually, do we need this? Or rather, how reactor-specific is this? You can just test the transducer itself, feeding it a set of mock events.)

The QuickCheck tests for equivalency don't seem to be very strong. They might even be outright wrong. Generally, lots and lots more could be done with the QuickCheck tests.


Finish the tutorial (recursive fexprs, advanced usage of reactors).


Perhaps namespace each event name.

A more involved environment, with more facilities than just line-terminal. Multiplexed I/O would be a start, could write an IRC client. Could also define an environment for web pages.

For that matter, HasteMain.hs should inject facilities that only make sense in the HTML5 DOM.

Subscription and unsubscription from facilities using standard commands.

More elegant way for handling abort responses (they should not trigger events -- because this can lead to a cascade of abort responses, if the reactor is erroneously handling those events too -- but they should be displayed if requested.)

Allow only one reactor. (Its transducer can be composed from multiple operators, instead of having multiple reactors.)

Example programs

Hunt the Wumpus.

Implementation of a concatenative language in an idiomatic style, taking a list like (1 2 + 3 *) and folding compose over it to obtain a function, and applying that function.


Rename "small" to "base".

Rename fun to function. This is because Robin prefers full words over abbreviations, which are jargon-y.