6/10/2015Martin Odersky, LAMP, EPFL1 Programming Language Abstractions for Semi-Structured Data Martin Odersky Sebastian Maneth Burak Emir EPFL.

Slides:



Advertisements
Similar presentations
Service Description: WSDL COMP6017 Topics on Web Services Dr Nicholas Gibbins –
Advertisements

Object-Oriented Programming Python. OO Paradigm - Review Three Characteristics of OO Languages –Inheritance It isn’t necessary to build every class from.
 Flattening and Direct semantics  By example: Inheritance  Featherweight Jigsaw (FJig)  (nice and clean) surface syntax  Generalized inheritance.
Independently Extensible Solutions to the Expression Problem Martin Odersky, EPFL Matthias Zenger, Google.
2 Object-Oriented Analysis and Design with the Unified Process Objectives  Explain how statecharts can be used to describe system behaviors  Use statecharts.
Principles of Object-Oriented Software Development The language Java.
Satzinger, Jackson, and Burd Object-Orieneted Analysis & Design
Design Patterns Module Name - Object Oriented Modeling By Archana Munnangi S R Kumar Utkarsh Batwal ( ) ( ) ( )
CS 106 Introduction to Computer Science I 04 / 30 / 2010 Instructor: Michael Eckmann.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)
Subclasses and Subtypes CMPS Subclasses and Subtypes A class is a subclass if it has been built using inheritance. ▫ It says nothing about the meaning.
The Trouble with Types Martin Odersky EPFL and Typesafe.
Design Patterns.
CS2110: SW Development Methods Design of methods (functions) Class design – CRC cards – UML class and sequence diagrams Software Design.
OOPs Object oriented programming. Based on ADT principles  Representation of type and operations in a single unit  Available for other units to create.
Slide 1 Wolfram Höpken RMSIG Reference Model Special Interest Group Second RMSIG Workshop Methodology and Process Wolfram Höpken.
CSE 332: C++ templates This Week C++ Templates –Another form of polymorphism (interface based) –Let you plug different types into reusable code Assigned.
Speaking Bluntly about SharpHDL: Some Old Stuff and Some Other Proposed Future Extensions Gordon J. Pace & Christine Vella Synchron’05 Malta, November.
Ceg860 (Prasad)L6MR1 Modularity Extendibility Reusability.
05 - Patterns Intro.CSC4071 Design Patterns Designing good and reusable OO software is hard. –Mix of specific + general –Impossible to get it right the.
CSE 425: Data Types II Survey of Common Types I Records –E.g., structs in C++ –If elements are named, a record is projected into its fields (e.g., via.
Polymorphism, Inheritance Pt. 1 COMP 401, Fall 2014 Lecture 7 9/9/2014.
9/28/01F-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Design Patterns.
Unified Modeling Language, Version 2.0
Chapter 6: Structured Vs. Object Oriented Analysis and Design.
Reviewing Recent ICSE Proceedings For:.  Defining and Continuous Checking of Structural Program Dependencies  Automatic Inference of Structural Changes.
Scala Overview Brandon Clopton CSCI 431. Scala fuses object-oriented and functional programming in a statically typed programming language. It is aimed.
CSE 425: Object-Oriented Programming I Object-Oriented Programming A design method as well as a programming paradigm –For example, CRC cards, noun-verb.
Generative Programming. Automated Assembly Lines.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns IX Interpreter, Mediator, Template Method recap.
Centralized vs. Decentralized Interpreter Pattern Visitor Pattern.
An OO schema language for XML SOX W3C Note 30 July 1999.
1 Class Diagrams: Advanced Concepts. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are the most commonly used diagrams.
Design Patterns Gang Qian Department of Computer Science University of Central Oklahoma.
Objects & Dynamic Dispatch CSE 413 Autumn Plan We’ve learned a great deal about functional and object-oriented programming Now,  Look at semantics.
ECE450S – Software Engineering II
Sheet 1 DocEng’03, Grenoble, November 2003 Model Driven Architecture based XML Processing Ivan Kurtev, Klaas van den Berg University of Twente, the Netherlands.
Unified Modeling Language. Object Oriented Methods ► What are object-oriented (OO) methods?  OO methods provide a set of techniques for analyzing, decomposing,
Abstract Syntax Trees Compiler Baojian Hua
CSE341: Programming Languages Lecture 22 OOP vs. Functional Decomposition; Adding Operators & Variants; Double-Dispatch Dan Grossman Spring 2013.
Behavioral Patterns CSE301 University of Sunderland Harry R Erwin, PhD.
CS162 Week 1 Kyle Dewey. Overview Basic Introduction CS Accounts Scala survival guide.
The Visitor Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
3/1/01H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)
Design Patterns CSCE 315 – Programming Studio Spring 2013.
Slide 1 Unified Modeling Language, Version 2.0 Object-Oriented SAD.
Design Patterns: MORE Examples
Abstract Factory Pattern
CSE341: Programming Languages Lecture 22 OOP vs
Linzhang Wang Dept. of Computer Sci&Tech, Nanjing University
Inheritance and Polymorphism
Behavioral Design Patterns
Object-Orientated Programming
CSE341: Programming Languages Lecture 22 OOP vs
Abstract Factory Pattern
Designing Software for Ease of Extension and Contraction
Intent (Thanks to Jim Fawcett for the slides)
Presentation by Julie Betlach 7/02/2009
Implementing Language Extensions with Model Transformations
CSE341: Programming Languages Lecture 22 OOP vs
Objects and Aspects: What we’ve seen so far
Software Design Lecture : 14.
Interpreter Pattern.
CSE341: Programming Languages Lecture 22 OOP vs
Implementing Language Extensions with Model Transformations
CSE341: Programming Languages Lecture 22 OOP vs
CSE341: Programming Languages Lecture 22 OOP vs
Presentation transcript:

6/10/2015Martin Odersky, LAMP, EPFL1 Programming Language Abstractions for Semi-Structured Data Martin Odersky Sebastian Maneth Burak Emir EPFL

6/10/2015Martin Odersky, LAMP, EPFL2 Scala and XML The project studies language constructs and implementation techniques for processing XML data in a general purpose programming language. It s based on the recently released Scala programming language (scala.epfl.ch) Scala unifies functional and object-oriented programming. Both idioms have a lot to offer. New applications will require a combination of the two.

6/10/2015Martin Odersky, LAMP, EPFL3 Example 1: Distributed programming and web services: Immutable data are essential for achieving robustness and efficiency of applications in the face of replication and partial failure. Example 2: XML processing: Conciseness and safety helped by pattern matching over trees regular expression patterns and types tree transformer combinators (Design principle: fusion instead of agglutination).

6/10/2015Martin Odersky, LAMP, EPFL4 Design Aim You should not have the impression that you are programming either functionally or object-oriented. Three examples how this is achieved: Modules are objects. Pattern matching over class hierarchies. XML Processing

6/10/2015Martin Odersky, LAMP, EPFL5 1. Modules are Objects Traditional modules and objects have complementary strengths: Modules are good at abstraction: e.g. abstract types in signatures. Objects are good at composition: e.g. inheritance, recursion, dynamic composability because objects are first-class. Idea: Identify Object = Module Interface = Signature Class =Functor Consequence: Objects and interfaces need to contain type members. Furthermore, type members can be either abstract or concrete. (Papers on this at FOOL10, ECOOP2003)

6/10/2015Martin Odersky, LAMP, EPFL6 2. Pattern Matching over Class Hierarchies How are data decomposed? OO-approach: Through virtual member access. Functional approach: Through pattern matching over algebraic data types. Complementary wrt extensibilty: OO: Easy to add new kinds of data with fixed method interface. Functional: Easy to add new kinds of processors over fixed data type. How can we get extensibility in both directions?

6/10/2015Martin Odersky, LAMP, EPFL7 Case Classes and Pattern Matching Idea: Allow Pattern Matching over constructors of classes in a class hierarchy. trait Base { trait Exp; case class Num(x: int) extends Exp; def eval(e: Exp): int = e match { case Num(x) => x } } trait BasePlus extends Base { case class Plus(l: Exp, r: Exp) extends Exp; def eval(e: Exp): int = e match { case Plus(l, r) => eval(l) + eval(r) case _ => super.eval(e) }} Full code-reuse possible; easy to set up. Static type-safety can be achieved by refining this pattern (see FOOL 11)

6/10/2015Martin Odersky, LAMP, EPFL8 3. Representing XML Documents On an abstract level, an XML documents is simply a tree. We use and extend standard software to convert between external documents and trees. Trees are pure data; no methods are attached to nodes. Trees should reflect the application domain, rather than being a generic “one size fits all” such as DOM. This means we want different kind of data types for different kinds of tree nodes. BookList Header Book* Publisher Date Title Author* Abstract Keyword*

6/10/2015Martin Odersky, LAMP, EPFL9 Parsing XML Trees in Java How can trees be decomposed? In an object-oriented language: Type test and type casts – ugly and inefficient. if (node instanceof Header) { Header header = (Header)node; Publisher pub = (Publisher)header; } else if (node instanceof Book)... Visitors – heavyweight, hard to extend. node.visit(new Visitor() { void visitHeader() {... } void visit Book() {... } } In a functional language: Recursive pattern match over trees. Problem again: extensibility.

6/10/2015Martin Odersky, LAMP, EPFL10 Parsing XML Trees in Scala In Scala, we can represent XML data as instances of case classes and use pattern matching to access their elements. E.g: entry match { case Header(pub, date) => … case Book(title, info) => … } In general, we need to match in sequences of XML trees. This is done by extending Scala’s pattern matching to regular expressions.