On this page:
unclear/  c
clear/  c
fulfilled/  c
advance/  c
unlike-asset/  c

1 Fundamentals

An unlike-asset/c value (henceforth "asset") is either fulfilled or unfulfilled. If unfulfilled, the asset is an advance/c procedure that returns a new, advanced asset in an unfulfilled or fulfilled state. If fulfilled, the asset is not a procedure at all. The fulfilled state is final.

In this collection, unlike assets may depend on one another. This is the status quo for any multimedia project such as video compositions, web pages, and video games. All dependencies must be fulfilled before advancing any asset, so no circular dependencies are allowed.

Dependencies are referenced by freeform unclear strings that describe other assets, like a URI or a relative path string. An instance of unlike-compiler% must clarify these strings and delegate work to procedures that can fulfill the assets under the clear/c names. An unlike-compiler% instance can also mark changes on an asset’s value and control how that change ripples to dependencies.


unlike-compiler% : class?

  superclass: object%

An abstract class that coordinates asset fulfillment.
Depending on your requirements and the complexity of your project, you may need to use custodians, threads, engines, places, or other constructs to coordinate different instances of this class.


(send an-unlike-compiler clarify unclear)  clear/c

  unclear : unclear/c

Override this method to deterministically map an unclear string to a clear name for an asset. By default, clarify is the identity function.

Once assets have clear names we need to decide what to do with them by delegating work out to appropriate procedures.


(send an-unlike-compiler delegate clear)  unlike-asset/c

  clear : clear/c
Override this abstract method to deterministically return the first value to represent an asset of name clear.

If you want your terminal value to be a procedure, wrap it in a box, list, etc.

If delegate returns an advance/c procedure, that procedure must accept the same clear name and the instance of the compiler as arguments, and either return the next advance/c procedure to pass on responsibility, or a terminal value that isn’t a procedure at all.

Any procedure in the implied chain of fulfillment can (and should) add! dependencies to the compiler as they are discovered. If this occurs, the subsequent procedure will not be called until those dependencies are fulfilled.

Once clarified names can be used to delegate work to procedures, you can compile!


(send an-unlike-compiler compile! [#:changed changed 
  #:removed removed]) 
  (hash/c clear/c fulfilled/c)
  changed : (listof clear/c) = null
  removed : (listof clear/c) = null
Fulfills all assets on the current thread and returns a hash mapping clear names to the final value associated with each asset. Will raise exn:fail if a call to compile! is already running for the instance.


  • The encapsulated model will record all asset activity.

  • Events are sent to unlike-asset-logger.

If changed or removed are not empty, then the compiler will first modify the underlying model to reflect changed or removed assets according to Responding to Change.


(send an-unlike-compiler lookup clear)  unlike-asset/c

  clear : clear/c
Return the current value associated with a clear name in the compiler. Will raise exn:fail if no asset is found.


(send an-unlike-compiler add! clear    
  ripple])  void?
  clear : clear/c
  dependent-clear : (or/c clear/c boolean?) = #f
  ripple : (or/c ripple/c boolean?) = #f
Adds a clear asset name to the compiler. If dependent-clear is a clear name, then the compiler will understand that clear is a dependency of dependent-clear. Will raise exn:fail if a circular dependency forms.

ripple controls how a change in clear’s asset propagates to dependent-clear’s asset. By default, the dependent asset will be rebuilt. Otherwise the change will produce an asset value from a provided ripple/c procedure.

For information on the change model, see Responding to Change.