<div dir="ltr"><div>Where is this new compiler project? Where is NewCompiler? I would like to see it.</div>
<div>Does anybody know where that book about the Squeak Compiler went to?</div>
<div> </div>
<div>the rest down below is all nonsense and I wouldn't read it if I were you.</div>
<div> </div>
<div>i knew this was going to cost me.</div>
<div> </div>
<div>What is atomic loading? Does it mean no dependencies or dependencies are handled?</div>
<div>It seems to me that there needs to be some kind of intellegent dependencies manager that works a lot better and is a lot smarter than what has been put out there so far.</div>
<div> </div>
<div>How can I learn about how a good Squeak compiler works? Without years and millions of dead hours?</div>
<div> </div>
<div>Modularity is very good. I think that all of Squeak should be very self explaining. This can be done if you put your explanations of what is going on after the body of the method. Colored source is good too. See Dolphin. But without reformating.</div>
<div> </div>
<div>I am making picoLARC on <a href="http://sourceforge.net/" target="_blank">sourceforge.net</a>. Each lisp/smalltalk expression gets compiled by an instance of a Compiler Class. Each expression( let if define etc ) has its own KEGLambdaLispCompiler subClass with one standard method and zero or more helper methods in it. Each Compiler outputs an instance of a subClass of the Eval Class. An Eval can be evaluated at runtime by >>evalWithActivationRec: or it could generate byte codes which do the same thing via some method like</div>
<div>EvalSubClass>>generateByteCodesOn:usingCodeWalker: where the CodeWalker could tie Evals together or do optimizations? Is this not a good design? I know I like the part about one Compiler Class for each expression and one corresponding Eval Class. But I haven't done any byte code generation yet so I don't know about that part. One Compiler per Eval is not strict. The ApplicationCompiler can output several different related kinds of Evals for the different function calls and message sends.</div>
<div> </div>
<div>What is this visitor pattern? I don't like the idea of putting byte code generation into a single Class. But I feel like maybe I don't know what I'm talking about. To modify the byte code generation for an expression you would subClass the Eval Class and modify the</div>
<div>>>generateByteCodeOn: aCodeStream. The initial implementor would try to seperate out the parts that might be modified by someone into seperate methods that get called by</div>
<div>>>generateByteCodeOn: so these helper methods would generally be overridden and not</div>
<div>>>generateByteCodeOn: unless that method was really simple. So the initial implementor has to think about reuse and the places where modification might occure. So you would have a lot of simple </div>
<div>>>generateByteCodeOn: methods instead of one big complex one.</div>
<div> </div>
<div>There are all different ways of calling a function or method or query etc in picoLARC and these are all subClasses of KEGLambdaLispApplicationEvalV6p1 and it seems to work fine.</div>
<div> </div>
<div>But overriding >>generateByteCodesOn: is not good enough is it? The Compiler Classes can't have hard coded Eval instance creations either right? The Compiler Class has to be subClassed also and the</div>
<div>>>meaningOf:inEnviron: needs to have a</div>
<div>( self createEval ) expression in it that could be subClassed and overridden. And then that subClass has to be easily inserted into the expression dispatch table that pairs up expressions with expression Compilers. So when that table gets made there should be a </div>
<div>( tableModifier modify: table ) which could stick the < expression Compiler > pairs in that are needed.</div>
<div> </div>
<div>I think that is all that would be required to modify the compilation of an expression.</div>
<div>I will have to make these changes to picoLARC so it will be more modifiable.</div>
<div> </div>
<div>I think the Compiler should be very modular. For picoLARC one Class per expression and one Class per Eval seems to work good. Stuffing lots of seperate things into a single Class and doing a procedural functional thing and not an OOP thing does not seem good to me.</div>
<div> </div>
<div>I think that the Compiler should be very clean and a best practices example with a long comment at the bottom of each method telling all about what it does. Writing it out and referencing other related methods helps to think about what is really going on and then a better design without hacks comes out. I don't think hacking should be encouraged at all. Hacking just makes a mess.</div>
<div> </div>
<div>And then this practice of not making any Package comments has got to stop. I think that people who do that should be admonished in some way. I think that the Package comment for the Compiler should contain the design document for it that tells all about how it is designed. If it needs to be long then it should be long. It should include: How to understand the Compiler. There should be a sequence of test cases that start simple and show how it all works.</div>
<div> </div>
<div>And that should go for the VM too. This idea that the VM can be opaque and only recognizable to a few is not good.</div>
<div> </div>
<div>These should be works of art and not hacked up piles of rubbish to be hidden away into obscurity.</div>
<div> </div>
<div>There is this idea that one should only care about what something does. And the insides of it are a random black box that you tweek and pray on. But I think that the insides should be shown to the world. They should be displayed on a backdrop of velvet. Especially the Compiler and VM and VM maker. And then the whole Windowing thing should be modularized so you can have multiple different Windowing systems.</div>
<div> </div>
<div>And what about having multiple VMs? It would be cool if picoLARC could be inside of Squeak in that way. It would be cool if one VM was generalized so that it could support different dialects and languages. And another was specific and fast. And you could make various kinds of VMs and images and output them onto disk without a lot of trouble. It would come with gcc and all that junk all set up so it would just work. If you already had gcc you could tell it not to download it.</div>
<div> </div>
<div>picoLARC has simple name spaces called Nodules where you can have Nodules inside of Nodules and Nodules can multiply inherit variables from others. Maybe such a thing could be used in Squeak? Then you could have multiple VMs. And VMs inside of VMs.</div>
<div> </div>
<div>I think that Dolphin Smalltalk could be held up as an example of pretty.</div>
<div> </div>
<div>I hope picoLARC will be another one.</div>
<div> </div>
<div>I think that Squeak is pretty in a somewhat cancerous sort of way.</div>
<div>The cancer is all the hacking. That goes on.</div>
<div>The vision is great but the hacking and undocumenting gum up all those big ideas.</div>
<div> </div>
<div>Sure it's quick but it rots away quickly too.</div>
<div> </div>
<div>Undocumented features. In Smalltalk this is less of a problem but in like Lisp say you make this great feature but then don't document it. You might as well have not even made it.<br><br></div>
<div class="gmail_quote">On Mon, Sep 1, 2008 at 2:12 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">2008/9/2 Edgar J. De Cleene <<a href="mailto:edgardec2001@yahoo.com.ar" target="_blank">edgardec2001@yahoo.com.ar</a>>:<br>
<div>
<div></div>
<div>><br>><br>><br>> El 9/1/08 5:39 PM, "Eliot Miranda" <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> escribió:<br>><br>>> The thought of a committee fills me with horror :) I don't think we need<br>
>> anything so baroque :)<br>>><br>>> Best<br>>> Eliot<br>><br>><br>> Peron said:<br>> If you wish nothing happens, nominate a comitee<br>><br><br></div></div>You both right. My intent was only to get people's attention on this<br>
problem and discuss different points of view and their needs.<br>Then implementors (like me) making things need to be done. Thats all.<br>If no-one sharing the thought that we need a better compiler at all,<br>then i can simply take away my words, and we will stay where we still<br>
sitting. :)<br><font color="#888888"><br><br><br>--<br></font>
<div>
<div></div>
<div>Best regards,<br>Igor Stasenko AKA sig.<br></div></div><br><br><br></blockquote></div><br></div>