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?

On Mon, Sep 1, 2008 at 7:56 PM, Igor Stasenko <siguctua at gmail.com> wrote:

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


-- 
David Zmick
/dz0004455\
http://dz0004455.googlepages.com
http://dz0004455.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080901/22775d33/attachment.htm