Hi Ian I have been reading about your Cola and Pepsi languages.
Why isn't Cola implemented in Win32 also? I am interested in how executable code is generated in general. Can you point me at any books or info about how such things are done? I have seen your bibliography of papers and books. There is a lot there. I have down loaded your .pdf about porting the Squeak VM. People seem to think that there is no need for new compilers since Microsoft has already done all that there is to do so there are few books on the subject. I would like a book or something about generating the executable codes in depth including the linking in of library functions. .net seems to do that linking in process for you. But I would like to know how it is done. I am interested in Cola because it is similar to what I am doing. I am making something similar called picoLARC. The L stands for Lisp and the ARC is short for Xerox PARC. pico stands for combining many small things together. I am implementing picoLARC on top of Dolphin Smalltalk based on designs from the book Lisp In Small Pieces. The idea is to take the best things from multiple languages and combine them into a single thing. And implement that thing in different languages/platforms to gain access to the libraries of those languages/platforms. Lisp has the best syntax so Lisp syntax is used everywhere. Smalltalk has the best Class hierarchy so the Smalltalk like Class hierarchy is used. Prolog is added in just for spite. Prolog syntax is converted to Lisp style. Each language gets its own inheritance hierarchy. There is an Object hierarchy and a Macro hierarchy and a Prolog Agent hierarchy. Macros can be done on Object methods and Prolog Queries since the syntax is all in Lisp. There could also be hierarchies for ML or Haskell. Each language to be added is converted to Lisp style syntax and a Class and instance hierarchy is set up. Subsets of C++ and Java and C# can be converted to Lisp style and get hierarchies of their own. What I mean is that lambda can generate functions that are like C functions. And this might make it easier for people to ease into a Lispy style of programming. At the same time lambda can generate regular Lisp closures as well. There is a namespace system based on Nodules which are like big Dictionaries at compile time and big Arrays at evaluation time. There is a root Nodule and the other Nodules point to each other in arbitrary graphs to look up global variables. A Nodule can have other Nodules inside. Each Nodule can have each one of the hierarchies inside of it. The Object hierarchy and the Macro hierarchy and the Agent hierarchy and the ML hierarchy and the Haskell hierarchy etc. Macros can be done on any one of these languages because they have all been converted into Lispy syntax. If you want a given hierarchy to be built into a Nodule then a simple set of function calls sets the whole thing up and then new Classes/methods can be added to it. You can also have hierarchies of ProtoTypes in a Nodule. If Classes are implemented in picoLARC Lisp then the Behavior Class MetaClass hierarchy is included in the hierarchies listed above but if they are implemented in a lower level language like Smalltalk then Behavior Class and MetaClass are not included in the hierarchies listed above. Leaving Behavior out is faster putting it in is more reflective. picoLARC can be implemented on top of Smalltalk or any of the other languages listed above. In each case the implementation language becomes a tightly integrated library of functionality. picoLARC will be zero to 10 times slower than the implementation language depending on the parts of it that are used. And depending on whether or not some kind of machine language is produced. picoLARC can be implemented on top of C++.net and C#.net to gain access to those .net libraries. Right now compilation results in a tree of executable Objects. In this way executable granularity is reduced and things are simplified. But I would like to be able to generate .net opcodes and Win32 executable codes. Maybe I will even wade into Linux to see what can be done over there. Maybe to see how Cola works. So picoLARC is the conversion of every language into Lisp syntax so that a hierarchy of Macros called Programmers can be used. Prolog and ML and Haskell and maybe even aspects of Cola can be converted into Lisp style syntax and put into their own hierarchies within the Nodule system in picoLARC. picoLARC can be implemented on top of each language in order to get a tight integration with the libraries accessible to that language. picoLARC can act as a high level scripting language for each of the languages it is implemented on. By scripting I mean that it can be very flexible and organize lower level things that are written lower down for higher speed. messages are dispatched to GenericFunction Objects such that if a method is unique then no Dictionary lookup is needed. Object level methods use an Array lookup instead of a Dictionary lookup. These speedups should help when the implementation is done on top of C++ or the like. A stepping debugger like the one in Smalltalk is tightly intergrated into all aspects of picoLARC including stepping into a macro call. Hopefully it will be easy to add different kinds of programming into picoLARC. Like maybe Aspect Oriented Programming. etc. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
