- Haskell - Haskell.org

ANNOUNCE: Doc.vim - Haddock display and Haddock index goodies for Vim
by Claus Reinke 04 Mar '07

04 Mar '07

the recent discussion about a simpler url-interface to library haddocks prompted me to write some vimscript to make use of the existing interface. the initial idea was just to translate qualified name and package into a url to launch a browser with. but as people pointed out, having to know the qualified name and even the package makes for an inconvenient interface. so the second version read haddocks index files to populate a dictionary of unqualified names and symbols, pointing to possible qualifiers and urls. once we have such a handy documentation index, we can play other ide-style games as well, so the current version (attached) adds a few more goodies. some inspection necessary: this is not a proper, portable, out-of-the-box release! the script has been tested with gvim 7.0 on windows, using the haddocks released with ghc-6.4.1, and opera as the browser. to adapt it for other systems, you'll need to change some paths and probably the :start command. feedback/fixes welcome. what is on offer:-) :IDoc "<name>" -- suggest possible qualifiers, then launch doc browser :Doc "<qualname>","<package>" -- old-style invocation :DocIndex -- populate index from haddock index html files (takes a few secs) CTRL-X CTRL-U -- one of the user-defined insert-mode completions -- does now complete unqualified ids wrt the doc index _? -- for unqualified id under cursor, suggest possible qualifiers, browse _. -- replace unqualified id under cursor with fully qualified version so you can place your cursor on 'mapM_', type '_?', select Prelude or Control.Monad, and find out what it is all about. or you can type 'pres', and still in insert mode, type CTRL-X CTRL-U, find 'preservingMatrix' as one of the possible completions, and select it. or you can place your cursor on 'preservingMatrix', type '_.', select one of the options, and have it replaced with 'Graphics.Rendering.OpenGL.preservingMatrix'. (for those who believe in gui rather than functionality as the distinction between ides and editors, the last three use little popup menus in gui vim;) how to: read the script to check that it does what you'd expect, adapt where necessary, then :source it, run :DocIndex (this takes a few seconds, so we should probably cache the result in more vim-friendly format somewhere later..), and play. as usual, no guarantees of any kind. feel free to adapt this for your haskell filetype plugins. and i'm sure that the ideas carry over to other intelligent editors, so perhaps someone will come up with an emacs variant?-) enjoy, claus

1 0

ANNC: hoogle.el
by David House 02 Mar '07

02 Mar '07

Hoogle.el is a simple Emacs Lisp library that nicely integrates Hoogle into Emacs. http://haskell.org/haskellwiki/Hoogle.el Here's the docstring from the only function it provides: hoogle-lookup: "Lookup the identifier at point in Hoogle. If we can't find an identifier at the point, or with a prefix arg of 1, prompts for a name to look up. If we can find a Hoogle in the $PATH (using `executable-find' on `hoogle-local-command'), it will be used, unless `hoogle-always-use-web' is non-nil. For web Hoogling, the name is appended to `hoogle-url-base' and `browse-url' is invoked." The file is based on work by myself, Clemens Fruhwirth and Andy Hefner. I welcome any comments. -- -David House, dmhouse(a)gmail.com

1 0

Laziness and the IO Monad (randomness)
by Dave Tapley 02 Mar '07

02 Mar '07

Hi all, I am having a problem with the implementation of a program (a genetic algorithm) which requires randomness in it. It all hinges on the ability to generate something (in the example below an Int), then provide a function to update it such that the prelude's iteratefunction (or an equivalent) may be used. In my program I require that both the generation and the updating function contain randomness. I have drafted a (simplified) example of my problem: This code show a trivial case where randomness (and hence the IO monad) is not used and the first 10 elements of the produced list are printed: aNum :: Int aNum = 2 addTwo :: Int -> Int addTwo = (+) 2 firstTen :: [Int] firstTen = take 10 (iterate addTwo aNum) main :: IO () main = do print firstTen As required the program terminates printing: [2,4,6,8,10,12,14,16,18,20] Now I present my 'conversion' of this trivial case where we both generate a random number, and add a random amount to it upon each iteration. Again we only wish to print the first 10: import System.Random -- Taken directly from function 'rollDice' in Haskell98 report randNum :: IO Int randNum = getStdRandom (randomR (1, 6)) addRand :: Int -> IO Int addRand x = do y <- randNum return (x + y) firstTen :: IO [Int] firstTen = do infiniteNums <- iterateM addRand randNum return (take 10 infiniteNums) main :: IO () main = do tenNums <- firstTen print tenNums -- Monadic interpretation of prelude iterate definition iterateM :: Monad m => (a -> m a) -> m a -> m [a] iterateM f xM = do x <- xM mcons xM (iterateM f (f x)) -- Taken from prelude definition of sequence mcons :: Monad m => m a -> m [a] -> m [a] mcons p q = p >>= \x -> q >>= \y -> return (x:y) However this latter case gets stuck in an infinite loop, terminating on a stack overflow. My question asks why this is the case, when laziness should ensure only the first 10 cases need to be computed. If anyone wishes to suggest another way entirely to approach this problem that would also be welcome! Many Thanks, Dave

5 4

GTTSE 2007: 2nd call for participation (02-07 July) (registration open)
by Joost Visser 01 Mar '07

01 Mar '07

GTTSE 2007, 02-07 July, 2007, Braga, Portugal 2nd International Summer School on Generative and Transformational Techniques in Software Engineering http://www.di.uminho.pt/GTTSE2007 ** Registration is now open ** SCOPE AND FORMAT The summer school brings together PhD students, lecturers, technology presenters, as well as other researchers and practitioners who are interested in the generation and the transformation of programs, data, models, meta-models, and documentation. This concerns many areas of software engineering: software reverse and re-engineering, model-driven approaches, automated software engineering, generic language technology, to name a few. These areas differ with regard to the specific sorts of meta-models (or grammars, schemas, formats etc.) that underlie the involved artifacts, and with regard to the specific techniques that are employed for the generation and the transformation of the artifacts. The tutorials are given by renowned representatives of complementary approaches and problem domains. Each tutorial combines foundations, methods, examples, and tool support. The program of the summer school also features invited technology presentations, which present setups for generative and transformational techniques. These presentations complement each other in terms of the chosen application domains, case studies, and the underlying concepts. The program of the school also features a participants workshop. All summer school material will be collected in proceedings that are handed out to the participants. Formal proceedings will be compiled after the summer school, where all contributions are subjected to additional reviewing. The formal proceedings of the first instance of the summer school (2005) were published as volume 4143 in the Lecture Notes in Computer Science series of Springer-Verlag. TUTORIALS * Krzysztof Czarnecki (University of Waterloo) Model Evolution * Jean-Marie Favre (University of Grenoble) Software Linguistics and Language Engineering * Stan Jarzabek (National University of Singapore) Software Reuse Beyond Components with XVCL * Oege de Moor (Oxford University) Code Queries with Datalog * José Nuno Oliveira (University of Minho, Portugal) Data Transformation by Calculation * Markus Pueschel (Carnegie Mellon University) How to Write Fast Numerical Code * Walid Taha (Rice University) A Practical Guide to Building Staged Interpreters * Eelco Visser (Delft University of Technology, The Netherlands) Domain-Specific Language Engineering REGISTRATION Online registration for the summer school is now open. The registration form, as well as detailed information on conditions and fees, are available at: http://wiki.di.uminho.pt/twiki/bin/view/Events/GTTSE2007/Registration The number of participants is limited. Participants will be selected on the basis of the information they supply on their registration form. SUMMER SCHOOL CHAIRS * Ralf Lämmel (Program Chair), Microsoft Corp., Redmond, USA. * João Saraiva (Organizing Chair), Universidade do Minho, Braga, Portugal. * Joost Visser (Program Chair), Universidade do Minho, Braga, Portugal. ADDITIONAL INFORMATION For additional information on the program, venue, and other details of the summer school, please consult the web page: http://www.di.uminho.pt/GTTSE2007 For remaining questions please contact gttse2007 at di.uminho.pt.

1 0

Haskell with only one typeclass
by oleg＠pobox.com 28 Feb '07

28 Feb '07

Defining new typeclasses is regarded as an important part of Haskell programming, as the normal way of introducing overloaded functions. This message shows that if the ability to define typeclasses is removed, no expressivity is lost. If Haskell had only one, pre-defined typeclass with only one method, we could still do normal Haskell programming with standard and user-defined overloaded numerical functions, monads, monad transformers, etc. Haskell with only one typeclass can express all of Haskell98 typeclass programming idioms including constructor classes, plus multi-parameter type classes and some functional dependencies. If we additionally admit TypeCast as a pre-defined constraint, the rest of functional dependencies are expressible. Besides clarifying the role of typeclasses in Haskell as method bundles, this message proposes a model of overloading resolution that is simpler than that of Hall et al. Perhaps this model might be of interest to Haskell' committee. The present approach is inspired by HList's class Apply, which seems to be, after a small adjustment, the universal class. For clarity of terminology, we call as Haskell1 the language Haskell98 with no typeclass declarations but with a single, already declared typeclass C (which has two parameters related by a functional dependency). The programmers may not declare any typeclasses; but they may add instances to C and use them. We show on a series of examples that despite the lack of typeclass declarations, Haskell1 can express all the typeclass code of Haskell98 and then multi-parameter type classes and some (most useful?) functional dependencies. Haskell98 methods are defined as ordinary functions in Haskell1. To represent the rest of functional dependencies, we later define Haskell1' as an extension of Haskell1 with a pre-defined constraint TypeCast (which is not user-extensible and can be considered built-in). Finally we introduce the analogue of Haskell98 classes -- method bundles -- and use them for defining bounded existentials. Obviously Haskell1 is merely a subset of Haskell rather than a new language; the removal of typeclass declarations is a matter of discipline rather than that of syntax. We offer a model of overloading resolution that is a bit different from that of Stuckey and Sulzmann's `A theory of overloading.' When an instance is selected, its dependent arguments are improved (`typecast'). If an instance is not selected, no type improvement is applied. Granted, this model is not formalized. But then, this message is not an ICFP paper. The complete code described in this message is available at http://pobox.com/~oleg/ftp/Haskell/Haskell1/Class1.hs http://pobox.com/~oleg/ftp/Haskell/Haskell1/Class2.hs We first disclose our one and only type class: > class C l t | l -> t where ac :: l -> t The constraint C is pervasive, which makes some signatures in want of syntax sugar, which we purposely avoid for clarity. We start by building overloaded numeric functions, the analogue of Num. The following defines the functions `a la carte'. Later we shall see how to bundle them into what Haskell98 calls `classes'. We begin with addition, to be denoted (+$) to avoid the confusion with the Prelude. > data Add a > infixl 6 +$ > (+$) :: forall a. C (Add a) (a->a->a) => a -> a -> a > (+$) = ac (__:: Add a) Whereas (+) in Haskell was a method, here the overloaded addition is a regular function, albeit bounded polymorphic. As we shall see, the constraints of such functions are analogues of Haskell98 class constraints. The above signature, sans the constraint, is the same as that of Prelude.(+). We will see later a way to avoid writing the C constraint explicitly. Let's define the instances of the generic addition for Ints and Floats > instance C (Add Int) (Int->Int->Int) where ac _ x y = x + y > instance C (Add Float) (Float->Float->Float) where ac _ x y = x + y as well over Dual numbers > data Dual a = Dual a a deriving Show > instance C (Add a) (a->a->a)=>C (Add (Dual a)) (Dual a->Dual a->Dual a) where > ac _ (Dual x1 y1) (Dual x2 y2) = Dual (x1 +$ x2) (y1 +$ y2) The latter is defined inductively, with the addition over base types being the base case. > ta2 = let x = Dual (1::Int) 2 in x +$ x -- sample test Likewise, we define the overloaded multiplication. This time, we use partial signatures to avoid writing the C constraint: > infixl 7 *$ > mul_sig :: a -> a -> a; mul_sig = undefined > mul_as :: a -> Mul a; mul_as = undefined > x *$ y | False = mul_sig x y > x *$ y = ac (mul_as x) x y Functions frmInteger and shw are analogous. As in Haskell98, we use the available overloaded functions to define new generic functions. For example, > genf x = x *$ x *$ (frmInteger 2) > tm1 = genf (Dual (1::Float) 2) +$ (frmInteger 3) The complete code demonstrates the overloading of not only functions but also of plain values: minBound. Next we turn to constructor classes and Monads, which can be easily restricted as frequently desired. > data RET (m :: * -> *) a > data BIND (m :: * -> *) a b > ret :: forall m a. C (RET m a) (a->m a) => a -> m a > ret = ac (__::RET m a) > bind :: forall m a b. C (BIND m a b) (m a->(a -> m b)->m b) => > (m a->(a -> m b)->m b) > bind = ac (__::BIND m a b) We show one particular monad: Either e > instance C (RET (Either e) a) (a -> Either e a) where ac _ = Right > instance C (BIND (Either e) a b) > (Either e a -> (a->Either e b) -> Either e b) where > ac _ (Right x) f = f x > ac _ (Left x) f = Left x with the goal to demonstrate MonadError, which is defined in Haskell's monad transformer library as follows -- class Error a where -- strMsg :: String -> a -- class Monad m => MonadError e m | m -> e where -- throwError :: e -> m a -- catchError :: m a -> (e -> m a) -> m a In Haskell1, the above code becomes > data ERROR a > strMsg :: forall a. C (ERROR a) (String->a) => String -> a > strMsg = ac (__::ERROR a) > instance C (ERROR String) (String->String) where ac _ = id > data ThrowError (m :: * -> *) a > throwError :: forall e m a b t1 t2. > (C (ThrowError m a) (e -> m a), C (RET m a) t1, C (BIND m a b) t2) => > e -> m a > throwError = ac (__::ThrowError m a) Here the constraints C (RET m a) t1 and C (BIND m a b) t2 are not called for, but we specified them anyway. That is, we require that `m' be an instance of a Monad. These extra constraints are Haskell1 analogue of Haskell's `class constraints'. The definition of catchError is similar. The Either e monad is an instance of MonadError > instance C (ThrowError (Either e) a) (e -> Either e a) where ac _ = Left > instance C (CatchError (Either e) a) > (Either e a -> (e -> Either e a) -> Either e a) where > ac _ (Left x) f = f x; ac _ x _ = x so we can write a test > te1 x = runEither $ catchError ac (\e -> ret e) > where > ac = (if x then throwError "er" else ret (2::Int)) `bind` > (\x -> ret (x *$ x)) `bind` (ret.shw) > runEither :: Either a b -> Either a b; runEither = id > te1r = (te1 True, te1 False) The MonadError example demonstrated that we already have some functional dependencies. To get them in full, we extend Haskell1 with the ``pre-defined'' constraint TypeCast. For example, to express the following Haskell method of two arguments with the type of the first argument determining the types of the result and of the second argument -- class FC3 a b c | a -> b c where fc3 :: a -> b -> c -- instance FC3 Bool Char Int we write in Haskell1' > data FC3 a b c > fc3 :: forall a b c. C (FC3 a b c) (a->b->c) => a->b->c > fc3 = ac (__::FC3 a b c) > instance TypeCast (FC3 Bool b c) (FC3 Bool Char Int) > => C (FC3 Bool b c) (Bool->Char->Int) where ac _ x y = 1 > tfc3 = fc3 True 'a' > tfc31 = fc3 True undefined The latter two sample definitions are accepted as they are. Without the functional dependencies, however, we would have needed type annotations. The accompanying complete code has the expanded example. Finally, we introduce the analogue of Haskell98 `classes' -- bundles of methods -- whose compelling application is bounded existentials. Let's define the Num bundle and numeric functions that are truly NUM-overloaded > data NUM a = NUM{nm_add,nm_mul :: a->a->a, > nm_fromInteger :: Integer->a, nm_show :: a->String} > data CLS a > instance (C (Add a) (a->a->a), C (Mul a) (a->a->a), > C (FromInteger a) (Integer->a), > C (SHOW a) (a->String)) > => C (CLS (NUM a)) (NUM a) where ac _ = NUM (+$) (*$) frmInteger shw We re-visit the overloaded addition, multiplication, show and fromInteger functions, defining them now in terms of the just introduced `class' NUM. We should point out the uniformity of the declarations below, ripe for syntactic sugar. For example, one may introduce NUM a => ... to mean C (CLS (NUM a)) (NUM a) => ... > infixl 6 +$$; infixl 7 *$$ > (+$$) :: forall a. C (CLS (NUM a)) (NUM a) => a -> a -> a > (+$$) x y = nm_add (ac (__:: CLS (NUM a))) x y and similarly for the other operations. We are in a position to define a bounded existential, whose quantified type variable 'a' is restricted to members of NUM. The latter lets us use the overloaded numerical functions after opening the existential envelope. > data PACK = forall a. C (CLS (NUM a)) (NUM a) => PACK a > t1d = let x = PACK (Dual (1.0::Float) 2) in > case x of PACK y -> nshw (y *$$ y +$$ y +$$ (nfromI 2))

1 0

TFP 2007: Last Call for Participation
by TFP 2007 28 Feb '07

28 Feb '07

Dear Colleagues, The deadline to register for TFP 2007 is quickly approaching. You may register at: http://cs.shu.edu/tfp2007/registration.html . Also, please be advised that the deadline to make hotel reservations at the guaranteed rate for TFP 2007 participants is also quickly approaching. Hotel information can be found at: http://cs.shu.edu/tfp2007/accomodations.html . You may browse the program and schedule for TFP 2007 at: http://cs.shu.edu/tfp2007/schedule.html . We look forward to seeing you in NYC!!! Cheers, Marco ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/

1 0

ANNOUNCE: Gtk2Hs version 0.9.11 released
by Duncan Coutts 28 Feb '07

28 Feb '07

Gtk2Hs - A GUI Library for Haskell based on Gtk+ Version 0.9.11 is now available from: http://haskell.org/gtk2hs/download/ The source tarball and an installer for Windows are available. Packages are available for Gentoo and FreeBSD. Packages for various other platforms should become available soon (hopefully including Fedora, Debian and Darwin). Changes since 0.9.10: * works with GHC 6.6 and Gtk+ 2.10.x * new typed tree/list widget API * new OpenGL widget added * new cairo SVG package (for rendering SVG images on cairo surfaces) * new implementation of the Graphics.SOE API * new glade tutorial * many more demo programs (clock, graph, traffic congestion sim, fonts, noughts & crosses, opengl, svg and updated profile viewer and other tree/list demos) * much smaller binaries (thanks to the ghc 'split objs' feature) * many bugs fixed * new functions for working with the threaded RTS * various minor documentation improvements Gtk2Hs feature highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.8 API * support for several additional Gtk+/Gnome modules: * Glade visual GUI builder * cairo vector graphics library * SVG rendering for cairo * OpenGL extension (works with HOpenGL) * GConf, Gnome's system for storing app preferences * SourceView, code editor widget with syntax highlighting * the Mozilla browser rendering engine in a widget * an implementation of the Graphics.SOE API * extensive haddock API reference documentation * multi-platform support with native look * LGPL licence Platforms and requirements: * builds from source on Linux, Windows, MacOS X, FreeBSD and Solaris * builds with GHC 6.2 - 6.6 * works with Gtk+ version 2.0 through to 2.10 * SVG support requires librsvg version 2.16 or later Please report all problems to gtk2hs-devel(a)sourceforge.net Contributions and feedback are also most welcome. Windows release notes: The installer expects GHC 6.6 or 6.4.2. Support for GHCi is only available with GHC-6.6. Profiling libs are included (though you do not need to install them if you want to save disk space) The installer now comes bundled with Gtk+ itself so there's no need to download it separately. Hopefully this should also make the installation process a bit more reliable if only by reducing the number of configuration combinations. The windows build does not include the svgcairo, sourceview, gconf or mozembed packages since they introduce rather a large number of dependencies and would make the installer a much bigger download. Duncan (on behalf of the Gtk2Hs team)

1 0

Re: [Haskell] [Fwd: Re: Computer Language Shootout]
by Andrzej Jaworski 27 Feb '07

27 Feb '07

The examples I pointed to seem to share strong and relatively consistent logic of a program. In case of large GA (e.g. Royal Road Problem) and IFP (e.g. ADATE) SML was exhaustively proved to predict this logic much better. In case of Algebraic Dynamic Programming C compiler seems to address specific properties of a program more adequately which leads to substantial improvements in optimization. It is important to stress that we deal in ADP with strong logic of the domain application. Handcrafting C code for regular applications does not show that kind of advantage, so it wouldn't leave Haskell in the dust. In general declarative nature has the edge over C craftsmanship (see: http://www.clip.dia.fi.upm.es/papers/carro06:stream-interpreter-TR.pdf)

5 9

[Fwd: Re: Computer Language Shootout]
by Simon Marlow 27 Feb '07

27 Feb '07

Forwarding on behalf of Andrzej Jaworski <himself(a)poczta.nom.pl>: -------- Original Message -------- From: Andrzej Jaworski <himself(a)poczta.nom.pl> Dear fellows, It is ironic that just after SPJ disclosed Comments from Brent Fulgham on Haskell and the shootout the situation has radically changed for the worse. Without knowing that I committed a blunder referring to the damn benchmark http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all together with multicore support arguments when trying to convert a prominent OCaml programmer to Haskell. Now they know more of us:-) What a language it is that jumps 30% up and down on benchmark while other languages gracefully stay in line? Can any of you explain the reason for this disgraceful degradation in Computer Language Shootout? Clean has also declined in these benchmarks but not that much as Haskell. According to John van Groningen Clean's binary-trees program in the previous shootout version used lazy data structure which resulted in lower memory usage and much faster execution. That was removed by the maintainer of the shootout and replaced by a much slower one using strict data structure. I fear that if laziness accounted for previous good scores of GHC then algorithms where laziness is downplayed must be responsible for that anecdotal opinion that Haskell can be extremely slow. For example: on Royal Road Problem in genetic algorithms http://www.dcs.ed.ac.uk/home/stg/sfpw/book/Garmendia-Doval/cameraready.ps Haskell was found to be on average over 500 times slower than SML implementation! If such extreme variations in performance are inherent for Haskell then the support for multicore rather than boosting its relative performance (against e.g. one-core-bound OCaml) may merely amplify Haskell unevenness to the point where programming becomes more of an art than a science like it is in Prolog. Perhaps making a collective effort towards benchmarking Haskell programs and analyzing the results in some methodic way could prove helpful? Regards, Andrzej Jaworski

14 14

AOSD 2007: call for participation
by Oege.de.Moor＠comlab.ox.ac.uk 26 Feb '07

26 Feb '07

AOSD 2007 International Conference on Aspect-Oriented Software Development Vancouver, BC, March 12-16 AOSD is the premier conference on software modularity that crosscuts traditional abstraction boundaries. This year's programme includes several papers from related communities, and a schedule of the research track is included below. The full proceedings can already be accessed in the ACM digital library at: http://portal.acm.org/toc.cfm?id=1218563&idx=SERIES10702&type=proceeding&co… Furthermore citation details are available on DBLP at http://www.informatik.uni-trier.de/~ley/db/conf/aosd/aosd2007.html For further information on AOSD 2007 and to register, visit http://aosd.net/conference The deadline for the hotel discount is this Friday. -------------------------------------------------- AOSD 2007: RESEARCH PROGRAM Session 1: Applications Wednesday, 11:00-12:30 Session Chair: Laurie Hendren Aspect-Oriented Application-Level Scheduling for J2EE Servers Kenichi Kourai, Tokyo Institute of Technology Hideaki Hibino, Tokyo Institute of Technology Shigeru Chiba, Tokyo Institute of Technology Framework Specialization Aspects André Santos, Tampere University of Technology Antónia Lopes, University of Lisbon Kai Koskimies, Tampere University of Technology An Aspect-Oriented Approach to Bypassing Middleware Layers Omer Demir, University of California Davis Premkumar Devanbu, University of California Davis Eric Wohlstadter, University of British Columbia Stefan Tai, IBM Research Session 2: Early aspects, models and design Wednesday, 14:00-15:30 Session Chair: Eric Eide Semantics-Based Composition for Aspect-Oriented Requirements Engineering Ruzanna Chitchyan, Lancaster University Awais Rashid, Lancaster University Paul Rayson, Lancaster University Robert Waters, Lancaster University >From Aspect-Oriented Design to Aspect-Oriented Programs: tool-supported translation of JPDDs into Code Stefan Hanenberg, University of Duisburg-Essen Dominik Stein, University of Duisburg-Essen Rainer Unland, University of Duisburg-Essen A Static Aspect Language for Checking Design Rules Clint Morgan, University of British Columbia Kris De Volder, University of British Columbia Eric Wohlstadter, University of British Columbia Session 3: Tools Wednesday, 16:00-17:30 Session Chair: Mik Kersten Expressive Programs through Presentation Extension Andrew D. Eisenberg, University of British Columbia Gregor Kiczales, University of British Columbia A Graph-Based Approach to Modelling and Detecting Composition Conflicts Related to Introductions Wilke Havinga, University of Twente Istvan Nagy, ASML Lodewijk Bergmans, University of Twente Mehmet Aksit, University of Twente Debugging with Control-Flow Breakpoints Rick Chern, University of British Columbia Kris De Volder, University of British Columbia Session 4: Programming language semantics Thursday, 11:00-12:30 Session Chair: Hidehiko Masuhara Open Bisimulation for Aspects Radha Jagadeesan, School of CTI, DePaul University Corin Pitcher, School of CTI, DePaul University James Riely, School of CTI, DePaul University Tribe: A simple Virtual Class Calculus Dave Clarke, Centrum voor Wiskunde en Informatica (CWI) Sophia Drossopoulou, Imperial College London James Noble, Victoria University of Wellington Tobias Wrigstad, Stockholm University Fully Abstract Semantics of Additive Aspects by Translation Sam Sanjabi, Oxford University Computing Laboratory Luke Ong, Oxford University Computing Laboratory Session 5: Programming languages Thursday, 14:00-16:00 Session Chair: Awais Rashid Conservative Aspect-Orientated Programming with the e-language Matan Vax, Cadence Design SCOPE: an AspectJ Compiler for Supporting User-Defined Analysis-Based Pointcuts Tomoyuki Aotani, University of Tokyo, Japan Hidehiko Masuhara, University of Tokyo Declarative Failure Recovery for Sensor Networks Ramakrishna Gummadi, Univerity of Southern California Nupur Kothari, Univerity of Southern California Todd Millstein, University of California at Los Angeles Ramesh Govindan, Univerity of Southern California cJ: Enhancing Java with Safe Type Conditions Shan Shan Huang, Georgia Institute of Technology David Zook, Georgia Institute of Technology Yannis Smaragdakis, University of Oregon Panel: Beyond AspectJ: AOP languages in 2017 Thursday, 16:30-18:00 What will the next generation of aspect-oriented programming languages look like? How will they be different from AspectJ? Must they support obliviousness? How will aspect interfaces be specified? In what form will open classes be present? Or will aspects turn out to be an instance of a more general and elegant modularisation mechanism? panelists: Theo d'Hondt, Vrije Universiteit Brussels, Belgium Hidehiko Masuhara, University of Tokyo, Japan Klaus Ostermann, Technical University Darmstadt, Germany Yannis Smaragdakis, University of Oregon, USA Session 6: Aspect mining Friday, 11:00-12:30 Session Chair: Yvonne Coady Simple Cross-Cutting Concerns are not so Simple Magiel Bruntink, Centrum voor Wiskunde en Informatica Arie van Deursen, Delft University of Technology Maja D'Hondt, Centrum voor Wiskunde en Informatica Tom Tourwé, Eindhoven University of Technology Using Natural Language Program Analysis to Locate and Understand Action-Oriented Concerns David Shepherd, University of Delaware Zachary Fry, University of Delaware Emily Hill, University of Delaware K. Vijay-Shanker, University of Delaware Lori Pollock, University of Delaware Efficiently Mining Crosscutting Concerns Through Random Walks Charles Zhang, University of Toronto Hans-Arno Jacobsen, University of Toronto

1 0