From WG 2.11
Jump to: navigation, search

IFIP WG2.11, meeting schedule

IFIP Working Group 2.11 Fourth Meeting


October 27-28, 2006, Portland, Oregon.

Your Checklist:

[ Directions to University Place]

If you are an observer and would like to give a talk, please add an abstract [ here]

  • If your proposal is not listed in "Well Developed Proposals", put it in the right format and send me an email to review it.
  • Please sign up for any sessions that you would like to attend in the following section.

Arrival: If you want to try to find someone else arriving at the same time, please add your arrival time [ here]

Sessions You can Sign Up for (right here)

  1. (Friday) Teaching Program Generation (Organizers: Eelco Visser. Participants: Walid Taha, Peter Sestoft, Jeremy Siek, Markus Pueschel, ... )
  2. (Friday) Assurance techniques for code generators (Organizers: Ewen Denney, Bernd Fischer. Participants: Oleg, Julia, Baris Aktemur, Tom Ellman, Manuel Fahndrich) ([Overview], [Summary])
  3. (Friday) Dependently-typed languages (Organizers: Stephanie Weirich. see attached notes).
  4. (Saturday) Library Specialization (Organizers: Yannis Smaragdakis, Peter Sestoft. Participants: Jeremy Siek, Harold Ossher, Stephanie Weirich, Baris Aktemur, Tom Ellman..., Manuel Fahndrich)
  5. (Saturday) Embedded Systems (Organizers: Kevin Hammond, Paul Kelly. Participants: Walid, Albert Cohen [Sat only], Oleg, Julia, Markus Pueschel). Notes on the outcomes of this session have now been attached to this page.

Preliminary Schedule

| Date | Time | Activity | | Fri 10/27 | 07:30-08:30 | Breakfast | | | 08:30-12:00 | Guest talks | | | | 8:30-9:00: Tom Ellman | | | | 9:00-9:30: Manuel Fahndrich | | | | 9:30-10:00: Emir Pasalic | | | | 10:00-10:30: Break | | | | 10:30-11:00: Markus Pueschel | | | | 11:00-11:30: Jeremy Siek | | | | 11:30-12:00: Laurence Tratt | | | 12:00-01:30 | Lunch | | | 01:30-02:30 | Advertisment talks for sessions | | | | 1:30-1:45 teaching program generation | | | | 1:45-2:00 assurance techniques | | | | 2:00-2:15 library specialization | | | | 2:30-2:45 embedded systems | | | 02:30-05:30 | Working Sessions | | | | * teaching program generation | | | | * assurance techniques | | | 06:00-07:30 | Dinner |

| Date | Time | Activity | | Sat 10/28 | 07:30-08:30 | Breakfast | | | 08:30-11:45 | Working Session | | | | * library specialization | | | | * embedded systems | | | 11:45-01:30 | Lunch | | | 01:30-05:00 | Summary talks from working sessions | | | 05:00-05:30 | Business meeting |

Well Developed Proposal

Proposal: WG2.11 Session on library specialization

Organizers: Yannis Smaragdakis, Peter Sestoft

Participants: Please sign up above

Peter raised the subject of library specialization in his message below and provided a motivating example that we can all work on. His specification document is an attachment to this page: [Peter's Overview]

What we are interested in is language mechanisms for structured, type-safe specialization of types and modules. This is unlike traditional code specialization constructs such as the C/C++ #ifdef, since #ifdef allows inconsistent uses (e.g., defining a method under a #ifdef but calling it outside).

This can be viewed as a reflective meta-programming technique: our static type system allows an "if" construct and keeps track of pieces of code that are only included conditionally. Specifically we want to ask questions like:

  • what is the right type system for such a mechanism?
  • can this be integrated in current languages and how?
  • what is the compilation model when we have conditional methods (e.g., are methods under unsatisfied conditions always removed from the result of compilation, or should they occasionally stay to support separate compilation?)


Proposal: WG2.11 Session on program generation in embedded systems

Organizers: Paul Kelly and Kevin Hammond

Participants: Please sign up above

Embedded systems (broadly-interpreted) provide compelling motivation for the study of program generation. Embedded development suffers from limited resources, power and performance constraints, a large hardware-software co-design space, difficulties with testing and debugging, and the difficulty of deploying bug-fixes. For these reasons, Program Generation is widely used. Examples include:

  • Generating VLSI and FPGA designs
  • Generating code for multi-processor system-on-chip devices
  • Domain-specific languages and compilers
  • Component configuration, feature composition, product line generation
  • Specialisation
  • Runtime reconfiguration
  • Automatic adaptation to platform
  • Design-space exploration.

The objective of this session is to expose the potential for our community's techniques in embedded systems, to identify some actual and promising success stories, to identify some common foundations, and to identify challenges for future work and collaboration. Contributions (short talks) are invited to address these goals.


Proposal: WG2.11 Session on teaching program generation

Organizer: Eelco Visser

Participants: Please sign up above

Getting program generation accepted and used starts with teaching our students. How should we incorporate program generation in the computer science curriculum? This session gives room for expressing views and reflecting on experience. Issues include:

  • experience with teaching courses on/involving program generation
  • place in the curriculum (wrt other material)
  • theoretical and conceptual framework
  • tools
  • course organization
  • topics and their relative priority (what is important)
  • suitable example domains


Proposal: WG2.11 Session on assurance techniques for code generators

Organizers: Ewen Denney, Bernd Fischer

Participants: Please sign up above

Automated code generation offers many compelling advantages to software development but reliability is still often seen as a weak point, at least in safety-critical domains. Indeed, code generators can even produce code which is more difficult to verify and certify than manually developed code.

This session will explore different techniques for assuring the output of code generators. There are different forms of assurance that we might aspire towards. For example:

  • compliance with requirements
  • compliance with specification/model
  • coding standards
  • traceability
  • appropriate documentation
  • absence of run-time errors

Various techniques can be used to address this general problem and we would like to discuss the challenges and issues which arise for the different paradigms of code generation, as well as different application domains.

Underdveloped Proposal

I'm not sure what the intended format should be, but I added topics that I would be interested in and added my name to them. If others do the same, it may become clear which would be popular topics. Probably the topics should be specified more at some point.

-- Main.EelcoVisser


I'm interested in:

  • Program transformation - in particular tools for domain-specific optimisations (and analyses), and active libraries
  • Generation of hardware designs (and generation of parallel, embedded and hardware/software codesigns)

-- Main.PaulHJKelly - 14 Jul 2006


I'm interested in:

  • embedded software and dependent types
  • synchronous/asynchronous languages for real-time systems
  • hardware description languages

Edwin Brady has been looking at the first problem from the types for resource perspective. I know Walid is also interested from the perspective of resource-aware-programming. Any other takers to put together a session?

I'm also particularly interested in exploring the issues in "crossover" synchronous/asynchronous notations such as Lucid Synchrone (with Marc and Albert?). I'm not sure there's a clear "challenge application" here, more a collection of problems?

Also, this is probably not mature enough for an open session, but I'd be interested in talking to like-minded people (Chris L, Paul K?) about program generation for Grid computing. I'm thinking of skeleton-based/template-driven approaches at a workflow level, probably on a dynamic generation basis.

-- Main.KevinHammond - 19 Jul 2006


I'm most interested in language for specifying program transformations and generation of hardware designs.

I would also be interested in hearing about MDE vs DSL and program generation for grid computing.

-- Main.JuliaLawall - 24 Jul 2006 (why are we all named main? :)


Oleg Kiselyov suggests:

- software radio as an easy and immensely practical example of code generation with static assurances (currently, they use Python to generate C++ code, and state typing constraints (like the demodulator and the filter both communicate single-precision complex numbers) in the _comments_ of the Python code). Certainly we can do better.

- complex optimization of numeric code (at the very least, partial loop unrolling and simple loop transformations). The optimizations are written independently of the code and can be applied to the naive code.

- staging and delimited continuations. Staging and code migration.

- staging and generic programming (in the spirit of `Scratch your boilerplate'). Implementing SYB in MetaOCaml while preserving equational reasoning. Using staging to implement a capability-safe subset of OCaml.

-- Main.JuliaLawall - 26 Jul 2006


Peter Sestoft suggests:

  • Runtime code generation (RTCG) for managed platforms, that is, Java

Virtual Machine and the Common Language Infrastructure, aka Microsoft .NET. We have some recent results on implementing spreadsheets using RTCG for .NET.

  • Generation of specialized libraries. We don't have any results

here, but a big wish: The C5 library (www.itu.dk/research/c5) is a very comprehensive generic collection library for C#. However, you pay for all the great functionality (at least in memory) even when you don't need it. How can one allow developers to generate specialized (reduced) versions of this library code that suits their needs, in a practical and maintainable way?

  1. theory, you could use a huge number of #if ... #end directives,

but that makes the implementation unmaintainable, and there's no guarantee that those #if's are inserted in a consistent and meaningful way. Much the same can be said for conditional methods. Aspects will (at present) make the implementation too slow.

Also, there's a question of testing. We have a large number of unit tests. Conceivably, one could generate a million different versions of the library. How describe which unit tests should be expected to succeed in each of those versions?

-- Main.JuliaLawall - 06 Aug 2006

-- I'm very interested in languages for program generation and transformation, especially safe static reflection over existing programs.

Resource-aware program generation sounds intriguing and I'll probably be interested in participating in a session like that.

-- Main.YannisSmaragdakis - 10 Aug 2006


-- Ewen Denney - 4 Oct 2006

I'm interested in any optimization or concurrent/parallel programming topic, and in particular:

  • as proposed by Kevin, in a dedicated discussion, on synchronous/asynchronous language

constructions for predictable concurrent programming and efficient code generation;

  • in generative techniques that preserve equational reasoning, type safety, while allowing complex (loop, storage, data layout) optimizations to be performed; the SDR application proposed by Oleg

is great.

Unfortunately, I will only attend the second day of the meeting.

-- Albert Cohen - 31 Aug 2006

I'm not proposing a session on this at this late stage, but I have become interested in generation of code for high-quality user interfaces based on descriptions of what needs to be shown. To achieve high visual quality, there would have to be a lot of support for hand-tailoring of the visual appearance, leading to interesting round-tripping issues.

-- Main.HaroldOssher - 09 Oct 2006


Tankut Baris Aktemur, Edwin Brady, Martin Bravenboer, Albert Cohen, Krzysztof Czarnecki, Ewen Denney, Tom Ellman, Manuel Alfred Fahndrich, Bernd Fischer, Kevin Hammond, Sam Kamin, Gabor Karsai, Paul H J Kelly, Oleg Kiselyov, Ralf Lammel, Julia Lawall, Anne-Francoise Le Meur, Crista Lopes, John O'Leary, Harold Ossher, Emir Pasalic, Markus Pueschel, Peter Sestoft, Tim Sheard, Yannis Smaragdakis, Walid Taha, Laurence Tratt, Eelco Visser, Stephanie Weirich

File Attachments