<div dir="ltr">So, here is an idea, start the VM from scratch, and, redo the entire project to allow what we want in Squeak, and the compiler. I know that is a really crazy idea, but I think it could be possible. I have been thinking about a couple of very unlikely, but, possible, maybe, VM ideas, but, what do you guys think about that?<br>
<br><div class="gmail_quote">On Mon, Sep 1, 2008 at 7:56 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2008/9/2 Kjell Godo <<a href="mailto:squeaklist@gmail.com">squeaklist@gmail.com</a>>:<br>
<div class="Ih2E3d">> Where is this new compiler project? Where is NewCompiler? I would like to<br>
> see it.<br>
> Does anybody know where that book about the Squeak Compiler went to?<br>
><br>
> the rest down below is all nonsense and I wouldn't read it if I were you.<br>
><br>
> i knew this was going to cost me.<br>
><br>
> What is atomic loading? Does it mean no dependencies or dependencies are<br>
> handled?<br>
> It seems to me that there needs to be some kind of intellegent dependencies<br>
> manager that works a lot better and is a lot smarter than what has been put<br>
> out there so far.<br>
><br>
<br>
</div>The atomic loading is not about handling dependencies (they are<br>
present and adressed as well, of course), but about installing a<br>
number of changes in system replacing old behavior in a single short<br>
operation, which can guarantee a safety from old/new behaviour<br>
conflicts.<br>
<div class="Ih2E3d"><br>
> How can I learn about how a good Squeak compiler works? Without years and<br>
> millions of dead hours?<br>
><br>
<br>
</div>Sure, you need some experience in compiling things, especially<br>
smalltalk. Or , at least , if you even don't have such experience, but<br>
using Parser/Compiler for own purposes, your experience is valuable as<br>
well, since you can highlight different problems or propose better<br>
interface or new functionality.<br>
<div class="Ih2E3d"><br>
> Modularity is very good. I think that all of Squeak should be very self<br>
> explaining. This can be done if you put your explanations of what is going<br>
> on after the body of the method. Colored source is good too. See Dolphin.<br>
> But without reformating.<br>
><br>
> I am making picoLARC on <a href="http://sourceforge.net" target="_blank">sourceforge.net</a>. Each lisp/smalltalk expression<br>
> gets compiled by an instance of a Compiler Class. Each expression( let if<br>
> define etc ) has its own KEGLambdaLispCompiler subClass with one<br>
> standard method and zero or more helper methods in it. Each Compiler<br>
> outputs an instance of a subClass of the Eval Class. An Eval can be<br>
> evaluated at runtime by >>evalWithActivationRec: or it could generate byte<br>
> codes which do the same thing via some method like<br>
> EvalSubClass>>generateByteCodesOn:usingCodeWalker: where the CodeWalker<br>
> could tie Evals together or do optimizations? Is this not a good design? I<br>
> know I like the part about one Compiler Class for each expression and one<br>
> corresponding Eval Class. But I haven't done any byte code generation yet<br>
> so I don't know about that part. One Compiler per Eval is not strict. The<br>
> ApplicationCompiler can output several different related kinds of Evals for<br>
> the different function calls and message sends.<br>
><br>
> What is this visitor pattern?<br>
<br>
</div><a href="http://en.wikipedia.org/wiki/Visitor_pattern" target="_blank">http://en.wikipedia.org/wiki/Visitor_pattern</a><br>
<div class="Ih2E3d"><br>
> I don't like the idea of putting byte code<br>
> generation into a single Class. But I feel like maybe I don't know what I'm<br>
> talking about. To modify the byte code generation for an expression you<br>
> would subClass the Eval Class and modify the<br>
>>>generateByteCodeOn: aCodeStream. The initial implementor would try to<br>
>>> seperate out the parts that might be modified by someone into seperate<br>
>>> methods that get called by<br>
>>>generateByteCodeOn: so these helper methods would generally be overridden<br>
>>> and not<br>
>>>generateByteCodeOn: unless that method was really simple. So the initial<br>
>>> implementor has to think about reuse and the places where modification might<br>
>>> occure. So you would have a lot of simple<br>
>>>generateByteCodeOn: methods instead of one big complex one.<br>
><br>
> There are all different ways of calling a function or method or query etc in<br>
> picoLARC and these are all subClasses of KEGLambdaLispApplicationEvalV6p1<br>
> and it seems to work fine.<br>
><br>
> But overriding >>generateByteCodesOn: is not good enough is it? The<br>
> Compiler Classes can't have hard coded Eval instance creations either<br>
> right? The Compiler Class has to be subClassed also and the<br>
<br>
</div>The problem in Squeak compiler that you will need to override much<br>
more classes than just Compiler to emit different bytecode, for<br>
instance.<br>
<div class="Ih2E3d"><br>
>>>meaningOf:inEnviron: needs to have a<br>
> ( self createEval ) expression in it that could be subClassed and<br>
> overridden. And then that subClass has to be easily inserted into the<br>
> expression dispatch table that pairs up expressions with expression<br>
> Compilers. So when that table gets made there should be a<br>
> ( tableModifier modify: table ) which could stick the < expression Compiler<br>
>> pairs in that are needed.<br>
><br>
> I think that is all that would be required to modify the compilation of an<br>
> expression.<br>
> I will have to make these changes to picoLARC so it will be more modifiable.<br>
><br>
> I think the Compiler should be very modular. For picoLARC one Class per<br>
> expression and one Class per Eval seems to work good. Stuffing lots of<br>
> seperate things into a single Class and doing a procedural functional thing<br>
> and not an OOP thing does not seem good to me.<br>
><br>
> I think that the Compiler should be very clean and a best practices example<br>
> with a long comment at the bottom of each method telling all about what it<br>
> does. Writing it out and referencing other related methods helps to think<br>
> about what is really going on and then a better design without hacks comes<br>
> out. I don't think hacking should be encouraged at all. Hacking just makes<br>
> a mess.<br>
><br>
</div>+1<br>
<br>
The design should allow replacing critical parts of compiler by<br>
subclassing without the need in modifying original classes.<br>
A so-called extensions , or monkey patching is very bad practice which<br>
in straightly opposite direction from modularity.<br>
<br>
I thinking, maybe at some point, to prevent monkey patching, a<br>
deployed classes can disallow installing or modifying their methods.<br>
<div class="Ih2E3d"><br>
<br>
> And then this practice of not making any Package comments has got to stop.<br>
> I think that people who do that should be admonished in some way. I think<br>
> that the Package comment for the Compiler should contain the design document<br>
> for it that tells all about how it is designed. If it needs to be long then<br>
> it should be long. It should include: How to understand the Compiler.<br>
> There should be a sequence of test cases that start simple and show how it<br>
> all works.<br>
><br>
> And that should go for the VM too. This idea that the VM can be opaque and<br>
> only recognizable to a few is not good.<br>
><br>
<br>
</div>VM tend to be complex. And complexity comes from inability of our<br>
hardware/OS work in a ways how we need/want it.<br>
<div class="Ih2E3d"><br>
> These should be works of art and not hacked up piles of rubbish to be hidden<br>
> away into obscurity.<br>
><br>
> There is this idea that one should only care about what something does. And<br>
> the insides of it are a random black box that you tweek and pray on. But I<br>
> think that the insides should be shown to the world. They should<br>
> be displayed on a backdrop of velvet. Especially the Compiler and VM and VM<br>
> maker. And then the whole Windowing thing should be modularized so you can<br>
> have multiple different Windowing systems.<br>
><br>
> And what about having multiple VMs? It would be cool if picoLARC could be<br>
> inside of Squeak in that way. It would be cool if one VM was generalized so<br>
> that it could support different dialects and languages. And another was<br>
> specific and fast. And you could make various kinds of VMs and images and<br>
> output them onto disk without a lot of trouble. It would come with gcc and<br>
> all that junk all set up so it would just work. If you already had gcc you<br>
> could tell it not to download it.<br>
><br>
<br>
</div>What is gcc? And why it required to make VM? ;)<br>
<div class="Ih2E3d"><br>
> picoLARC has simple name spaces called Nodules where you can have Nodules<br>
> inside of Nodules and Nodules can multiply inherit variables from others.<br>
> Maybe such a thing could be used in Squeak? Then you could have multiple<br>
> VMs. And VMs inside of VMs.<br>
><br>
> I think that Dolphin Smalltalk could be held up as an example of pretty.<br>
><br>
<br>
</div>Maybe, if you know how to deal with license & copyrights when taking<br>
their source and blindly putting it to Squeak :)<br>
<div class="Ih2E3d"><br>
> I hope picoLARC will be another one.<br>
><br>
> I think that Squeak is pretty in a somewhat cancerous sort of way.<br>
> The cancer is all the hacking. That goes on.<br>
> The vision is great but the hacking and undocumenting gum up all those big<br>
> ideas.<br>
><br>
> Sure it's quick but it rots away quickly too.<br>
><br>
> Undocumented features. In Smalltalk this is less of a problem but in like<br>
> Lisp say you make this great feature but then don't document it. You might<br>
> as well have not even made it.<br>
><br>
<br>
<br>
<br>
</div>--<br>
<div><div></div><div class="Wj3C7c">Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>David Zmick<br>/dz0004455\<br><a href="http://dz0004455.googlepages.com">http://dz0004455.googlepages.com</a><br><a href="http://dz0004455.blogspot.com">http://dz0004455.blogspot.com</a><br>
</div>