AL-2: Synopsis

Ideas & Concepts

• There is only one kind of signal; the distinction between streams and pipes is gone.
• Signal are monomorphically typed; their elements must be arrays or scalars. Arrays can only have scalars as elements. Scalars are numbers, pairs of numbers, or atoms.
• Atoms are unique things that can be used as labels, names, strings, enumeration types, etc. Atoms can be represented as integers. It is impossible to generate new atoms at run time. It is possible to define types as sets of atoms. The best-known such set is Bool={true,false}. In case anyone hasn't guessed, the integer representation of these is {1,0}.
• All function definitions are top-level. The syntax is heavy on the declarative side. Functions don't return, they define (multiple) return values.
• There are modules, and they are defined and implemented syntactically (as name spaces). Separate compilation is the norm. Function types must be declared explicitly, and prior to use (not so much to make one-pass compilation possible, but for documentation's sake. Exported functions must be declared in "header files", anyway).
• Signals have two components: value and synchronicity. The latter determines when the former is well-defined (or accessible).
• There are a number of primitives to synchronize signals. Amongst these are sample+hold, delay, merge, and sample.
• Synchronicity is not defined in terms of a global clock (i.e., a ``fastest signal''), but via comparison with other signals only. Using the sample+hold primitive, it is even possible to exchange values between systems that share no known synchronization!
• There is no reason not to allow continuous signals, i.e. signals that are defined at every point of time. This way, an AL-2 specification can even describe hardware that is non-discrete in the time domain (non-discrete data domains are impossible, except as purely opaque data types. After all, a compiler wants to know how many bits are needed to store an entity.)
• Automapping is restricted to synchronous signals. Data-manipulating functions work only via automapping.
• Polymorphism, if allowed at all, is to be highly restricted. Efficient separately-compiled numeric functions must have been appropriately instantiated at translation. (This is actually not so much of a problem, since typical hardware only supports a few sensible combinations of word sizes. Also, all numeric types are primitive.)
• I am not yet sure whether AL-2 will be call-by-need or call-by-value. Lazy evaluation seems to be the simplest approach of dealing efficiently with all them differently-synchronized signals (i.e., the output signal synchronization drives the evaluation process -- especially important when non-discrete signals are considered!).
• In any case, the semantics of AL-2 must be really small! While the semantics of ALDiSP was in the league of PL-1 or ADA, AL-2's semantics should approach the size of Scheme's (i.e., 1-2 pages). There should be a static/dynamic semantics; the static semantics will only do the type-checking and -inference. The signal synchronization semantics should be kept separate from the basic evaluation semantics -- if possible, by syntactic/typechecking means!

AL-2: Documents

This describes the core of the language; a lot of the nifty features of ALDiSP that I originally planned to migrate to AL-2 in some fashion have been thrown out of the language (or deferred to extension layers), leaving a bare-bones signal-flow formalism that should be usable as an compiler's intermediate representation. The ``definition'' is not very complete, as can be seen from the list of open questions that can be found in the first section.

A few text documents on implementation considerations, syntax, etc.pp. have accumulated. I don't put these on the net, they would be too confusing for the unwary reader. (It is a much better idea to mail me with any questions you might have!)

The earliest document that at least tries to be complete and readable is probably the initial collection of half-done ideas.

See also my List of Publications.

Under Development...