archives

How to Generate (Hard) Real-Time Code from Declarative Programming Languages?

Hello all!

First let me emphasize I'm a bit of a noob with language design and implementation, so feel free to dumb things down in response (in fact I would prefer it!)

I'm interested in the possibility of generating code for hard-real-time software from a declarative language. Two examples I've seen are Lustre (for reliability software) and Erlang (not sure how this could work actually since it's a general purpose language...) But when I dig down to find out exactly HOW we know that these systems generate real-time code, I come up empty handed. Where are the white papers / books / etc on how to determine a) that real-time code can be generated from a particular semantics in the first place, and b) how is the code actually generated in practice? Alternatively, how might we answer the same questions for soft-real-time code generation? Finally, can we answer this question for VMs as well, such as with .NET CIL code?

Hopefully this area of research isn't still a black art :)

Parsing: The Solved Problem That Isn't

In the blog post Parsing: The Solved Problem That Isn't Laurence Tratt discusses some interesting unsolved practical problems with parsing especially in combining grammars

The general consensus, therefore, is that parsing is a solved problem. If you've got a parsing problem for synthetic languages, one of the existing tools should do the job. [...]

One of the things that's become increasingly obvious to me over the past few years is that the general consensus breaks down for one vital emerging trend: language composition. "Composition" is one of those long, complicated, but often vague terms that crops up a lot in theoretical work. Fortunately, for our purposes it means something simple: grammar composition, which is where we add one grammar to another and have the combined grammar parse text in the new language (exactly the sort of thing we want to do with Domain Specific Languages (DSLs)). To use a classic example, imagine that we wish to extend a Java-like language with SQL [...]

He goes on to mention several example problems:

  • Two LL or LR grammars may combine to produce a grammar that is neither.
  • Two unambiguous grammars may combine to produce an ambiguous grammar.
  • Two PEG grammars may combine to produce something that doesn't do what you want due to left bias.

What's the current state of the art?