From p.herth at gmail.com Fri Sep 2 12:10:34 2005 From: p.herth at gmail.com (Peter Herth) Date: Fri, 2 Sep 2005 14:10:34 +0200 Subject: [munich-lisp] Meeting In-Reply-To: <20050830070833.GA27059@software-lab.de> References: <5921d57c0508250024e6d6828@mail.gmail.com> <20050829122147.22797.qmail@paladin.fortunaty.net> <20050830070833.GA27059@software-lab.de> Message-ID: <5921d57c050902051030a3fca2@mail.gmail.com> I just confirmed the 9.9.05 with Pascal, he will be coming and hold a presentation. Peter From Christian.Schaller at siemens.com Fri Sep 2 14:21:00 2005 From: Christian.Schaller at siemens.com (Christian Schaller) Date: Fri, 2 Sep 2005 16:21:00 +0200 Subject: [munich-lisp] Meeting Message-ID: 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 at common-lisp.net > [mailto:munich-lisp-bounces at common-lisp.net] On Behalf Of Peter Herth > Sent: Friday, September 02, 2005 2:11 PM > To: munich-lisp at 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 at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/munich-lisp > From p.herth at gmail.com Tue Sep 6 20:14:33 2005 From: p.herth at gmail.com (Peter Herth) Date: Tue, 6 Sep 2005 22:14:33 +0200 Subject: [munich-lisp] Meeting In-Reply-To: References: Message-ID: <5921d57c0509061314ba0d95b@mail.gmail.com> Pascal will hold a talk with the title: "Language Constructs for Context-oriented Programming". Looking at his train schedule, the talk probably won't start before 18.00. Peter From tfb at ocf.berkeley.edu Thu Sep 8 08:56:37 2005 From: tfb at ocf.berkeley.edu (Thomas F. Burdick) Date: 08 Sep 2005 01:56:37 -0700 Subject: [munich-lisp] Munich Lisp Meeting Message-ID: ------- Start of forwarded message ------- From: Peter Herth Newsgroups: comp.lang.lisp Subject: Munich Lisp Meeting Date: Thu, 08 Sep 2005 08:45:05 +0200 Organization: T-Online Message-ID: 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 ------- From Christian.Schuhegger at gmx.de Sat Sep 10 06:40:58 2005 From: Christian.Schuhegger at gmx.de (Christian Schuhegger) Date: Sat, 10 Sep 2005 08:40:58 +0200 Subject: [munich-lisp] context handling via CLOS and (eql form) Message-ID: <43227FFA.6060203@gmx.de> 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/ From Christian.Schuhegger at gmx.de Sat Sep 10 06:58:48 2005 From: Christian.Schuhegger at gmx.de (Christian Schuhegger) Date: Sat, 10 Sep 2005 08:58:48 +0200 Subject: [munich-lisp] multimethods, generic functions, multiple dispatch, ... Message-ID: <43228428.1080506@gmx.de> 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.pdf -- Christian Schuhegger http://www.el-chef.de/ From andy at splashground.de Sat Sep 10 07:50:35 2005 From: andy at splashground.de (Andreas Hauser) Date: 10 Sep 2005 07:50:35 -0000 Subject: [munich-lisp] multimethods, generic functions, multiple dispatch, ... In-Reply-To: <43228428.1080506@gmx.de> References: <43228428.1080506@gmx.de> Message-ID: <20050910075035.25512.qmail@paladin.fortunaty.net> Christian.Schuhegger wrote @ Sat, 10 Sep 2005 08:58:48 +0200: You seem to have forgotten to show the actual Lisp code. > class Triangle implements Shape { > public boolean collidesWith(Shape other) { > other.collidesWithTriangle(this); > } > ...; > public boolean collidesWithCircle(Circle s) {...;} > public boolean collidesWithSquare(Square s) {...;} > ...; > } While having methods with the same name but different signatures is certainly something i like, maybe in this case you just have problems with the objects you designed. I guess, we all know Java is limited, but let's not forget, they call it a feature. class Triangle implements Shape { public 2Dspace space() { 2DSpace my_space = xy[screen.x_dim][screen.y_dim]; // fill the matrix with pixels the Triangle occuppies return my_space; } public boolean collidesWith(Shape other) { return overlap(other.space, this.space); } } So first, generalize the properties of your objects and then let them interact. I would also say that colliding and especially overlap() is something that the Object World should do. Andy From Christian.Schuhegger at gmx.de Sat Sep 10 08:07:09 2005 From: Christian.Schuhegger at gmx.de (Christian Schuhegger) Date: Sat, 10 Sep 2005 10:07:09 +0200 Subject: [munich-lisp] multimethods, generic functions, multiple dispatch, ... In-Reply-To: <20050910075035.25512.qmail@paladin.fortunaty.net> References: <43228428.1080506@gmx.de> <20050910075035.25512.qmail@paladin.fortunaty.net> Message-ID: <4322942D.4080707@gmx.de> Andreas Hauser wrote: > Christian.Schuhegger wrote @ Sat, 10 Sep 2005 08:58:48 +0200: > > You seem to have forgotten to show the actual Lisp code. sorry :) (defmethod do-shapes-collide-p ((shape1 Triangle) (shape2 Circle)) (...)) (defmethod do-shapes-collide-p ((shape1 Circle) (shape2 Triangle)) (do-shapes-collide-p shape2 shape1)) (defmethod do-shapes-collide-p ((shape1 Triange) (shape2 Square)) (...)) ... > > >>class Triangle implements Shape { >> public boolean collidesWith(Shape other) { >> other.collidesWithTriangle(this); >> } >> ...; >> public boolean collidesWithCircle(Circle s) {...;} >> public boolean collidesWithSquare(Square s) {...;} >> ...; >>} > > > While having methods with the same name but different signatures is > certainly something i like, maybe in this case you just have problems > with the objects you designed. I guess, we all know Java is limited, > but let's not forget, they call it a feature. > > > class Triangle implements Shape > { > public 2Dspace space() > { > 2DSpace my_space = xy[screen.x_dim][screen.y_dim]; > // fill the matrix with pixels the Triangle occuppies > return my_space; > } > public boolean collidesWith(Shape other) > { > return overlap(other.space, this.space); > } > } > > So first, generalize the properties of your objects and then let them > interact. I would also say that colliding and especially overlap() > is something that the Object World should do. and what do you do if you talk about vector objects and not pixel objects :) -- Christian Schuhegger http://www.el-chef.de/ From andy at splashground.de Sat Sep 10 08:32:56 2005 From: andy at splashground.de (Andreas Hauser) Date: 10 Sep 2005 08:32:56 -0000 Subject: [munich-lisp] multimethods, generic functions, multiple dispatch, ... In-Reply-To: <4322942D.4080707@gmx.de> References: <20050910075035.25512.qmail@paladin.fortunaty.net> <4322942D.4080707@gmx.de> Message-ID: <20050910083256.25596.qmail@paladin.fortunaty.net> Christian.Schuhegger wrote @ Sat, 10 Sep 2005 10:07:09 +0200: > Andreas Hauser wrote: > > Christian.Schuhegger wrote @ Sat, 10 Sep 2005 08:58:48 +0200: > > > > You seem to have forgotten to show the actual Lisp code. > > sorry :) > > (defmethod do-shapes-collide-p ((shape1 Triangle) (shape2 Circle)) > (...)) > (defmethod do-shapes-collide-p ((shape1 Circle) (shape2 Triangle)) > (do-shapes-collide-p shape2 shape1)) > (defmethod do-shapes-collide-p ((shape1 Triange) (shape2 Square)) > (...)) > ... And why don't you need: (defmethod do-shapes-collide-p ((shape1 Circle) (shape2 Triangle)) ? > and what do you do if you talk about vector objects and not pixel objects :) It must be serialized somewhere (in Object World ?). Do the collision there. But it seems Java can do methods with different sigantures: public class foo { public foo() { } public void bar(int i) { System.out.println(i + 1); } public void bar(String s) { System.out.println(s + " world"); } public static void main(String args[]) { foo f = new foo(); f.bar(12); f.bar("Hello"); } } Andy From eclig at gmx.net Sun Sep 11 10:52:15 2005 From: eclig at gmx.net (Emilio Lopes) Date: Sun, 11 Sep 2005 12:52:15 +0200 Subject: [munich-lisp] new member Message-ID: 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 From abu at software-lab.de Sun Sep 11 13:55:34 2005 From: abu at software-lab.de (Alexander Burger) Date: Sun, 11 Sep 2005 15:55:34 +0200 Subject: [munich-lisp] new member In-Reply-To: References: Message-ID: <20050911135534.GA17830@software-lab.de> Hi Emilio, welcome on board! Cheers, - Alex Alexander Burger Software Lab. / 7fach GmbH Bahnhofstr. 24a, D-86462 Langweid abu at software-lab.de, http://www.software-lab.de, +49 821 9907090 From Christian.Schuhegger at gmx.de Sun Sep 11 14:48:49 2005 From: Christian.Schuhegger at gmx.de (Christian Schuhegger) Date: Sun, 11 Sep 2005 16:48:49 +0200 Subject: [munich-lisp] multimethods, generic functions, multiple dispatch, ... In-Reply-To: <20050910083256.25596.qmail@paladin.fortunaty.net> References: <20050910075035.25512.qmail@paladin.fortunaty.net> <4322942D.4080707@gmx.de> <20050910083256.25596.qmail@paladin.fortunaty.net> Message-ID: <432443D1.20402@gmx.de> Andreas Hauser wrote: >>(defmethod do-shapes-collide-p ((shape1 Triangle) (shape2 Circle)) >> (...)) >>(defmethod do-shapes-collide-p ((shape1 Circle) (shape2 Triangle)) >> (do-shapes-collide-p shape2 shape1)) >>(defmethod do-shapes-collide-p ((shape1 Triange) (shape2 Square)) >> (...)) >>... > > > And why don't you need: > (defmethod do-shapes-collide-p ((shape1 Circle) (shape2 Triangle)) > ? this is because collission of two objects is symmetric: a collides with b <=> b collides with a and i do not have to implement the same code again. > It must be serialized somewhere (in Object World ?). Do the collision there. this is why i suggested: > probably it is best factored out in a third CollisionDetectionAlgorithm class which only contains static methods for each combination of shapes. and you are right: > But it seems Java can do methods with different sigantures: > > public class foo > { > public foo() > { > } > > public void bar(int i) > { > System.out.println(i + 1); > } > > public void bar(String s) > { > System.out.println(s + " world"); > } > > public static void main(String args[]) > { > foo f = new foo(); > f.bar(12); > f.bar("Hello"); > } > } but this overloading of methods is something "compile time" and not "run time", e.g. if you would have some code similar like this: -- snip start -- public class CollisionDetectionAlgorithm { public static boolean collides(Shape s1, Shape s2) {...;}// throw a runtime exception public static boolean collides(Triangle s1, Circle s2) {...;} public static boolean collides(Triangle s1, Square s2) {...;} public static void main(String[] args) { Shape s1 = new Triangle(); Shape s2 = new Circle(); System.out.println(collides(s1,s2)); } } -- snip end -- you would end up with the first collides method being called which would throw a runtime exception. the only runtime type polymorphism that java knows is subtype type polymorphism which only reacts on the type of the implicite 'this' type. the calls to the overloaded methods are fixed at compile time. -- Christian Schuhegger http://www.el-chef.de/ From andy at splashground.de Sun Sep 11 16:49:23 2005 From: andy at splashground.de (Andreas Hauser) Date: 11 Sep 2005 16:49:23 -0000 Subject: [munich-lisp] multimethods, generic functions, multiple dispatch, ... In-Reply-To: <432443D1.20402@gmx.de> References: <20050910083256.25596.qmail@paladin.fortunaty.net> <432443D1.20402@gmx.de> Message-ID: <20050911164923.30333.qmail@paladin.fortunaty.net> Christian.Schuhegger wrote @ Sun, 11 Sep 2005 16:48:49 +0200: > Andreas Hauser wrote: > > And why don't you need: > > (defmethod do-shapes-collide-p ((shape1 Circle) (shape2 Triangle)) > > ? > > this is because collission of two objects is symmetric: > a collides with b <=> b collides with a > and i do not have to implement the same code again. I thought you had meant, that you don't need the second method at all. Like having an alias in the symbol table or something. I could imagine in a cool language you would only need one method and have some way to specify that the argument order doesn't matter. In Lisp i would at least have expected something like: (defmethod-all-combinations do-shapes-collide ((shape1 Circle) (shape2 Triangle)) where defmethod-all-combinations would produce all combinatios of the arguments, namely: do-shapes-collide ((shape1 Circle) (shape2 Triangle)) do-shapes-collide ((shape2 Triangle) (shape1 Circle)) And from the way you presented this at the biergarden, i tought, that CL even had some builtin magic for that case. > but this overloading of methods is something "compile time" and not "run > time", e.g. if you would have some code similar like this: > -- snip start -- > public class CollisionDetectionAlgorithm { > public static boolean collides(Shape s1, Shape s2) {...;}// throw a > runtime exception > public static boolean collides(Triangle s1, Circle s2) {...;} > public static boolean collides(Triangle s1, Square s2) {...;} > > public static void main(String[] args) { > Shape s1 = new Triangle(); > Shape s2 = new Circle(); > System.out.println(collides(s1,s2)); > } > } > -- snip end -- > you would end up with the first collides method being called which would > throw a runtime exception. the only runtime type polymorphism that java > knows is subtype type polymorphism which only reacts on the type of the > implicite 'this' type. the calls to the overloaded methods are fixed at > compile time. Even if Java was more dynamic, i don't see, why in this case it should not match the collides(Shape, Shape) signature, when you explicitly declare s1 and s2 to be of Shape. You would need them do be declared with the signatures you want to match. public static void main(String[] args) { Triangle s1 = new Triangle(); Circle s2 = new Circle(); System.out.println(collides(s1,s2)); } I don't get the point. Andy From axel at rauschma.de Tue Sep 13 08:05:27 2005 From: axel at rauschma.de (Axel Rauschmayer) Date: Tue, 13 Sep 2005 10:05:27 +0200 Subject: [munich-lisp] Links: Modular Verification etc. Message-ID: <28FDDCA1-B1D5-4BAD-8CDE-F8A7D534304B@rauschma.de> - "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 at rauschma.de From axel at rauschma.de Tue Sep 13 08:05:11 2005 From: axel at rauschma.de (Axel Rauschmayer) Date: Tue, 13 Sep 2005 10:05:11 +0200 Subject: [munich-lisp] Another new member Message-ID: <68674549-2D20-4004-90D2-603DE8BA3987@rauschma.de> 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 at rauschma.de