Re: [sc-dev] Towards SC 4

Hi all,

On Tue, Nov 12, 2013 at 1:00 PM, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx> wrote:

On Nov 12, 2013, at 11:52 AM, Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:

> Perhaps it would make sense to create a new interpreter from scratch,
> only building upon the existing syntax and extend it with namespaces
> and modules etc, as well as cleaning away *some* of the syntactic
> sugar? What about LLVM as backend? JIT compilation into real
> super-fast machine code? That would be tasty :)

And this is the kind of thinking that I think we should be doing :)

I've been thinking about LLVM too, very tempting. We would benefit from any advances at the LLVM level. For example, some people at Berkeley are extending LLVM intermediate representation specifically for real-time purposes [1].

Regarding piggybacking on another language, such attempts are interesting and welcome, but I simply wouldn't call that SC4. Firstly, such approaches would almost exclusively mean writing libraries for a particular language instead of developing a language itself, and that's considerably less interesting. Secondly, there are such attempts already (scala, octave, ...), and there will be more in future for sure, and then why call any one of these the "official" part of the SC4 package? I think only a SC language on its own deserves being considered an "official" part of the SC package.

In general, I like modularity and I think software should be moving in the direction of increased de/composability to increase solution (code) re-use. From that perspective, I like the current separation between audio server and lang, and I would like to keep this. Instead of bringing them back closer together, we should rather work to improve their cooperation (read synchronicity, determinstic communication), while keeping them as separable and as individually-reusable as possible.

Multi-rate is my big interest. I'm currently working in this area here at University of Victoria, Canada, on the basis of the existing Marsyas software framework. [2] The vision is a future multimedia dataflow framework that is quite flexible with regard to data types rates, while still maximizing RT (latency) and non-RT (throughput) performance. I've actually been brainstorming on possible ways for SC to benefit from my endeavors here.

Cheers,

Jakob

[1] Broman, David, et al. "Precision Timed Infrastructure: Design Challenges."Proceedings of the Electronic System Level Synthesis Conference (to appear). IEEE. 2013.

[2] http://marsyas.info/