2008/9/2 Kjell Godo <squeaklist at gmail.com>:
> Where is this new compiler project?  Where is NewCompiler?  I would like to
> see it.
> Does anybody know where that book about the Squeak Compiler went to?
>
> the rest down below is all nonsense and I wouldn't read it if I were you.
>
> i knew this was going to cost me.
>
> What is atomic loading?  Does it mean no dependencies or dependencies are
> handled?
> 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.
>

The atomic loading is not about handling dependencies (they are
present and adressed as well, of course), but about installing a
number of changes in system replacing old behavior in a single short
operation, which can guarantee a safety from old/new behaviour
conflicts.

> How can I learn about how a good Squeak compiler works?  Without years and
> millions of dead hours?
>

Sure, you need some experience in compiling things, especially
smalltalk. Or , at least , if you even don't have such experience, but
using Parser/Compiler for own purposes, your experience is valuable as
well, since you can highlight different problems or propose better
interface or new functionality.

> 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.
>
> I am making picoLARC on sourceforge.net.  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
> 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.
>
> What is this visitor pattern?

http://en.wikipedia.org/wiki/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
>>>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
>>>generateByteCodeOn: so these helper methods would generally be overridden
>>> and not
>>>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
>>>generateByteCodeOn: methods instead of one big complex one.
>
> 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.
>
> 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

The problem in Squeak compiler that you will need to override much
more classes than just Compiler to emit different bytecode, for
instance.

>>>meaningOf:inEnviron: needs to have a
> ( 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
> ( tableModifier modify: table ) which could stick the < expression Compiler
>> pairs in that are needed.
>
> I think that is all that would be required to modify the compilation of an
> expression.
> I will have to make these changes to picoLARC so it will be more modifiable.
>
> 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.
>
> 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.
>
+1

The design should allow replacing critical parts of compiler by
subclassing without the need in modifying original classes.
A so-called extensions , or monkey patching is very bad practice which
in straightly opposite direction from modularity.

I thinking, maybe at some point, to prevent monkey patching, a
deployed classes can disallow installing or modifying their methods.


> 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.
>
> 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.
>

VM tend to be complex. And complexity comes from inability of our
hardware/OS work in a ways how we need/want it.

> These should be works of art and not hacked up piles of rubbish to be hidden
> away into obscurity.
>
> 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.
>
> 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.
>

What is gcc? And why it required to make VM? ;)

> 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.
>
> I think that Dolphin Smalltalk could be held up as an example of pretty.
>

Maybe, if you know how to deal with license & copyrights when taking
their source and blindly putting it to Squeak :)

> I hope picoLARC will be another one.
>
> I think that Squeak is pretty in a somewhat cancerous sort of way.
> The cancer is all the hacking.  That goes on.
> The vision is great but the hacking and undocumenting gum up all those big
> ideas.
>
> Sure it's quick but it rots away quickly too.
>
> 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.
>



-- 
Best regards,
Igor Stasenko AKA sig.