[<<][meta][>>][..]
Wed Jan 26 08:26:32 EST 2011

Compile time vs. Run time

Thinking about this some more, a can see why it makes sense to have a
multi-stage language.  Emulating one in a single state language
requires trickery, or in Scheme, the jump to macros.

The point: it seems that the core of the DSP language is going to be a
composition mechanism with automatic state threading, keeping the
functional representation for analysis.  Keeping analysis might mean
keeping it in data-structure form and have an interpreter perform the
composition operation.

Additionally, it would be nice to use the rest of scheme to build
composition networks: moving that part to macros will make things
uncomfortable.  

It seems that these are at odds, at least in an untyped language.

An example would be to take a vector which is the output of some
computation, and use it as filter coefficients for a parallel circuit
of stateful objects.

What seems to be the problem is the inability to dispatch on the types
of functions in such a flexible way (i.e. on return times) as in
Haskell.

So is it possible to stay away from macros for building the
composition mechanism?

The problem is the classical one for staging and partial evaluation:
when is a loop a loop, and when is it expanded into multiple
instances?  There needs to be a way to express this.

Another conflict in Scheme: I have two very different meta levels: the
abstract interpretation part, and the macro part.  I really do not
want to complicate things by implementing composition in macros such
that it is no longer accessible on the abstract interpretation level.
In feldspar, array access is made abstract, such that the `map'
function can be made abstract also.  I feel this is really the way to
go.



[Reply][About]
[<<][meta][>>][..]