Hello Stephane I would like to contribute to Pharo 3. I would like to contribute BorgLisp to Pharo 3. My main goal in writing you now is that I would like to try to get other people ( scientists? ) interested in this BorgLisp idea because it is way too much work for one single person to do it alone and it will surely die if it is left up to just me alone by myself alone. But it would really put Pharo on the computer science map if BorgLisp were actually to get going in Pharo Smalltalk. Here is the basic idea of BorgLisp : ( BorgLisp is a simple but compelling idea that I would like to spread as widely as possible because this is the way that I would like to program in future. BorgLisp is completely about always using the right language for the job to be solved in the most powerful and most syntactically efficient and most semantically efficient way. ) --------------------------------------- --------------------------------------- --------------------------------------- Basically BorgLisp is a Pharo hosted BorgLisp lisp dialect construction framework where Pharo BorgLisp Compiler designer builders can assimilate every other traditional computer language ( Java C Ruby Haskell Assembler Lisp etc ) into BorgLisp as seperate but mutually embeddable BorgLisp lisp dialects within BorgLisp and with a generalized OOP( object oriented programming ) Smalltalk lisp hybrid style macro system that works across all the BorgLisp lisp dialects. And each BorgLisp Macro M is a Programmer Class instance Method and can be written to generate any BorgLisp syntax using any and all of BorgLisp to code up the syntax generation Macro M. --------------------------------------- --------------------------------------- --------------------------------------- ((( Each traditional language ( Java C Ruby Haskell Assembler etc ) can also have hybrid BorgLisp lisp dialects informed by Smalltalk style naming conventions etc to make them as Smalltalkish and self documenting like Smalltalk as possible. LambdaLisp is a Scheme Smalltalk hybrid in BorgLisp now( Implemented in Dolphin Smalltalk ). ))) BorgLisp Motivations : ------------------------------------------------------------- The main idea for BorgLisp came from the Pepsi Cola lisp Smalltalk hybrid project and the Maru lisp project and is a generalization of the similar more specific language embedding idea in those two projects. Lisp is the most powerful language syntax because you can change and add to its syntax and semantics at will and embed any lisp expression structure into any other lisp expression structure etc because there are no Lisp statements only expressions etc. This power is used in BorgLisp to make it so that each BorgLisp lisp dialect can be embedded into any code expressions of any other BorgLisp lisp dialects ( this dialect embedding is automatically compiler checked depending on whether the BorgLisp lisp dialects can combine in the requested way ). The main BorgLisp lisp dialects should be syntactically similar to and semantically equivalent to the original languages( Java C Ruby Haskell Assembler Lisp etc ) they are based on. There can be other similar hybrid BorgLisp lisp dialects based on traditional languages( Java C Ruby Haskell Assembler Lisp etc ) that are more Smalltalk like or more OOP ( object oriented programming ) for the optimum blend of software language BorgLisp lisp dialects. Here are some proposed BorgLisp lisp dialects : ---------------------------------------------------------------------- LambdaLisp ( a Smalltalk Scheme hybrid I have 75% finished in Dolphin Smalltalk and it can be source level single stepped in a Smalltalk like debugger in Dolphin ) PrologLisp ( I have taken several different cracks at this in Dolphin Smalltalk and it should also be step-able in the same BorgLisp Smalltalk like debugger used for LambdaLisp ) AssemblerLisp ( I have gotten all the IA-32 addressing modes to work in Dolphin and I have gotten one Intel IA-32 asm instruction ADD to compile correctly( all addressing modes ) into native IA-32 machine code according to a general Smalltalk code template which is repeatable for the rest of the IA-32 asm instructions. Probably the Pharo assembler could be used also but my way is also very self documenting of each IA-32 instruction and new asm instructions can easily be added by people other than me who are not familiar with the AssemblerLisp compiler. ((( Eventually this could encourage hardware makers to make more new hardware instructions because each new machine instruction would be quickly implemented in AssemblerLisp by anyone with a superficial knowledge of the AssemblerLisp compiler. ))) ) C-Lisp ( semantically equivalent to the C language ( using the clojure syntax? ) ) SmalltalkLisp JavaLisp ClojureLisp CommonLisp RacketLisp HaskellLisp RubyLisp ErLangLisp PythonLisp RLisp etc etc etc ( One or more BorgLisp lisp dialects can be constructed for each traditional computer language( Java C Ruby Haskell Assembler Lisp etc ) that exists or will exist ). ( There could also be Smalltalkish BorgLisp lisp dialects that were more object oriented than the original traditional languages that they are based on like LambdaLisp which is a Scheme Smalltalk hybrid which is fully OOP and is not semantically equivalent to Scheme( except in the core Scheme semantics ). ) BorgLisp is designed to host an OOP style lisp like macro system that can be used across all the different BorgLisp lisp dialects. This multi dialect BorgLisp macro system is based on a message sending syntax like in Smalltalk. So you create a Macro Class called a Programmer in a Programmer Class hierarchy and when BorgLisp syntax seems to send a message to that Class( or an instance of the Class? ) then an OOP style BorgLisp macro is evaluated which constructs BorgLisp source code( in the form of a syntax Object list ) which replaces the syntax macro message send in the BorgLisp source code being compiled. The BorgLisp macro is written in BorgLisp so it can use all the BorgLisp lisp dialects. BorgLisp has one or more source code debuggers like the one in Smalltalk. In the Dolphin prototype I have a Smalltalk like debugger that can source level single step single expression LamdaLisp programs. I have taken a crack at another style of Debugger that is Tree based and shows how each lisp expression gets reduced into its return value but that one got too complex so I switched to the traditional one that is simpler and does work now in Dolphin Smalltalk. The BorgLisp debuggers would be able to step through macro expansions. The BorgLisp debugger I made for the Dolphin Smalltalk BorgLisp prototype is designed to be able to treat macro expansions like function calls / message sends that dont put anything onto the program activation stack. This source level macro debugging capability would be a significant advantage over traditional lisp and would make lisp much more Smalltalk like. Traditional lisp never seems to have a source level debugger that works. Which is the pits( its bad ). The most important thing about BorgLisp is that you can embed any expression of any of the BorgLisp lisp dialects into expressions of any of the other BorgLisp lisp dialects ( if such specific embeddings are allowed by the BorgLisp compilers ). The BorgLisp lisp dialect compiler framework I started in Dolphin Smalltalk is very OOP with each BorgLisp lisp dialect in its own Class hierarchy and with a single Compiler Class for each type of BorgLisp lisp expression in each BorgLisp lisp dialect. This makes the BorgLisp lisp dialect compilers very similar to each other and very easy to understand and maintain. If you want to modify the compilation of any BorgLisp lisp dialects expression( like the LambdaLisp let expression ) then you just look up the Smalltalk Class of the same name( LambdaLispLetCompiler ) and the complete ( very small ) compiler for that BorgLisp lisp let expression is right there in its entirety( some code walking combines different expression compilers. Expression compilers can call other expression compilers to do syntax recursion ). BorgLisp should eventually be completely written in BorgLisp but at first it will be written in Pharo Smalltalk in such a way that the Classes can easily be converted over to LambdaLisp Classes or even SmalltalkLisp Classes in future. AssemblerLisp will provide a way to compile BorgLisp lisp dialects down to native machine code. But there is also a tree reduction process of BorgLisp evaluation that can be used for debugging which is part of the BorgLisp lisp dialect Compiler Class hierarchies such that each expression Compiler is associated with an expression evaluator( again this makes things very clear simple and maintainable ). Each Smalltalk like BorgLisp lisp dialect hybrid( like LambdaLisp ) of a traditional language( Java C Ruby Haskell Assembler Lisp etc ) and Smalltalk can have multiple complete Object Class Hierarchies as opposed to Smalltalk which has only one Class hierarchy in it. There is also the idea of BorgLisp lisp dialect Modules which can be imported into each other in a graph network and can also form a Object Module hierarchy. ((( There is also an efficient message dispatch idea implemented in LambdaLisp which clusters Methods with the same selector into Dictionaries called GenericFunctions which use the Class of the Message receiver as the lookup key to find the Method to evaluate the Message. Smalltalk on the other hand clusters the Methods into Classes and uses the Message selector as the key to look up Methods in the Classes. LambdaLisp has both GenericFunctions and Classes. The LambdaLisp Classes are there mainly to organize Methods in the Code Browser used by the LambdaLisp programmer( these Classes are not used for Method dispatch ). By doing it this way it makes it so that unique Methods that are only implemented in a single LambdaLisp leaf Class( no subClasses ) are dispatched like redirectable function calls in C. It also makes it so that Methods in the LambdaLisp Object Class are dispatched using an Array lookup instead of a Dictionary lookup like in Smalltalk. ))) So anyway do you have any interest in this BorgLisp idea as described above for Pharo? ((( If Pharo BorgLisp was actually to get started in Pharo Smalltalk with several BorgLisp lisp dialects of traditional languages assimilated into it by Pharo BorgLisp lisp dialect Compiler designer implementers then traditional language designers ( Java C Haskell ErLang Ruby R etc etc etc ) will in future be more and more compelled to make BorgLisp lisp dialect versions of their traditional languages. This force will become stronger and stronger the more languages get assimilated. Because when each language can easily embed into all the others with BorgLisp OOP Macros across all BorgLisp lisp dialects then a singularity will result that makes all the assimilated languages much much much more powerful than any single language by itself alone. And each new BorgLisp lisp dialect will add to this syntactic and semantic power in an exponential or geometric way. And that will all lead back to Pharo Smalltalk and image based programming. Pharo BorgLisp? ))) Can you help me to get others involved in this BorgLisp idea Stephane? Thank you for your time. ( I have used up all my time writing this ) Regards Kjell E Godø ((( Here is a Las Vegas STIC March 2011 talk I gave on BorgLisp. Please forgive my monotone crabbed vocal delivery. I cant help it because I have Aspergers syndrome which is a form of high functioning autism. Thanks. stic.st/conferences/sts11/abstracts/picolarc-the-borg-language-and-the-next-smalltalk/ scribd/doc/51270506/picoLARC-the-Borg-Language-and-the-Next-Smalltalk-The-Best-Ideas-All-At-Once-Kjell-Godo )))
Posted on: Sat, 16 Nov 2013 20:44:46 +0000
Trending Topics
Recently Viewed Topics
© 2015