Stef, This sounds great. At the risk of being the self-appointed exception pedant, I agree that exceptions beat unexpected (even ambiguous) return values, but there should be a way to provide an error block to avoid the overhead. I will also confess to skepticism about default return values - IMHO, they defeat much of the purpose of the exception. However, in the case of the compiler, I can see the other side of the argument (translation, I won't squawk much if it ends up with default actions). Bill
stephane.ducasse@inria.fr 8/20/2008 2:22 AM >>> Hi guys
it occurred to me that this may be important to stress the following point. The point of pharo is not to go to a minimal kernel for the sake of it but to get nice abstractions into play. (of course we will remove etoy, remove the extra fat of morphic and reorganize package structures and more....). But let me take an example: with marcus we worked yesterday on making sure that the newcompiler can be compiled and installed as a second compiler so that compiler freaks can use this second compiler as a fallback when they hack the compiler. The point is that we can in the future remove the old compiler and replace it with the new one. What this example illustrates is that we are looking for the smallest compiler but one that is good and have a good interface (use of exception, instead of [^ nil]). Now ideally we would like to have a smallkernel PLUS a set of packages that composes a pharo-core distribution. What we do not want is to fall into the trap of - smaller better - and have packages that are not touched by refactoring. So we would like to have a smallkernel but not smaller plus the ability to load automatically packages so that when we refactor the system we can work on a coherent set of packages. If you have feedback please let us know. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project