AL-2: Synopsis
After 3 years of work on a compiler for ALDiSP, enough new
ideas have accumulated for a major overhaul of the language. The current
working name is AL-2.¹ Ideas abound; the
most central one is to abandon the suspension model of control and revert
to a more traditional stream-based semantics. Since AL-2 will also enjoin a
static type system, the liguistic gap between our product and the
competition (i.e., LUSTRE, SILAGE, SIGNAL) shrinks somewhat.²
Ideas & Concepts
Now, what are the new and improved ideas and concepts which AL-2 is to
provide? Here are a few:
- 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
The latest incarnation of the ``standard AL-2 description'' is
"An Introduction to The AL-2 Signal Processing Language: A Successor to
ALDiSP" (91 k
dvi,
193 k ps).
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...
All kinds of internal stuff can be found in this subtree. Actually, this is my
first attempt at HTMLized project documentation. Lets see how it works out.
This page was last changed on Mar 06 1995, 14:52 by mfx@pobox.com. Comments and corrections welcome.