pro

pro@common-lisp.net

344 discussions

Re: [pro] Modularity for subclassing in Common Lisp
by Daniel Weinreb 08 Dec '10

08 Dec '10

Anton, Thank you very much for your mail. It prompted me to explain what I'm thinking of in a much more clear (I hope!!) way. Here we go: Anton Vodonosov wrote: > What is the difference > for modularity in case of subclassing, from other cases were we apply modularity? > I can't find the difference. > Here's the greater idea. If you have a module, by using CL packages (without any change to CL), it is possible to have more than one set of exports. So, you can offer different interfaces to different callers. By interfaces in this context I mean the set of symbols that are exported. If you offer interface I1 to callers C1, C2, and C2, and interface I2 to callers C4, C5, and C6, then you can be sure that C1, C2, and C3 will keep working as long as you do not make incompatible changes to interface I1. Similarly with I2. Now, moving specifically to OOP: Traditionally, e.g. in Smalltalk 80, it was a big deal that the caller of an instance of a class does not know the internals of the class. It only uses methods, and does not look internally at the instance variables (slots). (I can't remember whether ST-80 had the concept of private methods that are only intended to be used from methods of the class and not from callers.) OOP was often compared to, or even conflated with, the concept of "abstract datatypes" (ADT's), in the sense meant by Barbara Liskov. In CLU and such languages, similarly there was a sharp distinction between the advertised interface presented to callers of the ADT (abstract datatype, corresponding to a class), and whatever was going on inside it. This was a modularity boundary that allowed a separation of concerns between the users of the ADT and the implementation of the ADT. Recently, this was considered such a big deal that Liskov was awarded a Turing Award. ADT's did not, per se, contain the concept of inheritance. Inheritance was first exposed to the general public with ST-80. However, there wasn't even a semblance of an effort to provide any modular separation between a class and its subclasses. So, whenever the implementation of a class changed in any way at all, you risked breaking subclasses. This was particularly a problem when library 1, under control of group-of-people-1, provided a class, and library-2 subclassed it. If a new release of library-1 came out, there was in general no way for g-o-p-1 to find everybody who had subclassed their classes; if the lib-2 people installed the new release of lib-1, they had no idea whether anything would work. Now, you could just say that there should be internals and externals, and the externals exposed to the callers and the externals exposed to the subclassers are exactly the same set. This does not work for most non-trivial cases. I will assume that you know why, since I can't explain it briefly. So, what I am proposing is to be explicit about what is being exposed to the subclassers, so that if the base class is changed in a new release but the subclasser interface is compatible, the lib-2 people can rest assured that their library will continue to work. (Unless there are bugs, of course.) In C++ and Java, this isn't done with Lisp packages, of course. The "public" members are the interface to the caller, and the union of the "public" and "protected" members are the interface provided to the subclassers. Whether the subclassers should be given permission to override the public things, in all cases, is an interesting but separate discussion. With Lisp packages, you can control this any way you want. > > > We may note that "protected" is actually public, in the sense > that when we specify something as "protected", we specify > that the library has external clients which can rely on this protected > method or field. In that sense, yes, absolutely. > Anyone may inherit from our public class, and > access the "protected" members, therefore these members are > available to public. If we change the protected member, we affect > the library clients. > What I'm doing, however, is to distinguish between two sets of "public", as explained above. The callers, which would be a "big public" (lots of callers) must cope with incompatible changes relatively less often, whereas the "small public" (those who subclass) must cope relatively more often since more is revealed. > This drives me to a conclusion, that a single language feature is sufficient > which allows to separate a protocol for interaction with a module > from the module part we expect to change without affecting clients. > Taking you literally, we do not need a new CL feature. But translating what you're saying into the terms I am using, you're saying that we need only one protocol, whereas I am saying that it's better to have two. There is no "language feature" at the CL level, but there is a practice, or a "design pattern", that I am recommending. Having :documentation in the defpackage to explain what's going on, especially who is intended to use this package, would be very helpful. Design patterns are essentially a way to extend a language (in a nutshell). > I made observation on many java systems, that addition to packages > the public/protected/private for classes has bad influence on the > system modularity. > > Many java programmers tend to hide attributes of every single class > behind get/set accessors, even for simple classes which just hold > values passed between methods and do not contain any logic; to > create hierarchies of interface/abstract class/concrete for various > minor classes, employing protected methods. > There are at least two reasons to put in such methods. First, changing the implementation while keeping compatible behavior for the public methods. Imagine that you have a class called Point representing a point in two-space. You could use Cartesian representation: two data members x and y, and getX and getY (and, if desired, setX and setY). These are the simple getters (and setters) that you mention above. But what if, for some reason (numerical methods, I don't know) you decide that internally using a polar representation, with two data members storing an angle and a distance from the origin, is better. You can make getX continue to work using the appropriate trigonometry operations. Second, these days there are lots of tools that use "dependency injection" and whatnot that only work if you have such methods. Extending "ant", using Spring, and so on work this way, so it has become part of the usual Java design pattern for many classes. (See "Java Bean".) > But at the same time, people do not care to create structure at larger > level, to divide the system into modules. It is not uncommon to see > large systems where all these classes, subclasses in all the > packages are public: everything is available to everything. > Sure. > Separate access control for classes obscures the idea of modularity > (especially in case of such an OO centric language like java, the > programmers are mostly concentrated on classes/object, and often > don't even think about packages;). > I don't know what you mean by this. It depends what you mean by "access control". But if you mean limiting the access that callers of a module have, that is exactly the way modularity is usually realized. > Class is too small entity to form a module. A module API (protocol) > usually consists of set of classes, methods, factory functions, maybe > some global variables. > Ah, yes. That's why Common Lisp has packages and Java has namespaces; to be able to make groups exactly as you are saying. > Another thought is that the interface between base class and > its subclasses is not a second interface, but a part of the first interface. > As you said: > > >> So we could have one package >> for the code that calls into our library, which would have the usual >> protocol, which we can call the "external protocol". Then we could >> have a *second package*, which presents a second protocol that >> subclases would use! >> The second package IS for the second interface! > > What would be the name for the second protocol? I.e. what is the > interaction the base class and the subclass perform via this protocol? > I'm not sure what the name would be. If we were to adopt the practice I'm advocating, it would indeed be a good idea to have a standard naming practice. If you look at some of the major Java libraries, you can see them dealing with that. For example, look at JNDI, the standard Java interface for dealing with any kind of naming service, particularly hierarchical ones such as file system directories and LDAP servers. First, there is what they call the "API". This is used for modules that want to do things like "look up this name and tell me the contents" or "for this name, tell me all the children". Then there is what they call the "SPI", the "Service Provider Interface". In the API, the calling module calls JNDI. For the "SPI", JNDI calls the service provider module. A service provider module is what is often called a "driver". You'd have one for file systems, one for LDAP, and so on. Java comes with some useful ones like those two, and you can add your own if you want to allow people who use the JNDI API to access some previously unsupported naming system. This is very much like what I'm talking about. The API and the SPI are in different Java namespaces (well, as far as I know), and writing a module that calls the API is extremely different from writing a service provider. The SPI might or might not work by overriding classes or adding :before methods or whatever. In fact, the whole thing that I am advocating here is NOT ONLY for OOP and subclassing. I just presented it that way because that's where I see the main "pain point". What REALLY matters is the distinction between the API and the SPI. > As you point, it may be reusing of the implementation (derived streams > reuse write-string implementation from the base class). > > Looks like a thing intended for reusing can rightly be called > an "external protocol" too. > Well, this is something different, I think; a utility class whose behavior has to be documented. But this is a side issue and this email is alarmingly long already. :) > Another view on the interaction in subclassing is that the base class serves > as a template of some functionality, and we can customize its logic by > overriding some methods. In Java, however, the two are separated: there is an Interface that specifies the contract, and then there might or might not be a standard abstract base class that provides some helpful stuff. You are not required to use the utility abstract base class, although in practice I think I've always seen it used. Java allows you to skip having the Interface, which is too bad from the point of view of clean and simple language semantics, and for clarity of code. It's a lot like CLOS's not requiring defgeneric, and probably for the same reason; to let you be lazy or more succinct. But I think it's less clear. I try to always use explicit defgenerics. In our own code here, we particularly stress using defgenerics for functions that are felt to be exposed to other modules. (I say "felt" because our code does not isolate modules as well as it ought to.) > The output stream example may be viewed > in this perspective: we plug-in our write-character implementation into > the functionality implemented by the base class in order to customise it > to work with different character source. > Yes. > The means to parametrize/customize the protocol behavior can also > be considered as a part of the protocol. In simple case it's method parameters, > in more complex case we provide, for example, custom strategies, and can do it > by defining a method for the sublcass. > OK. > Therefore it looks to me that in many cases we deal with a single interface, > not two distinct ones. > Well, I think I've explained my point about that above. > Sometimes a module can interact with the outside world via several protocols, but > it not necessary relates to sublcassing, and it's not necessary that both (all) > the protocols are defined by this module. > Yes, indeed! That goes beyond the scope of what I've said so far. You can indeed have more than one external API, regardless of what you do with SPI's. I believe Ada lets you do all of this. More about Ada and the experience with compatible upgrades, below. > >> Now, there's a great thing about CL packages: you can have more than >> one defpackage for the *same* symbols. \ >> Exactly. You can have more than one API, you can have a separate SPI, you can have multiple SPI's and so on. This is crucial to everything I am proposing. (By "proposing" I do not mean to claim that what I'm saying is novel and original. It may well have been done before. I'm not trying to take credit for anything here.) > > It's a great feature. I think you mean something like when we want to define one > protocol as an extension of another protocol. Although in many cases I suppose > it's possible instead of extending interface to have a separate interfaces. I.e. > if one API is (func1, func2, func3), and another API is (finc1, func2, func3, extra-func), > we could have the second API just as (extra-func). > Exactly. > A good example is needed. Maybe something like database connection API, where implementation > for particular database is provided by a pluggable "driver"; or maybe swank, and swank > backends for different lisps; or something simpler. > Right, exactly, as I discussed above. For your reading pleasure, here's is some stuff about Ada. It's from Tucker Taft, one of the world's foremost experts on Ada (no kidding). Note that Ada 95 is a later version of Ada, with improvements to the original Ada definition. Tucker was very heavily involved with the definition of Ada 95, for years. The point he makes in the first paragraph corresponds to what I've been saying: the fact that "print" calls "to_string" is NOT apparent to the caller, but IS apparent to anyone writing a subclass. ---------------------------------------- Here is the mail from Tucker Taft. I have added a few comments in brackets [like this]. Hi Dan, Ada 95 avoids some of the heartache associated with OOP subclassing. First a little background... I remember going to an OOPSLA conference when we were just starting the work on Ada 95, and the panel was bemoaning the maintenance headaches they were facing. Someone like Microsoft would try to release a new version of some object-oriented library, and the users would scream bloody murder about incompatibilities. Microsoft would claim that all of the classes still had the same interface, and they just fiddled with the implementation. The problem was that in the implementation, there were calls from one operation to another, and by default in C++ (and Java and almost all OOP languages), those inter-operation calls would "redispatch" based on the run-time type of the operand. In C++ you can prevent this by using "class::operation", but that is more work and almost no one bothers. [In other words, Microsoft provided compatibility for the "caller" interface but not the "subclass" interface. The people screaming were the subclassers, not the callers.] So now what happens when you release a new version of the class library? Well for performance (or other reasons), some operations rather than calling other operations, now implement their functionality directly. A perfect example is a "print" operation and a "to_string" operation. It would make sense for the "print" operation to call the "to_string" operation and take the result and send it to the output device. But it might be more efficient to put the result directly to the output device one character at a time, and never bother creating a string. But what happens if someone had already "subclassed" your class and taken advantage of the fact that "print" called "to_string"? They quite likely would inherit the "print" operation as is, and only bother to re-implement "to_string". Now you release your new higher performance version with its great, more efficient "print" routine and bang, the subclassers code no longer works as expected (the inherited print routine no longer redispatches, so it only prints the contents of the parent class). [What I'm proposing is that the fact that print calls to_string is documented. If a new release changes that, and says that print might or might not call to_string, then the subclassers have to address that. They would still be angry because they have to do extra work just because of Microsoft, but they would KNOW what work they need to do. (Assuming Microsoft documented everything properly and made clear the protocol (interface) that the subclassers see.] So how did Ada 95 address this? It was pretty simple. Basically, when one operation of a class calls another, the default is a "static" binding -- there is no redispatch. You can explicitly force a redispatch, but that is more work, and presumably you only do that if you really want that. And if you are a good doobie, you will document that as part of the semantics of your operation. Hence, in our earlier example, if you want "print" to work by redispatching to "to_string", then you work a little harder to force that, and you document that as part of the semantics of the "print" operation. If in a later version of the class library you want to provide a more efficient "print" operation, well clearly that has different semantics, and deserves a new name like "direct_print" or equivalent. [I am 95% sure that what he's saying here, using different jargon than I do, is the same as what I am proposing.] The net effect is that a subclasser can treat operations of a class in Ada 95 as "black boxes," in that you don't care whether one operation calls another to gets its job done, so long as the programmer didn't explicitly decide to "redispatch." If they did redispatch, then presumably they documented that fact, and you can safely take advantage of it. If they didn't redispatch, then for all of the operations, "what you see is what you get," so if you choose to inherit some and override others, you won't get any nasty surprises when a new release of the class library comes out. I hope some of this makes sense! [In exchange for Tucker's having provided us the service of sharing his experience above, I am going to pass on his solicitation for people to comment on his new work. If you don't want to read that, you can safely stop here. But I think it's cool stuff.] By the way, some of these same issues came up in the work I have been doing designing "ParaSail" -- Parallel Specification and Implementation Language. I would love to come by some day and give you guys a short talk on ParaSail. It has some interesting stuff in it. I started a "blog" a year or so ago about the design process, and have started giving some talks in the past few months at conferences and to some local companies. Here is the blog: http://parasail-programming-language.blogspot.com If you are interested in seeing some slides from a talk I gave about it, see this page on our website: http://www.sofcheck.com/news/sate_2010.html The "blog" entry that most directly relates to this issue is: http://parasail-programming-language.blogspot.com/2009/09/parasail-extensio… and here is the relevant paragraph: One important thing to note about how ParaSail implementation inheritance works. It is a completely black box. Each implicitly provided inherited operation calls the corresponding operation of the underlying interface, passing it the underlying objects of any operands of the type being defined. The underlying interface operation operates only on the underlying object(s), having no knowledge that it was called "on behalf" of some extended class. If the underlying operation calls other operations, they too are operating only on the underlying object(s). There is no "redispatch" on these internal calls, so the extended class can treat these underlying operations as black boxes, and not worry that if it explicitly defines some operations while inheriting others, that that might somehow interact badly with how the underlying operations are implemented. Take care, -Tuck

1 0

[pro] Modularity for subclassing in Common Lisp
by Daniel Weinreb 08 Dec '10

08 Dec '10

(This is a new topic.) Many times, people have presented a major problem with object-oriented programming as it is often/idiomatically used. The good thing is that OOP, when done right (in Lisp, that means, among other things, always using defgeneric explicitly), provides a great abstarct interface to the caller. It's good for modularity, because if you want to changes the implementation of the class, you know what you can change easily, and what you cannot because callers depend on it. If all of the callers are under your control, you can easily make incompatible changes, but if you're providing a general-purpose library, that people all over the world are using, then it's a lot harder. I call the set of defgenerics (plus the factory functions) the "protocol". The word "type" is sort of right but carries a lot of connotations and freight that I'd rather avoid. Often all of the CLOS classes that implement a given protocol inherit from a common abstract base class. There are two reasons to do this. First, a common base class can provide implementations of some of the generic functions all by itself. My favorite simple example is an "output stream" protocol, that has a write-character operation and a write-string operation. The common base class provides an implementation of write-string that works by iterating over the characters of the string and calling write-character. Any output stream that can write strings in a more efficient way can override that method. The second reason is to define a Lisp type that all of the subclasses will be of. In my mind, as far as the first reason goes, there should be NO requirement that every type that implements the protocol *must* inherit from a common abstract base class. The abstract base class is merely an implementation convenience. In the case of the fhash library, I do not have any common base class. As a matter of fact, it's not even implemented using CLOS at all. (The caller doesn't know, and should not.) From the source file: ;;; An fhash is represented as a one-dimensional array. It can have two ;;; representations: a linear search table, or a hash table (from the ;;; underlying Common Lisp implementation). An fhash is represented as ;;; a vector, starting with a header. The 0th element says whether this ;;; fhash instance is :linear or :hash. If it's :hash, the 1th element ;;; contains the hash table, and the rest of the elements are ignored. As far as the second reason goes, fortunately Lisp has a powerful way to let you define types. In fhash: (defun fhash-table-p (fhash) "Return true if the argument is an FHASH. Otherwise return NIL. This is not perfect, since some array might just happen to have these values, but it seems unlikely." (and (vectorp fhash) (member (aref fhash +fhash-kind+) '(:linear :hash)))) (deftype fhash-table () '(satisfies fhash-table-p)) This is not perfect. A programmer might just happen to create a vector and put one of those keywords into the +fhash-kind+ slot. (+fhash-kind+ is zero but that's a mere detail.) But it's sort of good enough. OK, back to OOP. Abstraction of the object from the caller is just fine. But, the commonly-heard objection to OOP as it is really used is that there is *not* a clean modular definition isolating *subclasses*. Smalltalk didn't even try. CLOS, I believe, does not try and there is not an idiomatic way to do it. The only language I know that makes a good stab in this direction is C++, which has "public", "protected", and "private". Whatever else you say about C++, Bjarne understood this issue and tried to fix it. The C++ solution isn't perfect but it's sure a lot better than anything else. How can we provide the same thing in Common Lisp? And without changing CLOS? In fact, without adding any new language feature at all? With packages, fhash has a defpackage that provides the protocol seen by callers. If you do an abstract type with CLOS, you ought to do the same thing. (You might have one package for many types.) So the callers can "use" fhash and then call putfhash and so on. (Digression: A slightly different approach is to define a package not intended to be "use"'ed. I did this with the API for the logging facility in QRes. For example: log:add-rule. If you did a "use", it might be confusing to remember that add-rule is from logging, and indeed you might "use" another package that has an "add-rule" function. This is a name conflict. The *whole idea* of packages is to avoid name conflicts! So I think "use" is opposed to the whole idea of packages and should be used sparingly. What people usually do in Common Lisp, in my experience, is to name their functions so that the ones in one module (or, more generally, related ones) all have names starting with a common prefix. Well, that's what packages were invented: so that you don't have to do that! In QRes, even though there is a "qconfig" package for the configuration stuff, the functions are still all named "config-, and everybody uses "use". I think this is not as good as using packages as they were designed. Rather than, e.g., config-descriptor-property, use config:descriptor-property. Anyway.) Now, there's a great thing about CL packages: you can have more than one defpackage for the *same* symbols. So we could have one package for the code that calls into our library, which would have the usual protocol, which we can call the "external protocol". Then we could have a *second package*, which presents a second protocol that subclases would use! This gives us modular separation, just as "protected" does. Of course, there's nothing stopping any code at all from including a symbol from this second package in its code. But we already let people go into internal symbols using "::". Common Lisp's general attitude is that we don't make these things impossible; you're just not supposed to do them. It's very often useful to do this kind of violation when doing interactive debugging, or when writing white-box unit tests. (It would be great to have a static analysis tool that flag you when you "cheat", that you could run before releasing a new version of your stuff.) I have not actually written anything this way, but it seems to me as if it would work. And if experience shows that it does provide what I claim it will provide, I would love for that to become idiomatic/standard usage in Common Lisp. I admit that there's a significant problem, namely the same problem that we always have with packages. Because resolution of packages happens at runtime, it is difficult-to-impossible, in some cases, to change the package declarations during interactive debugging and have the effect that the environment behaves as if you had changed the package declaration and recompiled from scratch. All I can say is that we really ought to do something about the problems with packages, even if you don't buy anything I'm saying here. -- Dan

7 12

[pro] (values) for for-effect functions
by Daniel Weinreb 07 Dec '10

07 Dec '10

In case these terms are too old for anyone to know them, we used to use the phrase "for effect" to mean a function that was called for the sake of its side-effects, versus "for value" when it was called for the sake of its returned value. (Actually I'm not sure I remember what we called a function with both properties.) In some code I have seen, the author of the code has written (values) at the end of an implied-progn body. The purpose, pretty clearly, is to signal the reader of the code that the function was purely for-effect, i.e. that the returned value does not mean anything. This is mostly stylistic. In most cases, returning "nil" means the same thing as returning no values, i.e. (values). The only situation where it makes any difference, as far as I know, is when multiple-value-list is being called, and that's used very, very rarely. The question is, is it good style? That is, ought we consider it something to be recommended? The pro is that it presents clear information to the reader of the code. Merely not putting anything at the end of the implied progn means that the value of the last function called is the returned value, and the reader of the code might think that was on purpose. On the other hand, having a (values) at the end does not actually prove that the function does not have any meaningful value, since a "return" within the function could return a value (or many values). From a purely emotional/historical point of view, I am not used to seeing these (values) forms, and they seem somewhat ugly and verbose. But that's just based on my own experience and should not carry much weight. I'd like to write in our programming standards either that they should be used, or that they should not be used. I think it's suboptimal for them to be used in some places and not others, since the inconsistency could lead a reader of the code to draw wrong conclusions. What do people think? -- Dan

12 15

Re: [pro] Modularity for subclassing in Common Lisp
by Anton Vodonosov 07 Dec '10

07 Dec '10

I think the idea to use packages to specify module protocol (interface, contract) is right. And also I think this is better than to have a separate public/protected/private language feature for classes. What would be the motivation for a separate language feature? What is the difference for modularity in case of subclassing, from other cases were we apply modularity? I can't find the difference. You provide two examples. One is sublcallsing: > My favorite simple example is an > "output stream" protocol, that has a write-character operation and a > write-string operation. The common base class provides an > implementation of write-string that works by iterating over the > characters of the string and calling write-character. Any output > stream that can write strings in a more efficient way can override > that method. The second example is modularity: the fhash library hides the implementation details of the fhash-table object from the library client under a generic API. I am trying to find an example where modularity is applied to subclassing to explore the specifics of the modularity in this case, but I can't think of a good example which will highlight the specifics. We may note that "protected" is actually public, in the sense that when we specify something as "protected", we specify that the library has external clients which can rely on this protected method or field. Anyone may inherit from our public class, and access the "protected" members, therefore these members are available to public. If we change the protected member, we affect the library clients. This drives me to a conclusion, that a single language feature is sufficient which allows to separate a protocol for interaction with a module from the module part we expect to change without affecting clients. I made observation on many java systems, that addition to packages the public/protected/private for classes has bad influence on the system modularity. Many java programmers tend to hide attributes of every single class behind get/set accessors, even for simple classes which just hold values passed between methods and do not contain any logic; to create hierarchies of interface/abstract class/concrete for various minor classes, employing protected methods. But at the same time, people do not care to create structure at larger level, to divide the system into modules. It is not uncommon to see large systems where all these classes, subclasses in all the packages are public: everything is available to everything. Separate access control for classes obscures the idea of modularity (especially in case of such an OO centric language like java, the programmers are mostly concentrated on classes/object, and often don't even think about packages;). Class is too small entity to form a module. A module API (protocol) usually consists of set of classes, methods, factory functions, maybe some global variables. Another thought is that the interface between base class and its subclasses is not a second interface, but a part of the first interface. As you said: > So we could have one package > for the code that calls into our library, which would have the usual > protocol, which we can call the "external protocol". Then we could > have a *second package*, which presents a second protocol that > subclases would use! What would be the name for the second protocol? I.e. what is the interaction the base class and the subclass perform via this protocol? As you point, it may be reusing of the implementation (derived streams reuse write-string implementation from the base class). Looks like a thing intended for reusing can rightly be called an "external protocol" too. Another view on the interaction in subclassing is that the base class serves as a template of some functionality, and we can customize its logic by overriding some methods. The output stream example may be viewed in this perspective: we plug-in our write-character implementation into the functionality implemented by the base class in order to customise it to work with different character source. The means to parametrize/customize the protocol behavior can also be considered as a part of the protocol. In simple case it's method parameters, in more complex case we provide, for example, custom strategies, and can do it by defining a method for the sublcass. Therefore it looks to me that in many cases we deal with a single interface, not two distinct ones. Sometimes a module can interact with the outside world via several protocols, but it not necessary relates to sublcassing, and it's not necessary that both (all) the protocols are defined by this module. > Now, there's a great thing about CL packages: you can have more than > one defpackage for the *same* symbols. It's a great feature. I think you mean something like when we want to define one protocol as an extension of another protocol. Although in many cases I suppose it's possible instead of extending interface to have a separate interfaces. I.e. if one API is (func1, func2, func3), and another API is (finc1, func2, func3, extra-func), we could have the second API just as (extra-func). A good example is needed. Maybe something like database connection API, where implementation for particular database is provided by a pluggable "driver"; or maybe swank, and swank backends for different lisps; or something simpler. - Anton

1 0

Re: [pro] The Best Examples of "Code is Data"
by Matthew D. Swank 05 Dec '10

05 Dec '10

On 09/06/2010 12:41 PM, *Paul Tarvydas* wrote: > 1. Doug Hoyte's book Let Over Lambda, chapter 6.3 Alet and Finite State > Machines, raised my macrology to a new level. I used his ideas to > implement a full-blown hierarchical state machine macro(s) (roughly 200 > lines of CL, too large to post here). The hierarchical state machine > paradigm is great for programming reactive things, e.g. gui's, hardware > controllers, etc. > I've read his treatment of state machines, and they seemed like simplified co-routines. Or are you just referring to his macro techniques in aid of your own ideas about state machines? Matt

2 1

[pro] When to use SLOT-VALUE...
by Hans Hübner 02 Dec '10

02 Dec '10

Hi, The company I work for has a Common Lisp style guide that generally disallows using SLOT-VALUE. Instead, accessor should be used so that: BEFORE and :AFTER methods are always invoked when accessing a slot. Generally, I think this is a good idea when looking at classes and instances from the outside. Slots should be considered as being an implementation detail, and users (i.e. client code and derived class methods) should not make assumptions about how functionality is implemented. Now, I often have the need for class instances that are constant in some respect, i.e. some properties of the instance that are implemented using slots can't directly be changed. I often declare such slots havin only a: READER in the class definition, which makes the read-only nature of this slot apparent right away. Of course, such slots need to be initialized somehow. An :INITARG sometimes does the trick, but it is more common that the value of such slots is calculated and recalculated during the lifetime of the instance, and as such the slot's value must be set. Now, from the perspective of seeing the class declaration as documenting the visible behavior of instances of a class, it does not seem to be proper to declare an accessor to be used in class-internal code so that the slot's value can be updated. Instead, I think that it is better to use SLOT-VALUE to mess with the guts of an instance from code that is part of the guts itself. Of course, one may want to argue that DEFCLASS forms should not be considered to be an interface definition. Instead, one could call for a series of DEFGENERIC forms to define the external interface of some "module" and make class definitions be internal. From a more practical perspective, though, class definitions in CL serve both as interface and implementation definition, thus it seems to be appropriate using the mechanisms provided by CLOS to support both uses. How do others use or avoid SLOT-VALUE? Is it frowned upon in your company's or project's (verbal) style guide? Thanks for your input, Hans

9 14

[pro] Chains of multiple-value-bind...
by Scott L. Burson 26 Nov '10

26 Nov '10

[Sorry for the dup, Pascal. Meant to send this to the whole list.] On Fri, Nov 26, 2010 at 5:36 AM, Pascal Costanza <pc(a)p-cos.net> wrote: > Did anybody see anything similar before? Any suggestions for improvement? > My `bcond' macro, which works closely with my `nlet' macro, attempts to solve the same problem. `nlet' subsumes `multiple-value-bind': (nlet ((a b (foo))) (bar a b)) Coming up with a good syntax for `bcond' wasn't easy, and I'm not sure what you'll think of my solution, but here it is. It's like `cond', except that if the test subform is an `nlet' form, the scope of the bindings it establishes is magically extended to included the entire clause. E.g.: (bcond ((nlet ((a b (foo))) (test a b)) (do-something a b)) ... more clauses ...) The expansion is careful not to extend the scope of the bound variables over the following clauses. These macros are in my "misc-extensions" project on common-lisp.net, included in LibCL and Quicklisp. As they are upward-compatible with `cl:let' and `cl:cond', the package provides the same macros under the names `let' and `cond', which can be shadowing-imported if desired (I use them this way). `nlet' also subsumes and generalizes `let*'. BTW I wrote these 30 years ago, in ZetaLisp. I've always made heavy use of multiple values in my style, and `multiple-value-bind' is way too inconvenient to use -- the name is too long and it only takes one binding clause at a time. -- Scott

1 0

[pro] Chains of multiple-value-bind...
by Pascal Costanza 26 Nov '10

26 Nov '10

Hi, I just hacked the following macro: (defmacro multiple-value-case (&body clauses) (when clauses (destructuring-bind (first &rest rest) clauses (cond ((member (first first) '(t otherwise)) (when clauses (warn "Dead code: ~S." clauses)) `(progn ,@(rest first))) (t (destructuring-bind ((&rest lambda-list) expression (guard) &rest body) first `(multiple-value-bind ,lambda-list ,expression (if ,guard (progn ,@body) (multiple-value-case ,@rest))))))))) Did anybody see anything similar before? Any suggestions for improvement? Thanks, Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

4 3

[pro] Professional uses of Common Lisp...
by Pascal Costanza 11 Nov '10

11 Nov '10

Hi, Dan recently did a survey of existing Common Lisp implementations, which IMO is a very valuable resource. Another valuable resource would be an updated list of current existing professional uses of Common Lisp. The ALU wiki has a list here: http://wiki.alu.org/Industry%20Application - but that is somewhat old by now, as far as I can tell. Any volunteers for doing a survey along those lines? ;) Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

4 3

Re: [pro] Dennis Kucinich
by Daniel Weinreb 29 Oct '10

29 Oct '10

Apologies, the auto-complete in Thunderbird seems to have screwed the address here. Sorry! Yakov Zaytsev wrote: > wtf > > On Fri, Oct 29, 2010 at 7:23 PM, Daniel Weinreb <dlw(a)itasoftware.com > <mailto:dlw@itasoftware.com>> wrote: > > Dennis Kucinich's race is very close. If you want him to win, > send $, see: > > http://kucinich.us/index.php?option=com_content&task=view&id=46&Itemid=58 > <http://kucinich.us/index.php?option=com_content&task=view&id=46&Itemid=58> > > _______________________________________________ > pro mailing list > pro(a)common-lisp.net <mailto:pro@common-lisp.net> > http://common-lisp.net/cgi-bin/mailman/listinfo/pro > >

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

pro