munich-lisp September 2005

munich-lisp@common-lisp.net

8 participants
8 discussions

[munich-lisp] Links: Modular Verification etc.
by Axel Rauschmayer 13 Sep '05

13 Sep '05

- "Modular verification of collaboration-based software designs", Kathi Fisler, Shriram Krishnamurthi http://portal.acm.org/citation.cfm?id=503231 - MultiJava: Multiple dispatch for Java from Gary Leavens et al. If you want to look at multiple dispatch from a slightly different angle. - A partial (I'm only a co-author) plug for my own work: it describes nicely the various implications of layer-based programming. "Scaling Step-Wise Refinement", Don Batory, Jack Sarvela, Axel Rauschmayer http://www.pst.ifi.lmu.de/~rauschma/publications.html#ahead2 Greetings, Axel -- Axel Rauschmayer http://rauschma.de axel(a)rauschma.de

1 0

[munich-lisp] Another new member
by Axel Rauschmayer 13 Sep '05

13 Sep '05

Hi! Last time was also my first Munich Lisp meeting. My name is Axel Rauschmayer, I'm a research assistant at the dept. of computer science at the University of Munich. I'm currently writing a scripting language that is loosely centered around the following ideas: - Direct RDF support (obviating the need for complex object to {RDBS, XML, RDF} mappings). - RDF-based improved structuring of programs ("next-generation literate programming" if you will). - Solutions for some of the separation of concerns difficulties arising in GUI programming. - Multiple dispatch. The last item, as you might have guessed, is the reason for my interest in Lisp. Greetings, Axel -- Axel Rauschmayer http://rauschma.de axel(a)rauschma.de

1 0

[munich-lisp] multimethods, generic functions, multiple dispatch, ...
by Christian Schuhegger 11 Sep '05

11 Sep '05

hi, yesterday in the beer garden there was a discussion going on where i tried to explain the advantage of generic functions over the way that java or c++ implement their runtime type polymorphism on only one argument, the implicite 'this' argument. the example choosen to show the problems with only single method dispatching was the collission of two 2 dimensional shapes, e.g. triangle, circle, square, rectangle, ellipse, ... in java the 'best' way to achieve double dispatch is probably some variation of the visitor pattern, something along the lines: class Triangle implements Shape { public boolean collidesWith(Shape other) { other.collidesWithTriangle(this); } ...; public boolean collidesWithCircle(Circle s) {...;} public boolean collidesWithSquare(Square s) {...;} ...; } you avoid the if-then-elses, but if you add a shape later you will have to touch all sublasses of Shape and add the collidesWithNewShape method. because collission detection is symmetric, e.g. it does not matter if you say collidesWith(Triangle t, Circle c) or collidesWith(Circle c, Triangle t) it is not obvious if the actual code that does the collision detection between these two shapes should be in the Triangle or in the Circle class. probably it is best factored out in a third CollisionDetectionAlgorithm class which only contains static methods for each combination of shapes. as you can see you have to be already quite imaginative to implement double type dispatch and it will become even more complex with more than two types on which you would like to dispatch. you avoid the problem completely by using multimethods, e.g. CLOS in lisp or language extensions like NICE for java: http://nice.sourceforge.net/ i've also seen some time ago an extension to gcc that allows you to use multimethods in C++, but i cannot find it at the moment. there are two related documents that i found by quickly browsing through some google results: http://www.cs.technion.ac.il/~imaman/stuff/mm.ppt https://www.informit.com/content/images/0201704315/samplechapter/alexan11.p… -- Christian Schuhegger http://www.el-chef.de/

2 5

[munich-lisp] new member
by Emilio Lopes 11 Sep '05

11 Sep '05

Hello, Munich Lispers! I attended the last meeting on friday for the first time. I already had the chance to talk to some of you at the biergarten, but I would like to introduce myself to the list nonetheless. I'm the guy who speaks German with a funny and English with a terrible accent ;-). But seriously: I'm an ex-physicist who at some point realised that physics was not really his business and that programming is the real fun. I've been since then catching up and learning a lot of interesting CS things. Since 2003 I'm working for an automobile maker in Munich. The job is a mix of programming and system administration, but it's unfortunately a Lisp-free zone. My interest in Lisp began with Emacs, which I use since 1993. Probably due to some posting from Erik Naggum on one of the Emacs newsgroups, I got interested in Common Lisp and started playing with CMUCL and later SBCL. Most of my free time currently goes into following and contributing to the GNU Emacs development. Also, I've been programming in Scheme since about one year. Because I was always fascinated by CLOS and specially the MOP, I've adapted Gregor Kiczales' Tiny-CLOS to my preferred Scheme implementation, Scheme 48. I found it amazing that one can build CLOS with a MOP just by using lambdas and lexical scope! Oh, and I also enjoy riding my road bike a lot :-). Well, I guess it's enough for now. I'm sure we'll have chance to talk more at future meetings. I'm really looking forward to the next one! Emilio P.S.: My personal home page (not much there though): http://home.tiscali.de/emilio.lopes/ My home page at the Emacs Wiki (some personal blurb): http://www.emacswiki.org/cgi-bin/wiki/EmilioLopes My bookmarks at del.icio.us: http://del.icio.us/eclig

2 1

[munich-lisp] context handling via CLOS and (eql form)
by Christian Schuhegger 10 Sep '05

10 Sep '05

hi, here is a quick dummy example of what i intended to explain yesterday about handling context by explicitely threading a context parameter through your application: -- start -- (defun test () (let ((context '((condition-1 . yes)(condition-2 . no)(condition-3 . perhaps)))) (function-example-1 context 1 2))) (defun function-example-1 (context other-arg-1 other-arg-2) (let ((condition-1 (cdr (assoc 'condition-1 context))) (condition-2 (cdr (assoc 'condition-2 context)))) (function-example-1-with-context condition-1 condition-2 other-arg-1 other-arg-2))) (defmethod function-example-1-with-context (condition-1 condition-2 other-arg-1 other-arg-2) (declare (ignorable condition-1 conditon-2 other-arg-1 other-arg-2)) (error "not implemented context")) (defmethod function-example-1-with-context ((condition-1 (eql 'yes)) (condition-2 (eql 'no)) other-arg-1 other-arg-2) (declare (ignorable condition-1 conditon-2)) (format t "c1: yes c2: no arg1: ~A arg2: ~A~%" other-arg-1 other-arg-2)) (defmethod function-example-1-with-context ((condition-1 (eql 'yes)) (condition-2 (eql 'yes)) other-arg-1 other-arg-2) (declare (ignorable condition-1 conditon-2)) (format t "c1: yes c2: yes arg1: ~A arg2: ~A~%" other-arg-1 other-arg-2)) -- end -- [21]> (test) c1: yes c2: no arg1: 1 arg2: 2 as mentioned yesterday in the presentation often when you look at code that handles context you see a big if-then-else tree. this is very confusing and cannot be easily extended. in the above example you see no single if-then-else and it is additive in the sense that when you would like to add another combination of your predicates (conditions) you just add another defmethod. besides that, normally a program with context uses conditions/predicates to determine its actions. therefore i do not really see why the introduction of the concept 'layer' could help? i may be wrong, but in my current understanding a layer is just a name for a certain predicate combination, e.g. layer-1 := condition-1 == yes && condition-2 == no as you also see above with condition-3 (which is actually not used :) ) a predicate does not have to be binary, e.g. it is not restricted to the only values true and false. you can have even enumerated predicates like for example certain categories of screen size 'small := width 40 characters 'medium := width 80 characters 'big := width 120 characters 'large := more than 140 characters .... i decided to use an explicite parameter to the method called context and not a 'special' variable with dynamic scope. this has the disadvantage that you have to write the parameter in a lot of places (this is a one time disadvantage when you write the code), but it has the advantage that every function/method can be easily tested, because you explicitely hand in the context. i originally used the above technique in an embedded language (lisp plc programming environment : LPPE) where i had to output different 'machine code' instructions depending on the target hardware (not really but you can imagine it as: i386, ARM, alpha, ...) and depending on the element in the abstract syntax tree. therefore the methods take two (eql form) parameters, one is the target hardware type and one is the type of the AST-node. -- Christian Schuhegger http://www.el-chef.de/

1 0

[munich-lisp] Munich Lisp Meeting
by tfb＠ocf.berkeley.edu 08 Sep '05

08 Sep '05

------- Start of forwarded message ------- From: Peter Herth <p.herth(a)t-online.de> Newsgroups: comp.lang.lisp Subject: Munich Lisp Meeting Date: Thu, 08 Sep 2005 08:45:05 +0200 Organization: T-Online Message-ID: <dfomli$8qu$01$1(a)news.t-online.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, tomorrow, the 9.9, there will be a meeting of the Munich Lisp Group. As a special guest, Pascal Costanza will join us and talk about: "Language Constructs for Context-oriented Programming". The meeting will take place at 18.00 at the LMU, Oettingenstr. 67 Room Takla-Makan Z11 Main Entrance, downstairs, through the room opposite to the toilets. Downstairs: ____________________________________ | | | | | Z9 | Z10 | Z11 | | | | | |____/ __|____/ ___|______/ _________|___ | |________/ __________________________ | | | | | Z8 | ------ -------| | Z7 | | | |_____/ ________| | | -----------| |----------------- ___________ _ _________ |/ /| Stairs | |WC | |||| | ------------------------- Entrance Level: -------------------------------- _______/ _____ _______ | | | Stairs | | | | |||| | -------/ -------------------- | | ^ Main Entrance Peter -- pet project: http://dawn.netcologne.de homepage: http://www.peter-herth.de lisp stuff: http://www.peter-herth.de/lisp.html get Ltk here: http://www.peter-herth.de/ltk/ ------- End of forwarded message -------

1 0

RE: [munich-lisp] Meeting
by Christian Schaller 06 Sep '05

06 Sep '05

Will there be an update on http://wiki.alu.org/Munich, especially regarding the agenda? I'm going to invite a friend... :) Looking forward to meet you all again! - Chris > -----Original Message----- > From: munich-lisp-bounces(a)common-lisp.net > [mailto:munich-lisp-bounces@common-lisp.net] On Behalf Of Peter Herth > Sent: Friday, September 02, 2005 2:11 PM > To: munich-lisp(a)common-lisp.net > Subject: Re: [munich-lisp] Meeting > > I just confirmed the 9.9.05 with Pascal, he will be coming and hold a > presentation. > > Peter > _______________________________________________ > http://lisp.tech.coop/Munich > munich-lisp mailing list > munich-lisp(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/munich-lisp >

2 1

[munich-lisp] Meeting
by Peter Herth 02 Sep '05

02 Sep '05

Hi, I have talked to Pascal Costanza, and he offered to come to Munich and give a presentation of his works. So this would be the ideal reason to schedule a Lisp users meeting :). The planned date would be friday the 9th. Could we meet at the university, Wolfgang? Peter

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

munich-lisp September 2005