1 / 15

Apposition

Apposition. Programming Language Symbiosis is an Absolute Prerequisite for True Multiparadigm Programming. Definitions. Multiparadigm Programming (MPP) Language

nuwa
Download Presentation

Apposition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Apposition Programming Language Symbiosis is an Absolute Prerequisite for True Multiparadigm Programming Tom Tourwé

  2. Definitions • Multiparadigm Programming (MPP) Language “A programming language/environment that allows a developer to use the best suited programming paradigm for a specific task or problem” • Programming Language Symbiosis “Transparant use of features from one particular programming language in another language” Tom Tourwé

  3. The Need for MPP • Software engineering requirements • Use most suited paradigm/programming language for a given problem • Component-oriented programming • Should allow components written in different programming languages to collaborate • Misc: CORBA, Webservices, etc.. • Programming language independent • Communication overhead • Not transparant Tom Tourwé

  4. Example: Graphics Framework • Different kinds of figures that share common state/behaviour • Figure, Rectangle, Ellipse, etc. • Constraints between/invariants of different figures in a drawing • Alignment, dependencies, etc.. • Operations on figures • group, reshape, move, etc. OO Paradigm Logic Paradigm Functional Paradigm Tom Tourwé

  5. Requirements • Transparency between paradigms • Shared program elements: primitive types, lists, objects, etc .. • Use of functions, procedures, methods, predicates, etc .. • Extensibility • Straightforward incorporation of new paradigms • Integration of paradigms • Whole should be more than the sum of its parts • No restrictions on use of particular paradigm Tom Tourwé

  6. “Industrial” MPP Languages • C++ • Integrates imperative & object-oriented paradigm • Not extensible • Integrates a limited number of paradigms only • Weak integration • Only paradigms that can easily be combined • .Net • No integration, only “interoperation” • Extensible (CLR) • In theory: many different languages/paradigms • In practice: class-based OO languages • Restrictions on use of paradigms • Based on “common” subset of features • No multiple inheritance, covariant overriding, etc. Tom Tourwé

  7. “Research” MPP Prototypes • R++ • Extension of C++ with logic rules • Constraints, invariants, etc … • Functional Logic Programming • Extensions of logic languages with functional features • List manipulation, higher-order functions, etc … • Prolog++ • Extension of logic programming with object-oriented features Tom Tourwé

  8. Objective • Provide a unified framework for building & experimenting with MP programming languages • Use 1 powerful “macro kernel” language that • offers a limited number of basic butpowerful features • serves as an underlying basis for the MPP language • is easily extensible with new paradigms • allows integration of different paradigms • (Transformational approach to MPP) Tom Tourwé

  9. Example: Scheme • Simple but powerful, (mostly) functional language • Closures • Macros & Quasiquoting • syntax extensions • Expansion/code generation • First-class continuations • Explicitly manage control flow • Existing Scheme extensions • Logic programming (Schelog) • Class/Object-based OO • .. Tom Tourwé

  10. (define-macro class (lambda (super . definitions) `(letrec (..)))) (define-macro var (lambda (name . value) `(define ,name ,@value))) (define-macro method (lambda (selector arguments . body) `(set! ..))) (define Figure (letrec ((<<SUPER>> Root) (<<METHODS>> ‘())) (define area ‘()) .. (set! <<METHODS>> (cons (cons ‘displayOn: (lambda (aGC) (send self subclassResponsibility)) <<METHODS>>)) (define (self msg . args) (apply (cdr (assoc msg <<METHODS>>)) args)) self)) (define Figure (class Root (var area) .. (method displayOn (aGC) (send self subclassResponsibility)) ..)) Tom Tourwé

  11. Example • Integration of OO and functional paradigms (define Drawing (class Figure .. (function group (aSelectionOfFigures) (send Drawing new: (cons (send CompositeFigure new: (map (lambda (aFigure) (send aFigure copy)) aSelectionOfFigures)) (filter (lambda (aFigure) (not (member? aFigure aSelectionOfFigures))) (send self getFigures))))) ..)) Tom Tourwé

  12. Example • Integration of OO and logic paradigms (define Rectangle (class Figure (monitored-var width) (monitored-var height) (rule updateArea (width height) (when (and (> (send self getHeight) 0) (> (send self getWidth) 0)) (send self setArea: ((* (send self getHeight) (send self getWidth)))))) ..)) Tom Tourwé

  13. Research questions • Feasability • Can a paradigm be integrated with others? How? • “Paradigm Leaks” • E.g. backtracking with side effects • Scalability • Integration of a new paradigm with all already existing paradigms • Performance & memory overhead • Trade-off Tom Tourwé

  14. Questions Tom Tourwé

  15. Example • Integration of OO and logic paradigms (define Figure (class Root (monitored-var deleted? #f) (method delete () (set! deleted? #t)) (rule deletionUpdate (deleted?) (when (and (member aDependent (send self myDependents)) (send aDependent deleted?)) (begin (send aDependent removeDependent: (self)) (send self removeDependent: (aDependent))))) ..)) Tom Tourwé

More Related